Hi Enrico, Yes. Websockets will be useful for cases where there are frequent notifications (like server load etc). This is only one use case for subscription/notification. IMO, we should define a generic framework for subscription/notification which includes support for things like multiple event subscription and does'nt have the overhead of persistent connections when the clients are not interested to keep them. Regarding the server creating a connection to the client, the client explicitly advertises its contact address for the server to connect to. The reachability problem should be solved by the client.
-Ravi ________________________________________ From: Enrico Marocco [[email protected]] Sent: Monday, July 23, 2012 1:14 PM To: Ravi nandiraju Cc: [email protected] Subject: Re: [alto] WebSocket-based notifications 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
