XMLHttpPushContent - Client-side storage (buffer?!) to which server
can push.

Is it possible? Would this be useful?

v4vijayakumar wrote:

> XMLHttpPushContent - Client-side storage (buffer?!) to which server
> can push.
> 
> Is it possible? Would this be useful?

Hi,

Are you describing a scheme where some server will push anasked information 
to some client?
That will not work because most clients are behind a router/firewall and the 
server cannot find a open/working port that routes to the client you want 
to push to. (Many routers open a random port to which the server can 
respond, so the router 'knows' which machine behind the the router wanted 
the information.)

If you mean something different, please elaborate a little more...

Regards,
Erwin Moller

On Mar 27, 2:56 pm, Erwin Moller
<since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> v4vijayakumar wrote:
> > XMLHttpPushContent - Client-side storage (buffer?!) to which server
> > can push.
> >
> > Is it possible? Would this be useful?
> >

....

> Are you describing a scheme where some server will push anasked information
> to some client?
>
yes.

> That will not work because most clients are behind a router/firewall and the
> server cannot find a open/working port that routes to the client you want
> to push to. (Many routers open a random port to which the server can
> respond, so the router 'knows' which machine behind the the router wanted
> the information.)
>
> If you mean something different, please elaborate a little more...
>

....

If there is "XMLHttpPushContent" object to which server can push data,
then it would be useful (?).

Some web contents are really push. Even, RSS/atom feeds are pulled by
the browser/readers.

I always wondered why, for servers, when it is possible to respond to
requests but not communicate thereafter. If it is possible for a
client
pull content from server, why there is no way for the server to push
content to the client.

If many clients are behind the firewall/router then, why not servers
talk to them, then it is their (firewall/router) responsibility to
communicate to clients. Why there is no "URL-like" mechanism (reverse
URL ?!) for serves to talk back to client.

thanks.

v4vijayakumar wrote:

> On Mar 27, 2:56 pm, Erwin Moller
> <since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
>> v4vijayakumar wrote:
>> > XMLHttpPushContent - Client-side storage (buffer?!) to which server
>> > can push.
>> >
>> > Is it possible? Would this be useful?
>> >
> 
> ...
> 
>> Are you describing a scheme where some server will push anasked
>> information to some client?
>>
> yes.
> 
>> That will not work because most clients are behind a router/firewall and
>> the server cannot find a open/working port that routes to the client you
>> want to push to. (Many routers open a random port to which the server can
>> respond, so the router 'knows' which machine behind the the router wanted
>> the information.)
>>
>> If you mean something different, please elaborate a little more...
>>
> 
> ...
> 
> If there is "XMLHttpPushContent" object to which server can push data,
> then it would be useful (?).

For a server to 'push' anything, there must be a listening client.
Lets for simplicities sake say an IP-num and a port.

> 
> Some web contents are really push. Even, RSS/atom feeds are pulled by
> the browser/readers.

Erm?
You say some servers push, and give an example of 'client pull' which is 
excactly why we speak of 'serverpush' and 'clientpull', which is not the 
same thing.
For a server to really push there must be some client waiting for a possible 
bunch of information send by some server.


> 
> I always wondered why, for servers, when it is possible to respond to
> requests but not communicate thereafter. If it is possible for a
> client
> pull content from server, why there is no way for the server to push
> content to the client.

Of course that is possible. But it is not the nature of the http-protocol. 
In short (and not excactly): 
1) request received at server.
2) server sends back response to client (Server can see where to send back 
because the return address and port is mentioned in the request)
3) connection ends there.

That is how http works.

Of course, you can come up with another scheme that does something else, 
many exist, but it won't be http. ;-)

> 
> If many clients are behind the firewall/router then, why not servers
> talk to them, then it is their (firewall/router) responsibility to
> communicate to clients. Why there is no "URL-like" mechanism (reverse
> URL ?!) for serves to talk back to client.

