UDP: testing and documentation

[StefanKarpinski]

#5697 implemented basic UDP support but it is largely untested and entirely undocumented.

[JeffBezanson]

I'm well aware of the very different behavior of UDP, but I still wonder if we want to introduce the new send and recv functions for this. At this point it's pretty rare to add new functions for just one new type. Perhaps we should use read/write, or possibly match the interface of Channels (RemoteRefs).

cc @loladiro

[Keno]

The UDP abstraction is fundamentally different from the stream abstraction and needs to be separated, so I don't think read/write are the right functions to use. The RemoteRef abstraction is a better match, but I'm not sure what the interface would look like.

[StefanKarpinski]

Having higher level common APIs that can work with UDP or RemoteRefs or ZMQ or whatever is a nice extra, but the basic operations for UDP are send and recv.

[JeffBezanson]

I'm also not a huge fan of bind. I don't love that TcpSocket and UdpSocket have no useful constructors. For TCP it's not so bad since a single listen (or connect) suffices, but for UDP right now we seem to need 2 steps.

[Keno]

I considered adding send(ip,data) = send(UdpSocket(),ip,data), but I was afraid that people would just repeatedly call that rather than creating a single socket.

[JeffBezanson]

That seems like a good decision; I like the separation of send and having a thing to send to.

[jakebolewski]

Can this be closed?

[ihnorton]

I added some basic docs. There are UDP tests in test/socket.jl. It seems like the remaining questions were API decisions so this can probably be closed if people are ok with the names now that this has been in use for a while.

[tkelman]

The type itself is still undocumented.