RE : [sysapps/raw socket api]: New version based on Madrid meeting comments and comments from Ke-Fong Lin

Hi Jonas,

> It's still not clear to me how to use the localAddress/localPort arguments for TCPSocket and UDPSocket.
> What are the use cases for these options?

Local address is needed to select which network interface to use. On mobile device, that would be WIFI, 3G, Bluetooth.
Local port is needed for multicast receiving mainly. With TCP, client almost always use a random port selected by OS.

>How will the app know what values to specify for those arguments? Are you expecting that we'll have some additional spec that will provide information about which local addresses are available and where they are connected?

Yes, we've avoided that question currently. No localAddress set, means "default" network interface.
A way to enumerate available interface(s) would be helpful.

>In the ReadyState enum, should we differentiate the two ways that you can have a "halfclosed" connection? I.e. should you be able to tell if the other side has halfclosed vs. if your side has called halfclose? I suspect so.

No, if peer is "half closed" that means it won't (and cannot) send more data but it's still listening. In the meantime, the local host can still read (but won't receive data from peer) and of course send, so it's still "open"  readyState. The new spec has an event to signal that peer has half closed.

>What does the "addressReuse" option do when constructing a TCPSocket? What is the use case?

Re-use option is very important for UDP, this allows several applications to receive data from a multicast group (to use Bonjour for example).
But yes, you're right. It makes no sense for TCP sockets (streaming protocol). I'm not even sure you could do a setsockopt() on a TCP socket.
TCPSocket shouldn't have addressReuse.

>There doesn't appear to be a way to upgrade an existing TCPSocket connection to TLS. Is that something you're still planning on adding?

Yes, I'm working on it with Claes.

>Feedback [1] from our team was that for TCPSocketServer "accept" is a better name than "connection" since "connection" was unclear if it meant "connecting" or "connected". One option is also simply "connect" since that's what's used by Web Workers [2].

"accept" will definitely ring a bell for those used to Berkeley socket accept() function :)
I've no strong opinion regarding naming but yes, "onconnect" would be a great name as it is indeed used by SharedWorker (web workers).

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 Tuesday, 23 April 2013 19:40:14 UTC