This bit of functionality is critical for RubyDNS which.. uses UDP Sockets and requires them to work consistently, unlike UDPSocket#recvmsg which is a bit of an oddball.

I have to admit I'm not familiar with the "recv" set of socket functions. What we have implemented today is largely just using "read" and simulating other parameters to "recv" and "recvfrom".

The main challenge is mimicking these lower-level socket APIs on the JVM, where we have only high-level APIs that hide access to the actual file descriptors or the lower-level operations. We've managed to fake it well enough for the standard socket types, but when you get to more unusual sockets we still struggle a bit.

So, to clarify a few things.

• recv/recvfrom/recvmsg are used mostly with bare Ruby "Socket" instances or other connection-free sockets like UDP and UNIX, is that generally true? In other words, is it common to see someone using these functions with a TCPSocket?
• It's unclear to me what the difference is between a read and a recv, except perhaps that the recv works on connectionless sockets?

Supporting the general case of recv on all types of sockets may not be doable with Java's APIs, but a specific goal of getting enough of Socket#recvmsg to work for DNS should be possible.

I have to admit I'm not familiar with the "recv" set of socket functions. What we have implemented today is largely just using "read" and simulating other parameters to "recv" and "recvfrom".

read is a more generic operation on a file descriptor than recv or recvfrom which are specific to sockets. Generally speaking you can use read on a socket but you get less information, e.g. recvfrom will also give you the address the packet came from so you can reply.

The main challenge is mimicking these lower-level socket APIs on the JVM, where we have only high-level APIs that hide access to the actual file descriptors or the lower-level operations. We've managed to fake it well enough for the standard socket types, but when you get to more unusual sockets we still struggle a bit.

Java has DatagramSocket and DatagramPacket which should be sufficient to implement this API.

recv/recvfrom/recvmsg are used mostly with bare Ruby "Socket" instances or other connection-free sockets like UDP and UNIX, is that generally true? In other words, is it common to see someone using these functions with a TCPSocket?

You will normally use sendto on UDP socket in order to specify the destination. Similarly, you would normally use recvfrom to know where the UDP data was received from.

UDP sockets can be connected.

It's unclear to me what the difference is between a read and a recv, except perhaps that the recv works on connectionless sockets?

https://stackoverflow.com/questions/1790750/what-is-the-difference-between-read-and-recv-and-between-send-and-write

Supporting the general case of recv on all types of sockets may not be doable with Java's APIs, but a specific goal of getting enough of Socket#recvmsg to work for DNS should be possible.

That would be great.

Bump.

So, I assume the API you need to use in Java is DatagramSocket? Which probably means that it's even more likely you'll need to re-implement Socket to multiplex between ServerSocket, ClientSocket, and DatagramSocket, or depend on some other API.

#4748

Is there some reason why we can't merge this?

Bump :)

Sorry, this slipped through for too long. Marking for 9.2.1.

That would be awesome.

Could this be updated to the current code base? Thank you!