RE: [sysapps/raw socket api]: New version to be reviewed at Madrid F2F-meeting

Hi Ke-Fong,

Thanks a lot for your valuable comments!

I am replying the comments one by one:

> I'd rather think we can make the raw socket API more
> "compatible" with WebSocket. Basically, make all socket types,
> including WebSocket but except "server sockets", to derive from a main
> "Socket" parent. Logically, sockets are just receiving and sending.

In my current proposal, http://raw-sockets.sysapps.org/, the structure is:
interface RawSocket : EventTarget 
interface UDPSocket : RawSocket
interface TCPSocket : RawSocket
interface TCPServerSocket : EventTarget

You propose to add WebSockets to this structure by:
interface WebSocket : RawSocket

I guess that this would be possible from a logical point of view. However, the current Web Sockets API is available to web pages running in the normal browser context, while the SysApps Raw Socket API is only available to web applications running in the secure SysApps runtime. There are apparently different security implications on opening up an API for UDP and TCP sockets compared to an API for Web Sockets. So aligning Web Sockets into the same specification as UDP and TCP sockets might be tricky from a security point of view. Could John and other SysApps security experts comment on this?

> * Naming : onreceivetcp, onreceiveudp, sendUDP(), sendTCP() : Because
> we already know what kind of socket we use (UDP or TCP), just call them
> onreceive or send(). TCP or UDP suffixes are redundant I think.

Maybe I was a bit too ambitious in making names clear. As the methods belong to different interfaces we can just have, as you propose, onreceive, send() etc. I'll change that if no one else objects.

> * UDP multicast : Add join/leave multicast group. You won't receive
> multicast packets unless you join the group. Also some routers won't
> relay packets if the sender hasn't joined the group (even if it is
> legal to send to any address using an UDP socket).

I was thinking that joining a multicast group would be done by the API implementation when an IP-address is in the interval 224.0.0.0 and 239.255.255.255 for the UDP socket constructor and send(). 

Are there any use case for leaving a multicast group?

> * Send buffering issues : Send buffers are both system and socket
> implementation dependent. For instance, on Linux, it is easy to set the
> system's buffer size, can notably be made bigger (typical on video
> streamers). Also the socket implementation does buffering
> (bufferedAmount). There is the "ondrain" event when bufferedAmount is
> back to zero. Note that NodeJS, even has the option to set a callback
> to the socket.write() function, which is called when the send()
> effectively send the buffered the data. Having a boolean hint is a good
> idea. Need to be more precise, need to have a way to know where is the
> "threshold" for hint to be true. Or we can act as NodeJS and return
> true when buffered in system memory and false if all or partially
> buffered in user memory.

I think that this has to be discussed at the meeting. The current wording in the specification is basically a copy from Mozillas API and I want to understand the details more on this. See Issue 1 and Issue 2 in the specification.


> I have quite a few suggestions that I've compiled in the attached
> sketch proposal.

It seems as much in your sketch proposal is similar to my latest version even though you have structured it a bit different with more attributes and methods that are similar to UDP and TCP and belong to the "base socket" interface. You also have some added functionality in addition to what already has been mentioned above:

* Socket:

- ipVersion: Doesn't the format of the address parameter define if ipv4 or v6 is used? 

- url: Is this needed? Use cases?


* UDPSocket:

- ttl attribute: Use cases?

- setPeer(): Needed? You can always set address and port to the remote end in the send() method.

- Support for Blob and ArrayBufferView data types: I guess this might be useful.

* TCPSocket

- upgradeToSSL() and event when done: As an example you mention is when some mail servers that start a session as a non encrypted TCP session and then upgrade to SSL. So it seems that we need this.

- halfClose (): Use cases?


Best regards
  Claes

> -----Original Message-----
> From: Ke-Fong Lin [mailto:ke-fong.lin@4d.com]
> Sent: den 5 april 2013 12:17
> To: Nilsson, Claes1; public-sysapps@w3.org
> Subject: RE : [sysapps/raw socket api]: New version to be reviewed at
> Madrid F2F-meeting
> 
> Hi,
> 
> First, let met introduce myself. I'm a colleague of Alexandre Morgaut.
> I'm the developer in charge of implementing the socket API on Wakanda,
> which is a NodeJS compatible. It includes "server" and SSL support.
> I have quite a few suggestions that I've compiled in the attached
> sketch proposal. I'd rather think we can make the raw socket API more
> "compatible" with WebSocket. Basically, make all socket types,
> including WebSocket but except "server sockets", to derive from a main
> "Socket" parent. Logically, sockets are just receiving and sending.
> 
> Here are a few comments on the current proposal on http://raw-

> sockets.sysapps.org/ :
> 
> * Naming : onreceivetcp, onreceiveudp, sendUDP(), sendTCP() : Because
> we already know what kind of socket we use (UDP or TCP), just call them
> onreceive or send(). TCP or UDP suffixes are redundant I think.
> 
> * UDP multicast : Add join/leave multicast group. You won't receive
> multicast packets unless you join the group. Also some routers won't
> relay packets if the sender hasn't joined the group (even if it is
> legal to send to any address using an UDP socket).
> 
> * Send buffering issues : Send buffers are both system and socket
> implementation dependent. For instance, on Linux, it is easy to set the
> system's buffer size, can notably be made bigger (typical on video
> streamers). Also the socket implementation does buffering
> (bufferedAmount). There is the "ondrain" event when bufferedAmount is
> back to zero. Note that NodeJS, even has the option to set a callback
> to the socket.write() function, which is called when the send()
> effectively send the buffered the data. Having a boolean hint is a good
> idea. Need to be more precise, need to have a way to know where is the
> "threshold" for hint to be true. Or we can act as NodeJS and return
> true when buffered in system memory and false if all or partially
> buffered in user memory.
> 
> It is a little bit difficult to discuss specifications through emails,
> I'll be there (along with Alexandre) at Madrid.
> 
> Best regards,
> 
> 
> /* Lin Ke-Fong
>  * Senior Developer
>  * ke-fong.lin@4d.com
>  * +33 1 40 87 92 56
>  */
> 
> 
> 
> 
> Ke-Fong Lin
> Développeur Senior
> 
> 4D SAS
> 60, rue d'Alsace
> 92110 Clichy
> France
> 
> Standard :
> Email :    Ke-Fong.Lin@4d.com
> Web :      www.4D.com
> 
> 
> ________________________________________
> De : Nilsson, Claes1 [Claes1.Nilsson@sonymobile.com] Date d'envoi :
> jeudi 4 avril 2013 15:36 À : public-sysapps@w3.org Objet : [sysapps/raw
> socket api]: New version to be reviewed at Madrid  F2F-meeting
> 
> http://raw-sockets.sysapps.org/

> 
> Updates done are:
> 
> * Clarifications for UDP multicast
> * Error handling detailed at several places
> * For TCPServerSocket added closeServer() method and removed
> maxConnections
> * Misc clarifications at several places
> 
> I am happy for all comments, also prior to the F2F.
> 
> See you in Madrid!
> 
> Claes
> 
> Claes Nilsson M.Sc.E.E
> Master Engineer - Web Research
> Advanced Application Labs
> 
> Sony Mobile Communications
> Tel: +46 705 56 68 78
> sonymobile.com<http://sonymobile.com/>
> 
> [cid:image001.jpg@01CE3149.B6C10600]

Received on Friday, 5 April 2013 14:07:33 UTC