The unreliability of AF_UNIX datagram sockets

[Ken Brown]

On 5/20/2021 3:25 PM, Corinna Vinschen wrote:
> On May 20 09:46, Ken Brown wrote:
>> On 4/29/2021 7:05 AM, Corinna Vinschen wrote:
>>> I think it should be possible to switch to STREAM sockets to emulate
>>> DGRAM semantics.  Our advantage is that this is all local.  For all
>>> practical purposes there's no chance data gets really lost.  Windows has
>>> an almost indefinite send buffer.
>>>
>>> If you look at the STREAM as a kind of tunneling layer for getting DGRAM
>>> messages over the (local) line, the DGRAM content could simply be
>>> encapsulated in a tunnel packet or frame, basically the same way the
>>> new, boring AF_UNIX code does it.  A DGRAM message encapsulated in a
>>> STREAM message always has a header which at least contains the length of
>>> the actual DGRAM message.  So when the peer reads from the socket, it
>>> always only reads the header until it's complete.  Then it knows how
>>> much payload is expected and then it reads until the payload has been
>>> received.
>>
>> I think I'd like to go ahead and try to do this DGRAM emulation in the
>> current (AF_LOCAL) code.  It shouldn't be too hard, and it would solve the
>> unreliability problem while we look for a better way to handle AF_UNIX
>> sockets.
> 
> Yeah, sounds like the way to go for now.

Unfortunately, I ran into a problem.  Trying to emulate DGRAM sockets in STREAM 
sockets breaks the DGRAM send/recv semantics.  For example, WSARecvFrom won't 
return the source address.  I hope I'm just missing something, but I don't see a 
way around this.

Ken