RE: Sockets, was Re: [Raw Socket API]. New version separating UDP and TCP interfaces

Hi and thanks for your comments Marcos, Tomoyuki and Jonas,

1. [Marcos]: Also, where are the use cases for the raw socket APIs documented?  

[Claes]: At first a note that under http://www.w3.org/wiki/System_Applications#Phase_1_drafts there are place holders for use cases for each SysApps deliverable but all these sections are currently empty. When the WG started working more than half a year ago there was a poll on APIs to specify and the Raw Socket API was selected as a phase 1 deliverable. However, as far as I know there is no documentation of use cases that motivate the WG's deliverables. So a structured collection of use cases seems to be something that this WG currently misses for all API deliverables.

Going back to the raw socket API Jonas and Tomoyuki provided the following use cases:

* An email client which communicates with SMTP, POP3 and IMAP servers
* An irc client which communicates with irc servers.
* Implementing an ssh app.
* Communicating with existing consumer hardware, like internet connected TVs.
* Game servers
* Peer-to-peer applications

In addition I want to add local network multicast service discovery. In the protected SysApps runtime simple JS UPnP/SSDP, mDNS, etc APIs can be created on top of the Raw Socket API. Here we have plenty of use cases in the home media environment.

2. [Marcos]: I don't yet have concrete feedback on this API, but from first glance I'm concerned that it seems to deviate quite a bit from Web Sockets (I understand that it has to, because of the different requirements of the protocols). 

[Claes]: Yes, the proposed Raw Socket API deviates from the Web Socket API and, as you say, it has to as these APIs are interfaces to different protocols, the IETF WebSocket protocol versus UDP/TCP. As Tomoyuki points out the starting point for the SysApps Raw Socket API was the Chrome Socket API, which uses the well-proven structure and de facto standard of Berkeley socket APIs. So the questions is: Should we follow this structure or do something completely different? What is realistic within a reasonable timeframe?

Furthermore, The question is which style developers are used to? I assume there is a huge community of developers that are used to the "Berkeley Socket style" but of course, if we can do something that is better and easier for developers and still fulfill the goal of low level UDP/TCP communication we should not refrain from doing that. 

It is probably possible to align the style of the Raw Socket API with the Web Socket API, i.e. specify the Raw Socket interface as EventTarget and use EventHandler onsomething attributes, instead of callback functions as in-parameters to methods. However, due to the current discussion in SysApps on DOMRequest I suggest that we should wait to do a general change of the API structure until we have a resolution on the structure of SysApps APIs. When we have consensus on this issue I will analyze the API structure to align with other SysApps API.

3. [Marcos]: Also, the Node.js community has done a lot of work in creating socket APIs that seem much simpler than the ones proposed (at least it seems so at first glance), such as:

* http://socket.io/
* https://github.com/LearnBoost/engine.io
* https://github.com/socketstream/ss-sockjs
* https://github.com/nodejitsu/nssocket/
* https://github.com/socketstream/socketstream

See also "npm search socket"

It would be great if we could do a round of collecting data about what APIs are out there, and what developers are using and critically evaluate those. It would suck to reinvent the wheel when there are already good patterns out there that pair client and servers nicely (like socket.io does with its client-side library). 

[Claes]: Yes, socket.io is a simple API. However, I am not sure that we, with socket.io, can reach the low level that is required. Shouldn't we see socket.io etc as libraries above the W3C Raw Socket API (and the W3C Web Socket API). For example, socket.io uses URL addressing while the Raw Socket API needs IP-addressing. This is for example needed in order to create a UPnP SSDP M-Search multicast message. 

4. [Jonas]: Let me make another plug for the API that we're currently using in Firefox OS and which was somewhat modeled after the WebSocket API:

http://mxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMTCPSocket.idl#29

