From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2099.outbound.protection.outlook.com [40.107.244.99]) by sourceware.org (Postfix) with ESMTPS id 2E1E1383B414 for ; Thu, 15 Apr 2021 13:17:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2E1E1383B414 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cornell.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kbrown@cornell.edu ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DeQVZNj2OMTjW1THyBO8ySjTyNzR6sdElnZFonS8cBNCgi5+vupQhj93gQsfNOZpKm+wCjEmEAFNnSRhqrfOvmzUqDkSvqnEIChLQZKjcOFeiUjKD7Hy+YY6HrvrbMsc07QX9bsouR1k5YlV2La2DZF7XadCc6EZZRSRJCuoR5Uc2pid+EBWbejKzN6Pm3+/OuZNCWUlGfTtjyeTdU0NA7Xh0gvEjRZaUYhtk7touXEp2voJihIQ7TTs9nB4w/WuqVsoS9xFVdn7mldOFIXL8Jv8/1XomjuAnpF1dj/ls4pEDz4FKF8GxryUkdiUhJxnawNbfE5J7xdEQXtaq0RpIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y6iByP1dh4oVUOLNy2i98BQ4S22CNIlK0FIB6nZXYLk=; b=PUXQn8a8PmI6EEOopwezZPYz17b3NKsZHY+2DXQvXVyjxEcFyuHJyQPc4z3iOTB319/9vHn8TRoyK92lt5hQJWp0vLEITJRHotMkn3F0OK9UkF/WKXwPgHZGLwtjnF+fLE/BXDa7rg95tQZizsHuK74zJtyNI5aL9u/LUqLAcBR54o5QWMOqd6Vxgl6OVtaWj7++647tY284GK34VYDrM8SiUSj3Zu4mYsTcGFn1yYNSEwY0tkVx6ViWvCNaXf1eJtsfhWe2i416TFRjc/9rtbTTajtYUuGaDe6TcvzSOtBGIrhejEIVyUuNA7RLt/EosIgHjRHIkgVn5IjEpVRZsw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cornell.edu; dmarc=pass action=none header.from=cornell.edu; dkim=pass header.d=cornell.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y6iByP1dh4oVUOLNy2i98BQ4S22CNIlK0FIB6nZXYLk=; b=jvkqpKqT1y66AD12JqnWLeU+qFK4X44qlcKRb+8N98BJCwvk9xmtsAlTXD/J3EGD9KUxsDa+Pi7OHyDcBq0N8j/8OHtBzWmQmX61m8mL5EPF7Qnu8F0nAPTeZEmf73KRXve++A9E0ayBTgR+M5TsX5XzHn5pFPfbOP+1cVCt+Mc= Authentication-Results: cygwin.com; dkim=none (message not signed) header.d=none;cygwin.com; dmarc=none action=none header.from=cornell.edu; Received: from BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) by BN6PR04MB0661.namprd04.prod.outlook.com (2603:10b6:404:db::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.21; Thu, 15 Apr 2021 13:17:40 +0000 Received: from BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::59f8:fcc4:f07e:9a89]) by BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::59f8:fcc4:f07e:9a89%4]) with mapi id 15.20.4042.018; Thu, 15 Apr 2021 13:17:40 +0000 Subject: Re: Problems with the (new) implementation of AF_UNIX datagram sockets To: cygwin-developers@cygwin.com References: From: Ken Brown Message-ID: Date: Thu, 15 Apr 2021 09:16:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [24.194.34.31] X-ClientProxiedBy: CH2PR03CA0015.namprd03.prod.outlook.com (2603:10b6:610:59::25) To BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.17] (24.194.34.31) by CH2PR03CA0015.namprd03.prod.outlook.com (2603:10b6:610:59::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Thu, 15 Apr 2021 13:17:40 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b2020f85-9171-4db4-ebfe-08d90010d892 X-MS-TrafficTypeDiagnostic: BN6PR04MB0661: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wq4tf7Zz0nt6kDglIB6ISCbQG3nqo0fboUnNUknvriur4n6ojGWvWmaKLx9dwcsUEbWecC9NDkWNf2+DXahWlFe8otdcS5KmTW8ySD/PeorRDTr7PjCLhZ67ca4OrMKvF8MmWN0Z1NiL2xU+Uj6ab3ZIi8jllhc9d+E9sA8X5mxFBYbWh4u55ylIsvA3csE4jkqbRM073zw3dVE/IhcumgWsbgBRO4O6OQH9UwZt3WDkZ0WhE8MHkIy55KqlL3lN94onoI9pqm9BcoTiGqNoR988Sv+GM8G6Fiy3eZhlXvUenbQ9McwsWlSG1fYa3YEaVFWrgO2+bfWU4CryIrmI8LB4gdgDBsvv1GGz27/ZNfa4XUAD/pk22o3z3jt3tb0HQn5I5A7J9knURvrKNj9r4p+AwUV9RIjPE5eirWdxWLz4dhOP5IkfpxwoKliVFACaCew2L9jijWBXZm5VNcUfl2DMfVECHBa0qEbvyHz066IJdb4rxLNt7brLsB6BBDhY5+Mx7lBfHesfuHBvPv3AqZeuoBxrgJxSKFDORTxL104kaSDbdTrgLKdmoAVG4HXQAHYvBRPaCJzvUxWhY6CX+QeYLaqnlZskR8kJn53J8zOnAOqwCmDBFkdYXv47kfxyXIgyOX8UfKR34lSqY8kbBhF5gYOBYLU0L/0l73Xup5PCOGBZdlJS1DZZF+/xSYFxDSSvh5PWoKJ1EO7Qk0TmS7NrB6dC4loHa7YdGkXw4Bt/73ZxojgA3YtLoDeOzqJowxpLlCctKTOLFXZtxYS6iEIAKbAfgxUPgXkT2a/c//s= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR04MB4388.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(39860400002)(396003)(136003)(66946007)(66476007)(75432002)(36756003)(2906002)(66556008)(52116002)(53546011)(956004)(31686004)(31696002)(86362001)(2616005)(26005)(478600001)(966005)(16526019)(786003)(186003)(8676002)(38350700002)(83380400001)(316002)(6666004)(16576012)(38100700002)(5660300002)(8936002)(6916009)(6486002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?Windows-1252?Q?uel5ykdRxfi4PtZc1g0zO+PP/oKX/M+gKNQIl0cFywNpHSPT+/Qjgrkn?= =?Windows-1252?Q?67sxA7xdOqmbcC3/Fu0KgvkWLpYbfkA0Jm4XDKta5BFogbjDr2iCS5P1?= =?Windows-1252?Q?uC2yyI00Zye4JBSm69aWbrp1YKokPuJ3VsmKkytbSZ7J/79qAOLi6x0x?= =?Windows-1252?Q?6OheRYzhFVnGdOgNd00pZDh6piA1+3zyihj2Ay5+0ylPVTK/7xKuSUmP?= =?Windows-1252?Q?E53N5hVN8iXd6aphFAwDI8TACNDtHput8f0tfDsxbovrmwvChg6sN1LI?= =?Windows-1252?Q?ROstoXPzkueR19M5VxhCP54Ewn7X9HhQr4m+O4Q5/ODsHtHXGlSNBfbJ?= =?Windows-1252?Q?UGvGNo4fi2okTY0sS4Z+E8FAXtdGwZjU1Uvd2AGg8+RuKaMTHUN1wcju?= =?Windows-1252?Q?14jT+ZUYtrwTUOlWpWUYHB9+pE/pbfAaf3nsOkMaLxfM11K2SDv9pT5h?= =?Windows-1252?Q?mBxXLc5fAkn34fqE7lFY+pe4hl1bX3ztzBap1TADjJRVLAwNvqprBvS2?= =?Windows-1252?Q?4LBxjziVO71HnUwD6ymcjja9H3wElofITdbz51VjpHE3nuO4OZ97lQYM?= =?Windows-1252?Q?QMQIOq87UbS7GAjB2r8C76wAZ04LM4mOK9D5JIj9t7Qxve/Dn6s9Oihd?= =?Windows-1252?Q?SZ6svRnM/mx8FDGKgvo2c1AJeBt4xa2V86394asvoFxsme6n0BrgHRu2?= =?Windows-1252?Q?ZWJRKHy8cPaEj2TDWnGNeqUHOiiNi9kQuc5lXWzwFmJDVyAmzqpEncQt?= =?Windows-1252?Q?zkL1vNEk25KYlbX1fwBfrVVCDdSaJ1MSeuk7M8WMDwyoBtCFnu/e5OpM?= =?Windows-1252?Q?y7YtDTcBnLPtjxl2u5oaUKmcc7aBr3fkkm4t4x4/E/2y9c7cGQb0ePEL?= =?Windows-1252?Q?2C72npB/EClqBRQoPsPyeBv+CsU+pGA0JvbL98qn+swvugGfJ9WZOYbQ?= =?Windows-1252?Q?QkRHTngSopWzT/rxdUg85lrwl6xdY6pCIIDOR2IQyV9n/UyKgJ0d7YvA?= =?Windows-1252?Q?7t43EeHH28CwH+yas7+fpiKw506uW9YREyeRQjmPgSm6ZZpgmmfH5S7a?= =?Windows-1252?Q?DcTFNlaaP6mZk3bDGu6XB4aHB24XvxsX1CQF9/Z1G7U8JzgG3L5V+QdC?= =?Windows-1252?Q?nkfNMbvctjS0hZulBnipHj1gozMWoGV8ldq2nGpGdt/yjvUrj5p7igL+?= =?Windows-1252?Q?xnnLSncNVZRQoPBXaMJUU6NGxBoMZMsA/LXG7HB3OZbnQ0xGmLrNqn68?= =?Windows-1252?Q?pOA8xgJG87t16hixh0kUwa7QbXy2N1Q1UiobPpOAK6tD5TJsLG8kcC3+?= =?Windows-1252?Q?GvPxaYA2utbl76NLSMEiBuhHMk6BZ3mao5ThpwP9IznmQyDF3o4c9y1R?= =?Windows-1252?Q?S1LnHPi5vCPZDNWzzMzIxNPZYFe9AAkvkISJExNKmuaQeteltjikeTDV?= X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: b2020f85-9171-4db4-ebfe-08d90010d892 X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2021 13:17:40.4548 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d7e4366-1b9b-45cf-8e79-b14b27df46e1 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qJPGxCHpU9+N1oag0m5/Bmcy3JaqmmJc5Y5bMKrK7mmHUcSQATI/ErxSCRo98ayUJTuFwuC07EMTXfKGRoRbNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR04MB0661 X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, 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 13:17:44 -0000 On 4/15/2021 7:49 AM, Corinna Vinschen wrote: > 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! Unfortunately, the pipe isn't available until the server disconnects. I observed this in practice, and it's also documented at https://docs.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-disconnectnamedpipe "The server process must call DisconnectNamedPipe to disconnect a pipe handle from its previous client before the handle can be connected to another client by using the ConnectNamedPipe function." >> 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? No, I was missing the non-atomicity. So maybe that's OK. >> 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. Agreed. > 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. I thought about that, but you would still have the problem (as in 1 above) that the pipe instance isn't available until recv is called. > > 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...? Maybe so. Ken