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

Hi again,

Just a few more comments before Madrid.

[interfaces]
>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?

It's just a matter that browser  (or any non-privileged application) won't be able to instantiate UDPSocket, TCPSocket, and TCPServerSocket objects. But perhaps it's better to live that to security experts.

[multicast]
>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().

I think it would be better if that requires an explicit action from the user.

>Are there any use case for leaving a multicast group?

If you do not want to receive packets from the multicast address anymore.

[buffering]
>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.

From a "logical" point of view, there are three things :

1) The packet has been buffered by the Raw Socket API.
2) The packet has been buffered by the OS. (ondrain == all data buffered by API has been buffered  "sent" to the OS)
3) The packet has been effectively sent on the network (NodeJS seems to allows to set up a callback for that : http://www.nodejs.org/api/net.html#net_socket_write_data_encoding_callback).

Mozilla is spec is not very precise on limits. We may allow the user to set up (per socket) the API's send buffer size (up to a certain maximum) and have a buffer usage "threshold" (per socket) set as 75% (by default) for "false" hint triggering. Setting this threshold to zero, the send() function will return true if the packet has been directly buffered to the OS. That's not as good as NodeJS's write(), but good enough.

>> 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:

Yes, it is basically the same idea.

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

It's for the ease of the developer.

>- url: Is this needed? Use cases?

It's for compatibility with WebSocket. Also, the user may want to specify an address "unresolved" like "myhost.server1.local". Whereas addresses will be converted to "resolved"  to "192.168.4.64".
We can keep that in "textual" name in the url attribute.

>* UDPSocket:
>- ttl attribute: Use cases?

From a general point of view, it's a "raw" socket API, so basically, it's about exposing all (or a  maximum of) functionalities.
In my previous job, working on video streamers, we usually set the TTL to the maximum.

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

It's for the ease of developer. Berkerley's socket connecto() allows that. Even if a UDP socket allows you to send to any valid address, I guess there would be a lot of case when the UDP socket is only sending to one peer.

>* 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.

Microsoft Exchange doesn't support "direct" SSL connections. You must connect using a normal socket and then upgrade to SSL. It was the main reason for supporting that feature in Wakanda.

> - halfClose (): Use cases?

Same as for TTL attribute, it's a functionnality that should be exposed. The end developer would have no way to avoid problem if it needed that kind of feature.

Best regards,




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

Received on Friday, 5 April 2013 15:08:45 UTC