Expensive to synchronously set TCPSocket.localAddress when using default local address

[sicking]

Currently the API requires the implementation to be able to synchronously get the default local address. Consider the following code:

var tcp = new TCPSocket("123.123.123.123", 4711);
console.log(tcp.localAddress);

This forces the implementation to block the execution of the TCPSocket constructor until the implementation has read the default local address, something which likely requires some amount of IO.

I propose that the TCPSocket.localAddress and TCPSocket.localPort are set to whatever explicit value was passed to the constructor, or null if no value was set.

Same applies to UDPSocket.

[ClaesNilsson]

This is ok if there are no use cases for an application to retrieve the IP-address of the default local interface and/or the randomly selected local port number.
If there are use cases for above then one option is to use an attribute with the "open" event that provides to interface and port.

[ClaesNilsson]

Ok, so this means that the socket constructor sets the TCPSocket.localAddress and TCPSocket.localPort attributes to null if no explicit values were set with the options argument's localAddress and localPort members. Otherwise these attributes are set to the values given by these members.

[anotherlin]

How about that : localAddress and localPort are set to both NULL if not specified by constructor, or to values given to constructor if any. When in "open" readystate, they are both guaranteed to be set to actual values. In particular, when "onopen" callback is serviced localAddress and localPort contain the actual values.

Note that we need to add a mean to get a list of all available network interface(s).

[ClaesNilsson]

I think that this is a reasonable solution. WDYT Jonas?

The ability to get a a list of all available network interface(s) sounds like a separate API.

[anotherlin]

For the list network interface(s), I think it should be part of the raw-socket API.
It doesn't have to be much :

http://www.nodejs.org/api/os.html#os_os_networkinterfaces

For NodeJS, that's just a function returning an array.

[AMorgaut]

Mounir worked on a W3C network API
http://www.w3.org/TR/netinfo-api/

It provides informations on a specific network but don't expose adress
the Raw Socket API may accept a NetWork information object instead of an adress

There is also the Network Service Discovery:
http://www.w3.org/TR/discovery-api/
which may be taken into consideration for interoperability purposes

[sicking]

Specifically on a socket object, what is the use case for knowing the local IP address? Do a lot of protocols that go over TCP/UDP require sending the local IP address to the other end? Or do they require comparing incoming data to the local IP address? Does anyone have examples of this?

I definitely agree that there should be a way to get the local IP addresses and interfaces. However it still strikes me as odd to make that live on the socket connection object.

So I'd rather that the properties on the connection object simply reflect the values that were passed to the constructor. And then create an API like the node.js one mentioned above.

[anotherlin]

There are two issues:

1. Retrieve the list of available network interface(s). Seems that we agree that we should use an existing API specification or design one inside the raw-socket spec.

2. Being able to retrieve actual localAddress and localPort of a bound UDP or connected TCP socket. Once a UDP socket is bound (bind()) and a TCP socket connected (connect() for client and accept() for server), retrieving the actual local address and local port is just a matter of one syscall : getsockname() (http://pubs.opengroup.org/onlinepubs/009695399/functions/getsockname.html). It's a non-blocking syscall, it either succeeds or fails immediately. I don't see why we can't make that possible.

[ClaesNilsson]

For issue 1, I assume that extending the W3C DAP Network Information API, http://www.w3.org/TR/netinfo-api/, with information on available network interfaces would have privacy implications.
However, we already have a Network Interface API in the charter for SysApps phase 2, http://www.w3.org/2012/sysapps/#future. The charter states that this API will for example list available networks.
So what about keeping the current definition of local address/port for now and then refer to the phase 2 Network Interface API for listing available local networks?

[ClaesNilsson]

Closing and referring to #44 and #36