I agree that NAT traversal is complex but that is for a peer to peer network where both the peers are behind NATs and they need to figure out their reachability. In case of ALTO we don't have that kind of complexity. The ALTO client which expects the server to connect to it needs to ensure that it is reachable on that address/port from an external/internal network. This is same as the way an ALTO server behind a carrier firewall is configured to be reachable to clients outside.
I don't envisage ALTO clients like home devices using the subscription mechanism because, for a home device client it is easier to query the ALTO server for a changed map information rather than going for a subscription. IMO, this subscription mechanism would be useful for infrastructure cases like gateway devices, CDN, inter-DC etc where the problem of reachability is not so complex as in the case of peer to peer. Please let me know if there is something I am missing here. -Ravi ________________________________________ From: Enrico Marocco [[email protected]] Sent: Tuesday, July 24, 2012 4:10 PM To: Ravi nandiraju Cc: [email protected] Subject: Re: [alto] WebSocket-based notifications On 7/24/12 11:57 AM, Ravi nandiraju wrote: > 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. This is actually something the authors would like to get feedback about, i.e. whether people prefer to have one connection per resource, or some sort of subscription protocol running for multiple resources on a single connection. The draft at this point suggests the former approach, basically for simplicity. > 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. I cannot think of any way for the client to solve the reachability problem that is less demanding in terms of resources than a client-initiated connection. Can you suggest one that works with today's firewalls, access gateways and carrier NATs? -- Ciao, Enrico _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
