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/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?

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 Tuesday, 26 February 2013 19:31:06 UTC