Ok, I see you point. I agree that, for resources that rarely change there may be even a substantial gain with having the connection initiated by the server only upon an update event. On the flip side, for constantly changing resources (e.g. representing uptime-like information about server load) the overhead of a full HTTP request for each and every update would easily exceed the overhead due to maintaining a websocket connection.
More concerning than overhead is however the reachability requirement that a mechanism based on server-initiated connections pose on the client side, and that in fact would make it unsuited for any host residing behind a NAT -- the vast majority of end-user devices. Enrico On 7/23/12 9:04 AM, Ravi nandiraju wrote: > Hi Enrico, > The overhead which I was mentioning in my previous e-mail was about > managing the connections even when there is no change in the ALTO map > information. I think an explicit subscription/notification mechanism which we > proposed in > [http://tools.ietf.org/html/draft-alto-caching-subscription-00#section-8] > does not have this overhead because the server would initiate the connection > only when required. The server does'nt need to maintain the connection when > there is no change in the map information. > The mechanism which is proposed in the websocket based notification is an > implicit subscription where the connection implies the subscription. To keep > the subscription alive, the connection needs to be alive. In many cases, the > client just wants to subscribe and get notified only when there is a change > in the map data otherwise the connection is just an overhead. > > -Ravi > ________________________________________ > From: Enrico Marocco [[email protected]] > Sent: Friday, July 20, 2012 6:31 PM > To: Ravi nandiraju > Cc: [email protected] > Subject: Re: [alto] WebSocket-based notifications > > There certainly is additional overhead with any push notification > mechanism, esp. as compared to the simple pull model. For sure in terms > of resources needed for maintaining the subscription state of the > clients to be notified and for keeping the notification channels alive. > But that's a price you have to pay if you want to have server-initiated > notifications and in the end I believe the transport protocol will > hardly have a significant impact on it. Can you point out where you > think in WebSocket lays the additional overhead other alternatives do > not suffer from? > > Enrico > > On 7/20/12 2:15 PM, Ravi nandiraju wrote: >> Hi Enrico, >> I went through the proposed mechanism of notifications based on WebSocket >> protocol. I think this mechanism has the additional overhead of server >> needing to keep the connection alive for all the clients which need >> notification. This works well if the number of clients are less. In case of >> scenarios where the clients are more, then the server needs to manage a lot >> of connections. >> >> The additonal drawback of this mechanism is that if there is no change in >> the map data then the connections still needs to be managed by the server. >> >> -Ravi >> >> ________________________________________ >> From: [email protected] [[email protected]] on behalf of Enrico >> Marocco [[email protected]] >> Sent: Monday, July 16, 2012 1:09 PM >> To: [email protected] >> Subject: [alto] WebSocket-based notifications >> >> Folks, >> >> Jan and I have just submitted a draft proposing a server-to-client >> notification mechanism based on the WebSocket protocol: >> http://tools.ietf.org/html/draft-marocco-alto-ws-01 >> >> The mechanism proposed is one of the several possible, and the draft at >> this point delineates the idea only at quite a high level, without >> delving too deep into the details. Yet it should be enough to start a >> focused discussion, so please, if you are interested in the topic, take >> a quick read and share your thoughts on the list -- whether you feel >> this is a promising way to go, or if you have alternatives that you >> think would fit better. >> >> -- >> Ciao, >> Enrico
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
