Re: Extending Network Service Discovery draft with advertisement

To my earlier response's point, Dave's example is one that I'm having trouble mapping to the HTML5 API mentioned by Richard, except in the case where some home gateway acts as a discovery agent for devices advertising services, and then exposes them to browsers through web pages hosted on the gateway. I think this is reasonable given that gateways may offer a RUI function, and can simplify security management issues as devices/apps can register with the gateway, which then exposes their services according to gateway-owner managed policies.

But I think the multicast approach is more direct, and consistent with the ideas discussed so far in the HNTF.

Thanks,
Bryan Sullivan

On Mar 12, 2012, at 9:24 AM, "Dave Raggett" <dsr@w3.org> wrote:

> On 12/03/12 12:27, Rich Tibbett wrote:
> 
>> Perhaps you could describe in more detail the use case here? Is this
>> about web apps advertising themselves as Local Network Services? That is
>> something I'd particularly like to see proposals for so please forward
>> them here and we can discuss them further. For the most part that's
>> something that I see registerProtocolHandler doing [1].
>> 
>> Best regards,
>> 
>> Rich
>> 
>> [1]
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-navigator-registerprotocolhandler
> 
> 
> Something I've thought about is locally installed web apps that act as
> multiplayer games, and where the game players are all on the same local
> network. You need some way to locate other game players, and an
> efficient means to communicate with them.
> 
> Multicast messaging seems very promising for this purpose, firstly as a
> means to advertise your readiness to play, and secondly as an efficient
> means to distribute events to all players. In practice, multicast
> messages are limited in length, but present no problem for modest sized
> JSON encoded events.
> 
> To avoid security problems, you would limit the multicast port range and
> impose checks on the messages. The users would first need to give their
> consent.  We don't need to limit discovery to UPnP!
> 
> A further idea was to look at privacy friendly local discovery, given
> that multicast packets can typically be read by anyone on the same LAN.
> Sometimes you might care about who can see which devices/services are
> being advertised. The advertisements are encrypted to ensure that only
> intended parties can read them. This is a bit like DRM in that you need
> careful key management.
> 
> -- 
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>

Received on Monday, 12 March 2012 14:58:58 UTC