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

Thanks for these very valuable comments Jonas,

As said before the current API proposal is based on a well-proven structure and kind of de facto standard. I believe that this API will work fine and that we will be able to fulfill our use cases by this approach. 

However, I understand the arguments for making a simpler and more "webish" API. We must also consider what we really need in order to support for web applications. The current API is very flexible but this level of flexibility may not be needed for web applications.

I submitted an update today with a minor simplification eliminating the need to call bind() when setting up a TCP server. The scenario now is listen() - accept().

Going further I will look in more detail into the Mozilla API, Web Sockets and node socket.io and analyze what structure changes and simplifications that can be done to the SysApps Raw Socket API and still keep the ability to fulfill our needs that basically is UDP communication including multicast and TCP Client/Server. 

I hope to have a new draft pretty soon.

Best regards
  Claes


> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: den 26 februari 2013 20:30
> To: Nilsson, Claes1
> Cc: Marcos Caceres; public-sysapps@w3.org
> Subject: Re: Sockets, was Re: [Raw Socket API]. New version separating
> UDP and TCP interfaces
> 
> On Mon, Feb 25, 2013 at 2:17 PM, Nilsson, Claes1
> <Claes1.Nilsson@sonymobile.com> wrote:
> > 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/n
> > sIDOMTCPSocket.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?
> 
> I suspect SSDP multicast is not supported, but it would be pretty easy
> to add.
> 
> However the main difference that I wanted to highlight is the general
> flow of the API, rather than the various flags that are supported.
> 
> It feels to me a lot like the current proposal has simply taken a
> synchronous API, like posix, and turned it asynchronous by making all
> functions take a callback argument.
> 
> I think we need bigger changes in order to create a good asynchronous
> API. In particular:
> 
> * Use event handlers or callbacks which automatically fire when there
> is incoming data. Having to poll through asynchronous calls to read()
> feels awkward.
> * Let the API manage buffering of outgoing data.
> 
> These are the parts of the mozilla proposal that I think is interesting
> to look at. I.e. this is where I feel like the mozilla proposal feels
> much more like javascript and less like asynchronous posix.
> 
> > 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.)
> 
> First off, I don't really understand how to do all of these steps with
> the current TCPSocket proposal. It looks like you have to do something
> like the following if you want a callback for each incoming
> connection:
> 
> function setUpServer(maxConnections, localAddr, localPort,
> successCallback) {
>   var socket = new TCPSocket();
>   socket.bind(function() {
>     socket.listen(function() {
>       socket.accept(function() {
>         setUpServer(maxConnections, localAdd, localPort,
> successCallback);
>         successCallback(socket);
>       }
>     }, localAddr, localPort, maxConnections)
>   }, localAddr, 25);
> }
> 
> Is this correct? This seems like we can improve it. First off, should
> we even allow specifying which local address to accept incoming
> connections on? That seems like something that's rarely needed for
> client side applications, and none of the listed use cases seem to
> require it.
> 
> How about simply something like this instead:
> 
> function setUpServer(maxConnections, localPort, successCallback) {
>   var server = new TCPSocketServer(maxConnections, localPort);
>   server.onincoming = function(e) {
>     successCallback(e.connection);
>   }
> }
> 
> Of course we also need to create a system message based solution so
> that applications can act as servers without having to constantly be
> running. But lets start by simplifying the current feature set.
> 
> / Jonas

Received on Thursday, 28 February 2013 15:51:06 UTC