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

Hi Claes,

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

John Lyle has sent an interesting email about that, I hope he's there at Madrid.

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

I'd rather think it's better to have an explicit way to do so. For a UDP socket, destroy() would be the equivalent of Berkeley socket's close(socket_descriptor_id).
Garbage collector runs "when it wants", it may be a long time before it actually does the collection, and OS socket descriptors are limited in number (that's a huge a number, but still limited).
Also for the developer, that can be tricky, for WebSocket : http://www.w3.org/TR/2009/WD-websockets-20091222/#garbage-collection

Garbage collection is not done if there is at least a registered  event listener. So all listeners would have to be unregistered and then the socket object must not be referenced anymore.
That's easy to forget or miss.
With a close(), we can leak a JavaScript object but make sure we don't leak a process wide resource.

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

It's automatically set upon creation of the socket depending on the type of address used (IPV4 or IPV6).

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

Default value is OS dependent, retrievable using getsockopt() (or something like that).





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 Monday, 8 April 2013 14:55:46 UTC