XMLHttpPushContent

[v4vijayakumar]

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

Is it possible? Would this be useful?

 

[Erwin Moller]

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

 

[v4vijayakumar]

....

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.

 

[Erwin Moller]

...

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

 

[Walton]

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)

 

[v4vijayakumar]

....


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".

 

[Erwin Moller]

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