Re: Problems with the (new) implementation of AF_UNIX datagram sockets

[Mark Geisert <mark@maxrnd.com>]

Ken Brown wrote:
> On 4/15/2021 9:58 AM, Corinna Vinschen wrote:
>> On Apr 15 09:16, Ken Brown wrote:
>>> On 4/15/2021 7:49 AM, Corinna Vinschen wrote:
>>>> On Apr 14 12:15, Ken Brown wrote:
>>> [...]
>>>>> 1. Writing will block until a connection to the peer's pipe can be
>>>>> made.  In particular, if there are two consecutive writes with the
>>>>> same peer, the second one will block until the peer reads the
>>>>> first message.  This happens because the peer's pipe is not
>>>>> available for the second connection until the peer disconnects the
>>>>> first connection.  This is currently done in recvmsg,
>>>>> and I don't see a straightforward way to do it anywhere else.
>>>>
>>>> I'm a bit puzzeled.  The idea for datagrams was to call open/send/close
>>>> in each invocation of sendmsg.  Therefore the pipe should become
>>>> available as soon as the other peer has sent it's data block.  The time
>>>> a sendmsg has to wait for the pipe being available should be quite short!
>>>
>>> Unfortunately, the pipe isn't available until the server disconnects.  I
>>> observed this in practice, and it's also documented at
>>>
>>> https://docs.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-disconnectnamedpipe 
>>>
>>>
>>> "The server process must call DisconnectNamedPipe to disconnect a pipe
>>> handle from its previous client before the handle can be connected to
>>> another client by using the ConnectNamedPipe function."
>>
>> d'oh
>>
>>> [...]
>>>> Another idea might be to implement send/recv on a DGRAM socket a bit
>>>> like accept.  Rather than creating a single_instance socket, we create a
>>>> max_instance socket as for STREAM socket listeners.  The server side
>>>> accepts the connection at recv and immediately opens another pipe
>>>> instance, so we always have at least one dangling instance for the next
>>>> peer.
>>>
>>> I thought about that, but you would still have the problem (as in 1 above)
>>> that the pipe instance isn't available until recv is called.
>>
>> There always is at least one instance.  Do you mean, two clients are
>> trying to send while the server is idly playing with his toes?
> 
> Yes.  That was essentially the situation in the test case attached to
> 
>    https://cygwin.com/pipermail/cygwin/2021-April/248210.html
> 
> It was actually one client sending many messages while the server was playing with 
> his toes, but the effect was the same.

Sending datagrams between processes on the same system could be thought of as 
similar to sending/receiving messages on a POSIX message queue.  Though the mq_* 
man pages make it seem like mqs are intended for within-process messaging.  But if 
a datagram receiver created a message queue that datagram senders could open, 
couldn't that provide buffering and allow multiple clients?  Kindly ignore if insane.

..mark