Problems with the (new) implementation of AF_UNIX datagram sockets

[Mark Geisert]

Corinna Vinschen wrote:
> On Apr 15 16:50, Mark Geisert wrote:
>> 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:
>>>>> [...]
>>>>>> 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.
> 
> Interesting idea, actually.  Message queues already implement a lot of
> what a unix socket needs in terms of sending/receiving data.  The pipe
> would only be needed for credential and descriptor passing, ultimately :)

One might be able to deal with credentials/descriptor passing within the message 
queue by using message priority to distinguish the "message" types.  mq_receive() 
always gives you the oldest, highest priority, message available in the queue.

I'll have to look over the usual DGRAM references again, but OTTOMH if credentials 
are just euids and egids maybe they could be handled as permissions on the file 
backing the message queue.  If the filename (in a particular name space we set up) 
is just the port number one could treat ENOENT as meaning nobody listening on that 
port, while EPERM could result from credentials not matching the file's 
permissions.  Makes some sense but I'm unsure if it covers all needs.

..mark