From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) by sourceware.org (Postfix) with ESMTPS id BF9093947412 for ; Thu, 29 Apr 2021 17:39:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BF9093947412 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 (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MfYc4-1l52oB3rK4-00g430 for ; Thu, 29 Apr 2021 19:39:28 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 68CB7A80F11; Thu, 29 Apr 2021 19:39:26 +0200 (CEST) Date: Thu, 29 Apr 2021 19:39:26 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: The unreliability of AF_UNIX datagram sockets Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <58da34ac-f2b6-d8b2-e872-834cfcb1ab51@cornell.edu> <6cac30e5-56fc-5bf1-b85b-fe6b91bc5e97@cornell.edu> <16e1d55e-15ea-6c0e-04e4-aa6cb2c0c1bd@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16e1d55e-15ea-6c0e-04e4-aa6cb2c0c1bd@cornell.edu> X-Provags-ID: V03:K1:vvQNQ4TFkng6HAfYFLZeGedEpDYe0ZFZtvjnR8UOTz+7H3vG2iR EPghWOXpLvsJjloSFYepL787YBo58LVbtev7w/Mxwacd4Z3ZtJBP9v+0bOT+IBSEU015Cg2 33RsArFCO8b0qgSTI+kmH1Q2npc2BCE91WTbVCr6t1NThZxGlCVxEy1oMFRtARq08xgVeNu fcZcEUqFHDMUzdrM/8dbg== X-UI-Out-Filterresults: notjunk:1;V03:K0:7GfjCZdg9L8=:7u539aSSqoWdhbTU0NrT3b x3iPkstqQ59f0dgZ3bbyGVjWcugIGZJYdkTzEMWm7EFM9tgD1b6kPEhVYUj/D6z6hALPuVhh+ NceQL+yNjhf62juOM9Iyu1z8gVd/IdV8BG8N0l+U+sKsFDQe9YRdI+jo8yU4iOpuhL3WniBB7 2bXAQlwAuu9da+eI937hRhGEM0REuTF5sHtzLRUKPXPjhg84wbro+5r3vwUf+qoS5uWTOcjVX v2Mb0rgagNbSKr6oxJB1/yb/91MBQfduzOQdNJ0xmA68twh8Z2GH6KfU/qjBbSJEMc2jUrDi/ GFeRKklHL4VPgKOxZ5VsPsjaWAtRQ9d67MjwJIZuNGicDFkmmPuBczLtwYIECxcG7Il7CoM3l 0Piuq23btC5TmqPMHJLDb4W6eyoznDZ/CzOeJ7sfRTqJbTH1jjnA84ErC0OObREhjV3qm21Lc /U9Fh1Lytwb3Sm6DkJvUn7tJn1kL4dBdJ2rtyJGwi31ISyvllcfuZUNRiGzQZa022hG4fTAIX MkycSwZSQvyoHPkYnsjtTc= X-Spam-Status: No, score=-100.1 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, 29 Apr 2021 17:39:32 -0000 On Apr 29 12:44, Ken Brown wrote: > On 4/29/2021 11:05 AM, Corinna Vinschen wrote: > > So maybe we should really think hard about the alternative > > implementation using POSIX message queues, I guess. And *if* we do > > that, this should be used likewise for STREAM as for DGRAM sockets, so > > the code is easier to maintain. Obvious advantage: No problem with > > older OS versions. And maybe it's even dirt easy to implement in > > comparison with using other methods, because the transport mechanism > > is already in place. > > Yes, I don't think it should be too hard. The one thing I can think of > that's missing is a facility for doing a partial read of a message on the > message queue. (This would be needed for a recv call on a STREAM socket, in > which the buffer is smaller than the payload of the next message on the > queue.) But this should be straightforward to implement. > > Alternatively, I guess we could read the whole message and store the excess > in a readahead buffer. Alternatively, we could introduce a new, internal-only method into the POSIX msq code, one that reads a partial message, reduces the message to the remainder and keeps it on the queue head... > On 4/29/2021 11:18 AM, Corinna Vinschen wrote: > > While searching the net I found this additional gem of information: > > > > Native AF_UNIX sockets don't support abstract sockets. You must bind to > > a valid path, so you always have a visible file in the filesystem. > > Discussed here: https://github.com/microsoft/WSL/issues/4240 > > > > We could workaround that with our POSIX unlink semantics, probably, > > but it's YA downside > > Agreed. The more features that are missing from native AF_UNIX sockets, the > less appealing they become. > > Concerning abstract sockets, would we still have an issue if we used message > queues? Wouldn't there be a visible file under /dev/mqueue? Or is there a > way around that? Good point! There's no way around that yet. In theory that shouldn't matter because /dev/mqueue is kind of a "virtual" path, even if Cygwin implements the queues as real files. But that's setting the perspective straight, we're in fact no better than the native AF_UNIX here ¯\_(ツ)_/¯ Probably we should actually add an internal-only way of creating non-file backed mqueues for the purpose of adding abstract sockets. Corinna