RFC: udp recvfrom

[ihnorton]

Fixes #8901 (also ref #5772). @Keno

I'm open to suggestions on better ways to handle the IP4/6 duality. (another approach would be to store the binding address type in UDPSocket and branch based on that)

Not really sure what the overhead is for adding these function calls inside the callback. The issue is that the the addr::Ptr{Void} argument is only valid for the life of the callback, which necessitates deciding what it is pointing to and copying that out.

cc @jech

[ihnorton]

This PR would add the following export: recvfrom(::UDPSocket) -> (addr, data) where addr will be either IPv4 or IPv6 depending on the source host. Any suggestions or objections?

A possible alternative would be to have two functions: recvfrom / recvfrom6.

(edit: re-worded the above comment to make clear what "any suggestions/objections?" is referring to).

[jech]

This PR would add the following export: recvfrom(::UDPSocket) -> (addr, data)
where addr will be either IPv4 or IPv6 depending on the source host. A
possible alternative would be to have two functions: recvfrom / recvfrom6.
Any suggestions or objections?

Just a single function, please.

-- Juliusz

[ihnorton]

I wanted to know if there is any performance difference from the additions to _uv_hook_recv. This is my (admittedly unsophisticated - suggestions welcome) test setup:

julia> @async begin
           s = UDPSocket()
           bind(s, ip"0.0.0.0", 10000)
           while true
               b = recv(s)
           end
       end

On master:

isaiah@titan:/cmn/jldev/test$ iperf -u -c 127.0.0.1 -p 10000 -b 10G -t 30
------------------------------------------------------------
Client connecting to 127.0.0.1, UDP port 10000
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 127.0.0.1 port 56863 connected with 127.0.0.1 port 10000
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-30.0 sec  2.82 GBytes   808 Mbits/sec
[  3] Sent 2060762 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

With this PR:

isaiah@titan:/cmn/jldev/test$ iperf -u -c 127.0.0.1 -p 10000 -b 10G -t 30
------------------------------------------------------------
Client connecting to 127.0.0.1, UDP port 10000
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 127.0.0.1 port 38491 connected with 127.0.0.1 port 10000
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-30.0 sec  2.82 GBytes   808 Mbits/sec
[  3] Sent 2061876 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

(repeated several times with consistent results)

[ihnorton]

So, that being the case, I'll merge in a day or so if there are no objections. (appveyor failure is unrelated)

[coveralls]

Changes Unknown when pulling c360a8a on ihnorton:udp_recvfrom into * on JuliaLang:master*.