unix-socket icon indicating copy to clipboard operation
unix-socket copied to clipboard

Add SOCK_SEQPACKET support

Open vi opened this issue 9 years ago • 6 comments
trafficstars

Obviously, sequential packet sockets should support #4 and #5.

They also have listener/connection, unlike datagram sockets.

vi avatar Dec 28 '15 15:12 vi

Servo's ipc-channel uses SEQPACKET sockets which might provided some inspiration on the implementation.

The API's probably going to be a bit weird due to the need to indicate packet boundaries.

sfackler avatar Dec 29 '15 03:12 sfackler

Aren't usual traits Read and Write not enough?

Each write corresponds to one read at the other side. Reading with too small buffer is Err. There can be Ok(0) from read and it's not a failure or EOF.

I.e. existing code can happen to work even if substitute SOCK_STREAM with SOCK_SEQPACKET.

Alternatively reuse part of API from UnixDatagram, possibly extracting common things into traits.

vi avatar Dec 29 '15 09:12 vi

Ah, I was expecting SEQPACKET records to be specified via MSG_EOR in sendmsg and recvmsg and be allowed to split across read/write calls, but they apparently behave more like connected datagram sockets: http://stackoverflow.com/questions/3595684/why-do-i-not-see-msg-eor-for-sock-seqpacket-on-linux.

Seems like an API similar to UnixDatagram without the unconnected variants would work then. I would like to make sure that SEQPACKET behavior is roughly consistent betwee Linux, OSX, BSDs, etc though.

sfackler avatar Dec 29 '15 15:12 sfackler

Just came here to enter an issue for seqpacket :) Yea, SEQPACKET's API semantics are connection oriented like stream, but datagram oriented. In my testing, on Linux I have found that seqpacket connections support either the send or the sendmsg functions. So it can be treated basically as a stream API, with the understanding that payloads are never sent via multiple messages.

Looking at the lib, we could probably get away with just adding an option or an alternate constructor to UnixStream.

Whether the consensus is to make a UnixSeqpacket struct and factor out the common functionality, I am happy to implement either.

rrichardson avatar May 22 '16 19:05 rrichardson

I think it'd make more sense as a separate UnixSeqpacket struct for now, but yeah, please do!

sfackler avatar May 23 '16 20:05 sfackler

I forgot one rather important thing, this PR depends upon rust/libc PR https://github.com/rust-lang/libc/pull/300

Since libc doesn't presently contain SOCK_SEQPACKET

rrichardson avatar May 27 '16 04:05 rrichardson