You'd do best to not look under the covers of Sockaddr_in and friends on JRuby; we're not using native structures, so they're likely going to differ from what the platform says.

The difference in your case may be a real bug, but I find the exposure of Sockaddr_in and friends in the Ruby API to be serious code smells. It's usually difficult to write code using it that works across platform, and it's forcing an arbitrary, hidden implementation detail on users of the library.

That said, I know we should at least be consistent. Why are you looking at the Sockaddr_in bytes at all?

I guess actually what I really wanted was Socket.unpack_sockaddr_in("\x02\x00\x00P\x7F\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00")
but it expects those first two bytes to be switched. The reason I'm trying to use that is that I'm reading in Linux auditd logs and one of the fields is saddr which is in byte form. I would like to extract the port and ip so that I can search on it in elasticsearch. I was trying to transform the data in a logstash ruby filter using unpack_sockaddr_in and ran into this issue. So both sockaddr_in and unpack_sockaddr_in seem to want those first two bytes switched, but the incoming data matches the expected behavior of ruby. For right now I just flip the bytes in my filter and it works, but felt like this should behave similarly to ruby.

@ChuckWoodraska Ok, that makes things a little clearer for me. So the short answer is that you won't be able to use JRuby for this right now without a platform-appropriate sockaddr_in.

The long answer is that we're probably going to need to move toward native sockets soon anyway. That will probably be easiest if we can adopt the FFI-based socket library that @yorickpeterse wrote, but it will take some work to get there since it depends on another Ruby VM's internals.

Another option, which isn't super attractive but probably less work, is to simply do a better job of outputting proper sockaddr_in for each platform. As far as I can tell, none of our output is right on macos, and it doesn't appear to be right for you either.

Ping @enebo...there's many reasons for going to native sockets, but I'm not sure of the right path. A jnr-socket library would be very useful for way more than just JRuby, but we'd be doing a lot of the work by hand...unless we can get jnr-clang working.

@headius yeah navigating the proper path here is likely the path of least support but still 100% correct. I agree that jnr-something would work but it would be quite a bit of ongoing support. ffi does not really reduce that work much but yorick's library would cut out quite a bit of the initial work. The support would be large either way though? Being in Ruby would likely allow more people to PR? I lean slightly to Ruby FFI vs JNR but only because so few people want to support our JNR stuff.

Another question is whether we can really use these byte addrs at all right now? I mean we are providing them because MRI does but can how can we use them. I understand the reporter just wants to compare them so if we just did an ffi call for just Sockaddr_in what would break? I mean both ways so you can convert those bytes back to something our Java impl can use.

@enebo The uses I've seen for these APIs mostly just want to capture some structure representing the addrinfo contents. I believe this is intended to be replaced by the proper Addrinfo class, of which we have implemented a decent portion.

The case reported here is somewhere in the middle; @ChuckWoodraska wants to be able to read in a log from auditd, which inserts some of addrinfo into the log as an encoded representation of the platform-local sockaddr_in byte array.

The bytes we present are...unusual. I'm not sure what they match now. These structures could very easily have changed from 32 to 64 bit as well. In any case, nobody seems to understand them but us, so we can't read in those log entries.

I think for uses of addrinfo and sockaddr_in and sockaddr_un and friends from within Ruby, the direction is toward using the Addrinfo abstraction rather than passing around the byte arrays. But integrating with other socket utilities on the same system may always require the appropriate bytes. 🙄

This would be fixed by supporting the FFI-based rubysl-socket library, but probably not otherwise.

I have opened #6334 for that goal, though I'm not sure when we will get to it.

Where does rubysl-socket etc live these days? Not at https://github.com/rubysl/ anymore.

Answering my own question - now at https://github.com/rubinius/ruby-stdlib/tree/master/lib/socket.