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 928C63858024 for ; Sat, 22 May 2021 15:49:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 928C63858024 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 (mreue108 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MybCV-1lW8HO0zvR-00yylY for ; Sat, 22 May 2021 17:49:15 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id BEE95A82C00; Sat, 22 May 2021 17:49:14 +0200 (CEST) Date: Sat, 22 May 2021 17:49:14 +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> <16e13907-8702-2ca2-a28e-f37f4f7f880c@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:dnRfbCw5E2oEksW5PyrZUgGo1MM+Hdz9E6k7sGY7GlvMli1L60U CSNn++Xr87lwLAcmLKfl9OUbgyPHq/8qP/kTx9b4Gb3M2FQUAmPfoSOI1KHh63DFyHl8y0z QH0PnOoTTl0es82sNg70f1FXYSj5NJD0X63ytevyRQd/ID1L1JhN4Aq/aCfJt/vxLlQkzPN 7T2OCThzI1n+0q3gSTIoA== X-UI-Out-Filterresults: notjunk:1;V03:K0:2YeywH1vptg=:A0Fjc96RDPpIbJQx/l63MZ j0aFEVvGALF724Q5nroJmzekv2XY8A2b7gFJVmVyKJiSqHPH/eZ60jwao7D/rLjYY70nbOwKy rlQH9hBq82u0yTI+o2p/T+CXZaANQwA0sY+sj96w7+kubSkoCYn+cTh50KpqIua22Sckt3u1h CSPN8+z1B/JsY66Ed18MIG/JrGaiYPzcibl1vCISMouDCjmGV2J53skLtCWNYzVkRKHJTf/H5 2N+RU6ujvzn55rue2IcEU6mIdczUjD1dAzLW8Vi4FQswq4mM+xIHwWlcQGBzYpadUJy2zDdm1 UneygyUksSOdvDEtEiJeR9GCY7IjKdY3ghIVMEpSpgzmHeDG6j2lbh4ExED+nqnzmQ/jzGwID Cy5t1o3FW5uoBMGuhYX6owh+GlG14j3+6LmwHWrJkJGonPlacGdMYEV/1Py4v7TAVfbT3i/uQ W/a/9YE7qyMDFxKgkR9CQm5VOKKTDS0w7rMv/oNlt1cr4QOs3lB9GsGQQvosmqFLbgcNHonvS t9zXrToFIr7vnydavbqr1c= X-Spam-Status: No, score=-100.4 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: Sat, 22 May 2021 15:49:18 -0000 On May 21 17:54, Ken Brown wrote: > On 5/20/2021 3:25 PM, Corinna Vinschen wrote: > > On May 20 09:46, Ken Brown wrote: > > > On 4/29/2021 7:05 AM, Corinna Vinschen wrote: > > > > 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. > > > > > > I think I'd like to go ahead and try to do this DGRAM emulation in the > > > current (AF_LOCAL) code. It shouldn't be too hard, and it would solve the > > > unreliability problem while we look for a better way to handle AF_UNIX > > > sockets. > > > > Yeah, sounds like the way to go for now. > > Unfortunately, I ran into a problem. Trying to emulate DGRAM sockets in > STREAM sockets breaks the DGRAM send/recv semantics. For example, > WSARecvFrom won't return the source address. It doesn't anyway, does it? I mean, this is entirely local and the source address is, basically, the same socket. > I hope I'm just missing > something, but I don't see a way around this. I hope I don't miss something either... Corinna