From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) by sourceware.org (Postfix) with ESMTPS id D1A7B3857C73 for ; Thu, 15 Apr 2021 13:58:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D1A7B3857C73 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=corinna-cygwin@cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MYvHa-1l2DwA3peC-00UrsI for ; Thu, 15 Apr 2021 15:58:18 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 95F28A80DA9; Thu, 15 Apr 2021 15:58:17 +0200 (CEST) Date: Thu, 15 Apr 2021 15:58:17 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: Problems with the (new) implementation of AF_UNIX datagram sockets Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:LcVdrjVYM5FIqUoQoUchwHuztctiDt7c0rWoOnJBWuAg9CPFoSm OgxTBkkGYrLh7Z7YPnXpurzCGOC6NjgixtxXkh8mdTQkZZeL2JewOj9u5vF7xbIYdY8YoAE u2j64lnKsTlp0R1U0/dvkEC9U7CVLyymZ3FABTllD0O6XxZESTBojliVH7qN2+OmxYmEAON N0zjU6KaKagOKatle+Ayw== X-UI-Out-Filterresults: notjunk:1;V03:K0:pMCWU3Pf6Q8=:7o2QLYTG4+URLPSRGDgXOw vZncXgiVxWdtF4Q2z39hxRmi+z4h4yBldKLOIbln6A6s782WxZXu9w4bP5tGtJq9Pt0xbtjKl rPo3kV8v1IkQ5rjEgmNNw6uNs+re3ljyQq0/S9yUE+xla90GzH4GMY9FVyzT23PZZlg4LCxUj XdR0x8nmNghgKADTXaFUQ9QeOvB9uH8oVS+oUeXtU9w+H0yz+hO8L3RR+qFVccdIEeUCag6mj AzGVo/TaXUM1Y4EdeMnH5l/dr9q8V5P9uerV2kCVZVmZjeoNJimuBss6RyDAt+Buq2uIwOp8W EcSd5dsf7zBU1vbU+LdxOAELEYT2yLlCNHzrmSi7WcAmhSYP0PzuTe7WTTR2PXV/Wmk5QElHe 7Ka3omitac4S/8CRRttR/l44RvOY4GAoh09n607NG8mumkvY6f//4zF5Sf/QB9DowWmCy7Lyz pKhT03tsOeLItzrSnkU9o6qj6Yzb7LtYAPnnTkoMW0NJwee4Htpu3Vi1FrhciUoZEJUs+Ozvd u3cWqx9x2zHL5Dw7Ndn/+I= X-Spam-Status: No, score=-101.0 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham 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 13:58:22 -0000 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? Corinna