v4vijayakumar wrote:
On Mar 27, 2:56 pm, Erwin Moller
<since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
>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