From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by sourceware.org (Postfix) with ESMTPS id 70BEF3968C22 for ; Thu, 29 Apr 2021 15:05:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 70BEF3968C22 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 (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1M7JvQ-1lfRcs0Vhs-007irK for ; Thu, 29 Apr 2021 17:05:38 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 76C06A80F11; Thu, 29 Apr 2021 17:05:37 +0200 (CEST) Date: Thu, 29 Apr 2021 17:05:37 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6cac30e5-56fc-5bf1-b85b-fe6b91bc5e97@cornell.edu> X-Provags-ID: V03:K1:G+q/V9m/32ZFvQpeqzcZBBnfZbk4K1+uhGJfpBcq/zjuoojoJO6 ujaIshiQsY6VH5PCtYycSP0CxH1UxEiskHyvezQXnD5pA779lWQPeAE9FnE6pkQ/HEQP/VI Rkal0OnHwu7w52x6L6t9aD4ITxd9cJiYyU53Z0XBNCpMv1jhbZ4lrjSFqQ0WLXliFqcmOk6 ehH0RRJDriQ5MnhFy9+gw== X-UI-Out-Filterresults: notjunk:1;V03:K0:uuMTEFuZ/zc=:HcwngK9i+9AUXjBgF8pSkt rdAKalLWKTO79iR5vUE35crYOuhPRaDdb6c8H7xKagHua6E0L/SIqYJC2K0h5pIwDJmKFY5jN l/ZT02FhrzOheMRENoISFznv37zIQOOvC57eoLolmYwegEl0GBXDh4hYHav05f76otWfz8QLk 4QQrEl3nm7OClzZeRjyeTxP0WnUo78qLwjQNqtbXv8AGRdeA2+wauo+vfPU5vf3vBi+RWRIOq +wmcof3ylgyTHwmvsQkUL1RRF2Doq2QRb3kLGYAGRVuOklIUw3SiOM7hhnQh3nCN04PwCjSrC 4Oao1T9Wl1vepa20RsZf9gM3NZRvIALUEGKsuTAakRjSWeg7RnBDuxnbsoVqg1/re66WaU3od RXOlcmEWeoFX4DGgzZga1nG4DMlTrwc5WdpuC+i+1LOL4iHuLD/O3ziAm2UbOlctio+A5l7Wn cHj4ErO1kRMZU4Wie3dejZ0fvAgk/yWuR5jKypFVM+s8u6dy4z6GHAVchoCPt0oZJnfExlgns ZskO1h+zDZ2PunSTNwxRBE= X-Spam-Status: No, score=-100.3 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, 29 Apr 2021 15:05:41 -0000 On Apr 29 10:38, Ken Brown wrote: > On 4/29/2021 7:05 AM, Corinna Vinschen wrote: > > On Apr 27 11:47, Ken Brown wrote: > > > I'm willing to start working on the switch to native AF_UNIX sockets. (I'm > > > frankly getting bored with working on the pipe implementation, and this > > ^^^^^^^^^^^^^ > > I not really surprised, Windows pipe semantics are annoying. > > > > > doesn't really seem like it has much of a future.) But I'd like to be > > > confident that there's a good solution to the datagram problem before I > > > invest too much time in this. > > > > Summary of our short discussion on IRC: > > > > - Switching to SOCK_STREAM under the hood adds the necessary reliabilty > > but breaks DGRAM message boundaries. > > > > - There appears to be no way in Winsock to handle send buffer overflow > > gracefully so that user space knows that messages have been discarded. > > Strange enoug there's a SIO_ENABLE_CIRCULAR_QUEUEING ioctl, but that > > just makes things worse, by dropping older messages in favor of the > > newer ones :-P > > > > I think it should be possible to switch to STREAM sockets to emulate > > DGRAM semantics. Our advantage is that this is all local. For all > > practical purposes there's no chance data gets really lost. Windows has > > an almost indefinite send buffer. > > > > If you look at the STREAM as a kind of tunneling layer for getting DGRAM > > messages over the (local) line, the DGRAM content could simply be > > encapsulated in a tunnel packet or frame, basically the same way the > > new, boring AF_UNIX code does it. A DGRAM message encapsulated in a > > STREAM message always has a header which at least contains the length of > > the actual DGRAM message. So when the peer reads from the socket, it > > always only reads the header until it's complete. Then it knows how > > much payload is expected and then it reads until the payload has been > > received. > > This should work. We could even use MSG_PEEK to read the header and then > MSG_WAITALL to read the whole packet. > > I'd be happy to try to implement this. Do you want to create a branch > (maybe topic/dgram or something like that) for working on it? You can create topic branches as you see fit, don't worry about it. > > Ultimately this would even allow to emulate DGRAMs when using native > > Windows AF_UNIX sockets. Then we'd just have to keep the old code for > > backward compat. > > Yep. > > > There's just one problem with this entire switch to non-pipes: Sending > > descriptors between peers running under different accounts requires to > > be able to switch the user context. You need this if the sender is a > > non-admin account to call ImpersonateNamedPipeClient in the receiver. > > So we might need to keep the pipes even if just for the purpose of being > > able to call ImpersonateNamedPipeClient... > > > > > > Thoughts? > > Sounds great. Thanks. Don't start just yet. I'm still not quite sure if that's really the way to go. As I see it we still have something to discuss here. For one thing, using native AF_UNIX sockets will split our user base into two. Those who are not using a recent enough Windows will get the old code and no descriptor passing. However, if an application has been built with descriptor passing, it won't work for those running older Windows versions. I don't think we want that for the distro, or, do we? Next problem... implementing actual STREAM sockets. Even using native AF_UNIX sockets, these, too, would have to encapsulate the actual payload because of the ancilliary data we want to send with them. Whether or not we use native AF_UNIX sockets, they won't be compatible with native applications... 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. What's missing is the ImpersonateNamedPipeClient stuff (but that's not different from using native AF_UNIX) and reflections about the permission handling. Corinna