From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) by sourceware.org (Postfix) with ESMTPS id CECB33858025 for ; Thu, 15 Apr 2021 11:49:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CECB33858025 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 (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MjSHc-1lvqur2PxC-00kx47 for ; Thu, 15 Apr 2021 13:49:11 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 6ACF4A807DB; Thu, 15 Apr 2021 13:49:10 +0200 (CEST) Date: Thu, 15 Apr 2021 13:49:10 +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:vNeSAtGZvpPFL6Tr6/z3cGFkUVEVW9a76nHVupf4rsax6Q3ptii 9i+2RZViRwGKJ99bpef79VqX1Yy3fJ0WIS5ALf3vgKxzISFUBbk2pjAvnGtf6TO+/fXMFq4 nOHZAvCq+8fpbzkJg1p+5+PE74iUVXMt2kuKhZmcAKR0HAyy/ABTu0N56lklNrc9t4LthPy LXmMoPLHIqJdky1Rc68mQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Zt/nOXxSYgM=:pB4340Tdz04saiRuVj3h3M TMWGMmjNvr3kqLgy68/LsuFnruIPTYJdEfLFHlL3dH2b1gOK2fB9yyQ+7oZtQY7qpo6mWz7EF h9T7V3mGbo45/24YcdKa8Abe/C7Wy3mQ9AGoeN9YH3RT3m8xcroIvstmWZCcZCqs6wDa/Ypuu AqOD9OqanMyyVYeYrDytxcElioYgxg3xFlOxA1Za3sxSW68k1iygEbDnp4zbWJOHbq/wWvBuE RBzqFdyl9wmyD4kQkAOY59x5DIC7SRfRB+PEG6YbiXacAz6EZDB2EplLrNaMMyCrDOGYi75ax WK9SQ3l+Aijz15UkCpsy/5xYaQYLrWi+yL/H7qMIr2dQFFrbvRCCsuIqddOUfXfwISaHposSA 2/x5irefiexIJoe0+DEzfvU/3Yhek+Kur1F4/rY3JmFnfQ1u/uvWbDKIzvDEdSM1+uEYFOpZM ALgcmMDt9vZyLosWUR+E0SHYXnDsGcmUilJIYLKBon5/KAy3yBDZaaPbUuGQ5qezvmcesBoED Nqu36IpmmwO3HUd/9sWhb0= X-Spam-Status: No, score=-100.8 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, 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 11:49:16 -0000 Hi Ken, On Apr 14 12:15, Ken Brown wrote: > Hi Corinna, > > This is a follow-up to > > https://cygwin.com/pipermail/cygwin/2021-April/248284.html > > I don't know if you've been following that thread, but two serious problems > with datagram sockets (on the topic/af_unix branch) have shown up. > > 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! > 2. There's no way for select to test whether a datagram socket is ready for > writing. That's because we can't know whether a connection to a > hypothetical peer's pipe will be possible. According to Stevens, the issue > *should* be whether there's space in the socket's send buffer. But our > sockets don't have a send buffer until they connect to a pipe. Even then, there's no guarantee a send will succeed, given that select/send are not running atomically. However, we *could* for a start always return success from select for this scenario. If we have a nonblocking socket, it should fail opening the pipe and return EGAIN, which is perfectly fine. If we have a blocking socket, it could block on send, which is perfectly valid, too, because of the non-atomicity. Or am I missing something? > I think the solution to both problems is for Cygwin to maintain a send > buffer for datagram sockets. Does that seem right, or do you have another > idea? In theory the send buffer should be a shared buffer between all peers, so this could be constructed as a shared ring buffer, accessible from af_unix_shmem_t. But then again, this introduces a security problem, so that's not a good idea. So, process-local buffers. But you also have the problem how to empty the buffer. Do you start a new thread which checks if the pipe is getting available and if so, sends the buffer content? In which process? And what do you do if there's still data in the send buffer when the process exits? This is annoyingly complicated and error-prone. 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. Corinna P.S.: Idle musings... The only other implementation of AF_UNIX sockets using named pipes on Windows I know of (U/WIN) implements the gory details as part of their priviledged server process, i. e., their equivalent of cygserver. The difference is that the entire system is based on this server process, so the U/WIN processes don't run at all if that service isn't running, quite unlike Cygwin. Requiring a server running just to allow AF_UNIX sockets to work seems a bit off for us... Having said that, maybe the idea to implement AF_UNIX sockets as named pipes is... outdated? Roughly 90% of our users are running a W10 version supporting AF_UNIX sockets natively (albeit missing native SOCK_DGRAM support). Perhaps it's time to switch...?