Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename readmsg to recvmsg #4684

Merged
merged 1 commit into from
Oct 11, 2018
Merged

Rename readmsg to recvmsg #4684

merged 1 commit into from
Oct 11, 2018

Conversation

ioquatix
Copy link
Contributor

  • Fix inconsistency of naming w.r.t. MRI.

Uh, I didn't even look at the code originally, but it seems like it's not even implemented. At least we can fix the name.. but can we fix the implementation too?

* Fix inconsistency of naming w.r.t. MRI.
@ioquatix
Copy link
Contributor Author

ioquatix commented Jun 23, 2017

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.

@headius
Copy link
Member

headius commented Jun 23, 2017

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.

@ioquatix
Copy link
Contributor Author

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.

@ioquatix
Copy link
Contributor Author

Bump.

@ioquatix
Copy link
Contributor Author

ioquatix commented Feb 2, 2018

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

@ioquatix
Copy link
Contributor Author

ioquatix commented Jun 9, 2018

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

@ioquatix
Copy link
Contributor Author

Bump :)

@headius
Copy link
Member

headius commented Oct 6, 2018

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

@headius headius added this to the JRuby 9.2.1.0 milestone Oct 6, 2018
@ioquatix
Copy link
Contributor Author

ioquatix commented Oct 6, 2018

That would be awesome.

@BanzaiMan
Copy link
Member

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

@headius headius merged commit e5ac6dd into jruby:master Oct 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants