The unreliability of AF_UNIX datagram sockets
Ken Brown
kbrown@cornell.edu
Fri May 21 21:54:37 GMT 2021
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
More information about the Cygwin-developers
mailing list