From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by sourceware.org (Postfix) with ESMTPS id B7D353980424 for ; Thu, 20 May 2021 19:26:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B7D353980424 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 1N4Qbu-1lHeTp48j0-011QJr for ; Thu, 20 May 2021 21:26:00 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 6AF33A82BFD; Thu, 20 May 2021 21:25:59 +0200 (CEST) Date: Thu, 20 May 2021 21:25:59 +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: <16e13907-8702-2ca2-a28e-f37f4f7f880c@cornell.edu> X-Provags-ID: V03:K1:j6iEbCLw0IYscj9/23rjXt5PtRasJpukyu6wTnN2cgcuTlzFM1Y aRfu1OmMvC+NyVWo+IDd/xPRD8r5yoc2pR0xUQFvf6DBKlAxSQtYb0xIpgOGyFGoJ7qGr3G gaLXTIyrYQ/fTmTqksoHIHnip4gW3pS5SeERlMayiSPCkqBiuDc1WfER8g+MScgh5r1Zisg 4DKodKtAjr5Ms4Tof9Ehg== X-UI-Out-Filterresults: notjunk:1;V03:K0:HYClclZn3II=:Mj7idgjJI90hzv/JG8Spfu L1N56PD0XzUVt4OUpJnsb5FmSogRZJ5u3z5L1Dxf0tVQgBkzb4ZhvBK6jZ7s20ioaphfUsZDj tSpaH5A3DKj1NS1wkGWwegv/cOaxv9WhLTaLoaEEtc8lLlTGHSh26bCY1bthhh4WZtGKB40gf HKCtkbLKK0rbqH3vPQ7RYN9ZYRtBocXRddBDnLbr6gs8+MuVWBJfPWYvtZEacGEnW+KVyy7bU XkhwXSyGJ1FymWA30XL7mdgUmb8TANsNGi86U2nrtqOfFQ3lwQny7q9L0U8VmpFx5DfGWm+1m ii0xXbUchU28rXsmUyv8cEstEpxYURHF4Dxm9nCrxb54x70JQt+dQLd3es54uq9F/Bf95+HsB X9yHC3Y3FMABom7EXfj064q/meooQrdDuJ8GjTYPrkZZ0CcKpb3sDg0C6BNu7tlt5DYGoBDLs IUEDmZGgjX7SrdDwDd00Ng68ZpH4lRyX5YfmMhp7c3tjtOPftPM09KCgjbeRhyGwlMhWVik5S EC1H1etZxoXRoT3IH7RQ2k= 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, 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, 20 May 2021 19:26:07 -0000 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. Thanks, Corinna