Re: [Fwd: local device discovery - api, demo and source code]

Re: extending WebSocket, I admit it is a stretch, semantically speaking, but
I was thinking mostly of reuse of the WebSocket API here, as opposed to
reusing or extending WSP itself. It could also be argued that an independent
API would be better; however, going with the initial idea, I had something
like the following in mind (consider this a rough strawman example):

function recvSSDP(/*WebSocket*/ socket, /*SSDPMessage*/ msg) {
  // receive incoming SSDP message
  var s = msg.startLine;
  if ( s.indexOf('NOTIFY') == 0 ) {
    // dispatch notification
  } else if ( s.indexOf('M-SEARCH') == 0 ) {
    // dispatch search
  } else if ( s.indexOf('HTTT/1.1') == 0 ) {
    // dispatch search response
  } else {
    // ignore other messages
  }
}
function sendSSDP(/*WebSocket*/ socket, /*SSDPMessage*/ msg) {
  // transmit outgoing SSDP message if open
  if ( socket.readState == s.OPEN ) {
    socket.send ( msg.encode() );
  }
}

var socket = new WebSocket();
socket.onmessage = function(event) {
  recvSSDP ( socket, new SSDPMessage(event.data) );
};
// open UDP socket, protocol 'ssdp'
socket.open ( 'udp://239.255.255.250:1900/', 'ssdp' );

var startLine = 'M-SEARCH * HTTP/1.1';
var headers = {
  'HOST'       : '239.255.255.250:1900',
  'MAN'        : '\"ssdp:discover\"',
  'MX'         : '1',
  'ST'         : 'ssdp:all'
};
sendSSDP ( socket, new SSDPMessage ( startLine, headers ) );

Note that WebSocket as presently defined does not have a distinct open()
method (as implied above), which creates a race condition between
construction and open, since open may complete prior to onopen being set. I
have used a two-step construct then open above similar to XHR2.

So, the question above is this adequate to support SSDP, and would it be
better to define a new API without reusing WS. My answer to both of these
is: probably (adequate and better to define a new API). If WS were a bit
more generic and not tied to WSP, then it could suffice (provided the open
problem is fixed, and perhaps add a 'base64' sub-protocol to allow send/recv
of arbitrary UDP packet bodies).

G.

On Fri, Apr 15, 2011 at 5:52 PM, Dave Raggett <dsr@w3.org> wrote:

> On Fri, 2011-04-15 at 17:09 +0800, Glenn Adams wrote:
> > If WebSocket were extended to permit send/recv of a UDP
> > multicast/unicast packet, then it should be possible to implement all
> > of UPnP protocol, including SSDP, directly in client side JS via an
> > (extended) WebSocket enabled UA.
>
> The Web Sockets API is designed for bilateral communications. How would
> you suggest modifying it to support multicast and datagram based
> messages?
>
> > The question remains whether it is necessary or useful to define
> > higher level abstraction layers, e.g., a low-level, generic UPnP
> > layer, UPnP service specific layers, etc.
>
> Quite so. This could come later based upon experience by library
> developers with exploring various approaches to defining overarching
> abstractions.
>
> --
>  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>
>
>