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 0DDEC3858031 for ; Thu, 15 Apr 2021 23:50:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0DDEC3858031 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 13FNoPXd065598 for ; Thu, 15 Apr 2021 16:50: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 smtpdzdtnWQ; Thu Apr 15 16:50:24 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> From: Mark Geisert Message-ID: <9db1d7ab-fe47-6f8c-db65-c9fe5e18952b@maxrnd.com> Date: Thu, 15 Apr 2021 16:50:23 -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: <1cfa2d74-eaa4-e3be-9fa5-519952026aef@cornell.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 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: Thu, 15 Apr 2021 23:50:30 -0000 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