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

Conversation

Projects
None yet
3 participants
@ioquatix
Copy link
Contributor

ioquatix commented Jun 23, 2017

  • 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?

Rename readmsg to recvmsg
* Fix inconsistency of naming w.r.t. MRI.
@ioquatix

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor Author

ioquatix commented Jul 31, 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".

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

This comment has been minimized.

Copy link
Contributor Author

ioquatix commented Dec 12, 2017

Bump.

@ioquatix ioquatix referenced this pull request Dec 12, 2017

Merged

Travis: jruby-9.1.15.0 #175

@ioquatix

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor Author

ioquatix commented Jun 9, 2018

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

@ioquatix

This comment has been minimized.

Copy link
Contributor Author

ioquatix commented Jun 29, 2018

Bump :)

@headius

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor Author

ioquatix commented Oct 6, 2018

That would be awesome.

@BanzaiMan

This comment has been minimized.

Copy link
Member

BanzaiMan commented Oct 6, 2018

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

@headius headius merged commit e5ac6dd into jruby:master Oct 11, 2018

1 check failed

continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.