The unreliability of AF_UNIX datagram sockets

[Corinna Vinschen]

On Apr 29 12:44, Ken Brown wrote:
> On 4/29/2021 11:05 AM, Corinna Vinschen wrote:
> > So maybe we should really think hard about the alternative
> > implementation using POSIX message queues, I guess.  And *if* we do
> > that, this should be used likewise for STREAM as for DGRAM sockets, so
> > the code is easier to maintain.  Obvious advantage: No problem with
> > older OS versions.  And maybe it's even dirt easy to implement in
> > comparison with using other methods, because the transport mechanism
> > is already in place.
> 
> Yes, I don't think it should be too hard.  The one thing I can think of
> that's missing is a facility for doing a partial read of a message on the
> message queue.  (This would be needed for a recv call on a STREAM socket, in
> which the buffer is smaller than the payload of the next message on the
> queue.)  But this should be straightforward to implement.
> 
> Alternatively, I guess we could read the whole message and store the excess
> in a readahead buffer.

Alternatively, we could introduce a new, internal-only method into the
POSIX msq code, one that reads a partial message, reduces the message
to the remainder and keeps it on the queue head...

> On 4/29/2021 11:18 AM, Corinna Vinschen wrote:
> > While searching the net I found this additional gem of information:
> >
> > Native AF_UNIX sockets don't support abstract sockets.  You must bind to
> > a valid path, so you always have a visible file in the filesystem.
> > Discussed here: https://github.com/microsoft/WSL/issues/4240
> >
> > We could workaround that with our POSIX unlink semantics, probably,
> > but it's YA downside
> 
> Agreed.  The more features that are missing from native AF_UNIX sockets, the
> less appealing they become.
> 
> Concerning abstract sockets, would we still have an issue if we used message
> queues?  Wouldn't there be a visible file under /dev/mqueue?  Or is there a
> way around that?

Good point!  There's no way around that yet.  In theory that shouldn't
matter because /dev/mqueue is kind of a "virtual" path, even if Cygwin
implements the queues as real files.  But that's setting the perspective
straight, we're in fact no better than the native AF_UNIX here ¯\_(ツ)_/¯

Probably we should actually add an internal-only way of creating
non-file backed mqueues for the purpose of adding abstract sockets.


Corinna