There ARE such schemes, many, but they are NOT http.

Routers that perform NAT (Network Address Translation) do switch ports to 
the outside world all the time.
So there is simply no way to reach a client behind NAT after the response 
from the server is received.
The NATsoftware opens a random port for the server to respond to. Then the 
NAT software closes the port, and opens a new random port for the next 
request.

A realworld example:
computer1 (internal IP 10.0.0.160), 
computer2 (internal IP 10.0.0.180), 
computer3 (internal IP 10.0.0.200), 
are together behind the same router that performs NAT, and is connected to 
the internet.

This is what happens roughly:
1) computer1 opens in a browser www.google.com
2) request arives at the router.
3) router opens a random port for incoming traffic, say port 12345, and 
remembers any answers ariving at that port sould go to 10.0.0.160.
4) router sends the request to google.
5) After some time google responds to the IP-address of the router on port 
12345.
6) router sees the packages coming in on port 12345, and sends them to 
10.0.0.160.
7) When all packages are in (or google times out) the port 12345 is closed 
and the firewall forgets about the port12345-10.0.0.160 combi.


For a serverside push scheme to work, the server needs to know where 
(IP+port) to send the information to, and of course the client has to have 
software listening to that port. With NAT this won't work, since the router 
did close the port.


> 
> thanks.

You're welcome.

Regards,
Erwin Moller

On Mar 27, 2:27 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
> XMLHttpPushContent - Client-side storage (buffer?!) to which server
> can push.
>
> Is it possible? Would this be useful?

There's a technique called "Comet" in which the client opens a
connection to a server and the server begins a loop that keeps a
connection open.  While that loop is running, the server has the
ability to push data to the client without the client requesting it.

wiki:
http://en.wikipedia.org/wiki/Comet_(programming)

On Mar 27, 6:36 pm, Erwin Moller
<since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> v4vijayakumar wrote:
> > On Mar 27, 2:56 pm, Erwin Moller
> > <since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> >> v4vijayakumar wrote:
> >> > XMLHttpPushContent - Client-side storage (buffer?!) to which server
> >> > can push.
>
> >> > Is it possible? Would this be useful?

....

> > I always wondered why, for servers, when it is possible to respond to
> > requests but not communicate thereafter. If it is possible for a
> > client
> > pull content from server, why there is no way for the server to push
> > content to the client.
>
> Of course that is possible. But it is not the nature of the http-protocol.
> In short (and not excactly):
> 1) request received at server.
> 2) server sends back response to client (Server can see where to send back
> because the return address and port is mentioned in the request)
> 3) connection ends there.
>
> That is how http works.

Even there is no way to serialize http-request object in the server
side, so that we can use these details later.

"Push" also can be compared to "response", when "request" means
"tune-in".

v4vijayakumar wrote:

> On Mar 27, 6:36 pm, Erwin Moller
> <since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
>> v4vijayakumar wrote:
>> > On Mar 27, 2:56 pm, Erwin Moller
>> > <since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
>> >> v4vijayakumar wrote:
>> >> > XMLHttpPushContent - Client-side storage (buffer?!) to which server
>> >> > can push.
>>
>> >> > Is it possible? Would this be useful?
> 
> ...
> 
>> > I always wondered why, for servers, when it is possible to respond to
>> > requests but not communicate thereafter. If it is possible for a
>> > client
>> > pull content from server, why there is no way for the server to push
>> > content to the client.
>>
>> Of course that is possible. But it is not the nature of the
>> http-protocol. In short (and not excactly):
>> 1) request received at server.
>> 2) server sends back response to client (Server can see where to send
>> back because the return address and port is mentioned in the request)
>> 3) connection ends there.
>>
>> That is how http works.
> 
> Even there is no way to serialize http-request object in the server
> side, so that we can use these details later.
> 
> "Push" also can be compared to "response", when "request" means
> "tune-in".


Sorry, you lost me. :-/

Regards,
Erwin Moller