There are a few things that we expect will need to be changed in this API:
* We should use a real constructor rather than a .open method
* The binaryType API likely needs to be changed to fit the latest whims of how ArrayBuffers should be used :)
* Buffering might need to be more configurable
* Needs support for startTLS

[Claes]: This is an alternative approach but due to the limited documentation I have difficulties in understanding if all our use cases could be fulfilled by this API. For example, is it possible to implement SSDP multicast with using this API?

5. [Jonas]: Additionally we need to add support for incoming connections. This is something that I don't quite understand with the current API. I would have expected there to be a static 'listen' function which allowed registering a callback for incoming connections. This callback would receive a TCPSocket object. The current setup where you seem to need to create a TCPSocket object first, and then call bind and/or listen seems very awkward to me.

[Claes]: The traditional scenario is http://en.wikipedia.org/wiki/File:InternetSocketBasicDiagram_zhtw.png. When Accept() is called the AcceptInfo contains the new socket object for the accepted socket that is used for further communication with the remote host. (However, there is currently an error in AcceptInfo. The type of socket should be TCPSocket, not RawSocket.)

Best regards
  Claes

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: den 25 februari 2013 11:31
> To: Marcos Caceres
> Cc: public-sysapps@w3.org
> Subject: Re: Sockets, was Re: [Raw Socket API]. New version separating
> UDP and TCP interfaces
> 
> On Fri, Feb 22, 2013 at 7:06 AM, Marcos Caceres <w3c@marcosc.com>
> wrote:
> > Hi,
> > I don't yet have concrete feedback on this API, but from first glance
> I'm concerned that it seems to deviate quite a bit from Web Sockets (I
> understand that it has to, because of the different requirements of the
> protocols). Also, the Node.js community has done a lot of work in
> creating socket APIs that seem much simpler than the ones proposed (at
> least it seems so at first glance), such as:
> >
> > * http://socket.io/
> > * https://github.com/LearnBoost/engine.io
> > * https://github.com/socketstream/ss-sockjs
> > * https://github.com/nodejitsu/nssocket/
> > * https://github.com/socketstream/socketstream
> >
> > See also "npm search socket"
> >
> > It would be great if we could do a round of collecting data about
> what APIs are out there, and what developers are using and critically
> evaluate those. It would suck to reinvent the wheel when there are
> already good patterns out there that pair client and servers nicely
> (like socket.io does with its client-side library).
> 
> Let me make another plug for the API that we're currently using in
> Firefox OS and which was somewhat modeled after the WebSocket API:
> 
> http://mxr.mozilla.org/mozilla-
> central/source/dom/network/interfaces/nsIDOMTCPSocket.idl#29
> 
> There are a few things that we expect will need to be changed in this
> API:
> * We should use a real constructor rather than a .open method
> * The binaryType API likely needs to be changed to fit the latest whims
> of how ArrayBuffers should be used :)
> * Buffering might need to be more configurable
> * Needs support for startTLS
> 
> Additionally we need to add support for incoming connections. This is
> something that I don't quite understand with the current API. I would
> have expected there to be a static 'listen' function which allowed
> registering a callback for incoming connections. This callback would
> receive a TCPSocket object. The current setup where you seem to need to
> create a TCPSocket object first, and then call bind and/or listen seems
> very awkward to me.
> 
> > Better still, we should reach out to the developers of the above
> libraries to review and comment on anything we come up with.
> 
> Yes!
> 
> > Also, where are the use cases for the raw socket APIs documented?
> 
> The use cases that we had for FirefoxOS were:
> 
> * An email client which communicates with SMTP, POP3 and IMAP servers
> * An irc client which communicates with irc servers.
> * Implementing an ssh app.
> * Communicating with existing consumer hardware, like internet
> connected TVs.
> 
> For some of these types of hardware we'll likely need higher-level APIs.
> But we'll never be able to cover all existing hardware and software
> that is out there, so we need a fallback.
> 
> / Jonas

Received on Monday, 25 February 2013 22:17:53 UTC