Add TCP port information to NetAddr

[bgola]

Currently it is not possible to directly access an open TCP socket from sclang. This RFC proposes a way to access the metadata of the socket created when calling NetAddr.connect method so the user can listen to messages coming back from that socket.

[muellmusik]

I'm not so sure about the semantic drift of this. A NetAddr broadly models a particular endpoint, not a connection. (I admit it's slightly messy, but I'm not sure we should make it more so) Alternative approaches:

1. connect() takes a connectHandler argument, which is passed the port on success.
2. Add the ability to query or receive the socket after connecting, returning some sort of Socket object. (currently it just stores a pointer in that field). This might make sense if there's other behaviour/introspection we'd like.

[bgola]

@muellmusik agreed.

The Socket object should be a second proposal I would add in a next RFC. That is because currently sclang is only able to send / receive OSC messages, so having access to a Socket object would IMO mean a lot of extra work. I don't think it would make sense to have such object and still not be able to open local TCP port for accepting incoming connections or be able to send / receive any sort of bytes through that socket (and all other things that a Socket object should/could do). So for now having just the port and/or some other attributes would be nice.

I have no preference between having NetAddr.tcpRecvPort or receving the port as the connectHandler.. Even tho I think it adds some unnecessary complexity for users who are not familiar with callbacks (but sclang is full of callbacks anyway, so it wouldn't be such a big issue)

[muellmusik]

So for now having just the port and/or some other attributes would be nice.

I'm totally sympathetic to reluctance to add a lot of stuff just to get a particular feature for now. That does need to be balanced though against the additional technical debt and complexity of adding multiple ways of doing the same thing, especially if we think a Socket object is the ultimate way to go. There's been some enthusiastic talk of adding WebSocket support, so perhaps it would be most productive to join forces and think about a broader network implementation. For myself I'd rather see an initially incomplete version of it 'done right' (if we can agree on that :-) than 1.5 times what we ultimately need.

(but sclang is full of callbacks anyway, so it wouldn't be such a big issue)

The question I guess is how to deal with failures. Another approach could be to optionally request a port in connect() a la openUDP. We could return the port or a NetAddr if successful and nil if not. There is a small chance that this would break a small amount of code, though I suspect very little if any as it would only matter if people were relying on connect returning the instance.

[bgola]

@muellmusik I am totally up for a broader network implementation and also very interested in WebSocket support. So yes, would make sense to have an initial Socket object for now. But then I'm not the most experienced in SC development to propose how that should be implemented. On the other hand, I think the way this NetAddr.connect / TCP support is really incomplete so would not hurt to have this "fixed" for now until we come up with a full network implementation.

But as I said, I am happy with both. I would just like to know what port was used to send the message so I can register the proper callbacks for that message (without the need to include things on top of the application protocol like the randomId in OSCRouterClient).

Thanks for the feedback :)