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

Hi again Ke-Fong,

Thanks for your additional comments. I am replying inline below but we will discuss more in Madrid.

Best regards
  Claes

> -----Original Message-----
> From: Ke-Fong Lin [mailto:ke-fong.lin@4d.com]
> Sent: den 5 april 2013 17:11
> To: Nilsson, Claes1; public-sysapps@w3.org
> Subject: 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.
[Claes] Yes, let us discuss in Madrid.
> 
> [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.
[Claes] Yes, that is one option and might be clearer for developers. It is ok for me to do this change.
> 
> >Are there any use case for leaving a multicast group?
> 
> If you do not want to receive packets from the multicast address
> anymore.
[Claes] My thought was that the developer had to create a new socket if multicast wasn't going to be used more. However, if we have an explicit joinMulticastGroup() then I guess that we should have leaveMulticastGroup() as well.

By the way, I haven't specified a "close()" or destroy() method for UDP Sockets as there is no connection setup. A developer can always stop listening to incoming data by calling suspend(). Then JavaScript garbage collection will handle removal of unused sockets objects. Do you think that this is sufficient? Or do we need a destroy() or similar method for UDP Sockets?
> 
> [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_callb

> ack).
> 
> 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.
[Claes] We have a solution that fulfills what we really need for Web System Apps that is as simple as possible for developers. To be discussed in Madrid.
> 
> >> 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.
[Claes] Could you elaborate on how this attribute is set and used by developers.
> 
> >- 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.
[Claes] If there are use cases this is ok for me.
> 
> >* 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.
[Claes] So you recommend that the developer should be able to set ttl of packets sent? Should we have a ttl attribute in UDPOptions? Default value?
> 
> >- 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.
[Claes] Yes, we can add that if it helps developers. If we do that we can also have common send() and onreceived at the Raw Socket level.
> 
> >* 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.
[Claes] ok
> 
> > - 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.
[Claes] We can add if there are use cases for it in a Web System App.
> 
> 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 Sunday, 7 April 2013 09:39:52 UTC