From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 3A4803857C52 for ; Sat, 17 Apr 2021 02:54:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3A4803857C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 13H2sP2x073609 for ; Fri, 16 Apr 2021 19:54:25 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.20]" via SMTP by m0.truegem.net, id smtpd2mwqpw; Fri Apr 16 19:54:22 2021 Subject: Re: Problems with the (new) implementation of AF_UNIX datagram sockets To: cygwin-developers@cygwin.com References: <1cfa2d74-eaa4-e3be-9fa5-519952026aef@cornell.edu> <9db1d7ab-fe47-6f8c-db65-c9fe5e18952b@maxrnd.com> From: Mark Geisert Message-ID: <8cec7dd0-5a0a-1e38-66d0-3c92854d1a69@maxrnd.com> Date: Fri, 16 Apr 2021 19:54:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2021 02:54:38 -0000 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