From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2118.outbound.protection.outlook.com [40.107.244.118]) by sourceware.org (Postfix) with ESMTPS id BEC813858034 for ; Sat, 1 May 2021 21:42:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BEC813858034 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=KCHuCiU6xxhx8A+IGTuGSbWjFvn1R7A6ra2EUvC3pKdvDXF8JsUcNMQ15ZQuzeyeWUKou//Hk68zggk8Hg16wTXNr2HuloiXQo6ez5kchYUPS53eNw4UnBSQs9k4hJwnfTGAwPuluLwS+xWFu5h/WFSMldCyiUZCh27eR6fpJHXn6zMvT9m8yRYzQ/FisCYsNNovZIkh/u5PI9XBCxNkoF1DephEnT1zQa1l2Xv76G/v0SpflQeeodDpHhoRKi0m3PlKaHMjeARfVCUQ+zwtc+WOo99Ctf0ZymHiGEdZvPyX1yt1z1ubFyQbtatnfk0soc5c/fBWSs5eGm8HkyYm/Q== 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=1KhOipHsY1i+Dfx2E3oTACh+BoKG9J+vmKEJNt+bpRk=; b=Cjlv2ekm2F6thtStzH7DPtvoq0kkgzQBAxVhVwXwZyNiJnZI4O4lhQb5QzFxHnNAHJJGF3nFlLMIwrS5WTmaOLI50PS9Oje5QL3XqsewXasAiwXubxPfI4DtGpLeyejsiEK6qd9FKJAWroK20H6DCEQ3vkjBJsIZVEIMpe57QLAVt4fGKG3pcXfiZj6D4tvHEvLQZxbOb2XSNRnEyuMo6dkkimch9QpTKH50kY7liszJYGpcuMAPQKkfkozDFnVXa5gUnWiBdYXn2i4WM3G2B6wQwVqO+2aFKU+p3eYywcI4OMevKJF0S96FOf/50K3Uld53JeHVtvvHP71oBYvOQw== 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=1KhOipHsY1i+Dfx2E3oTACh+BoKG9J+vmKEJNt+bpRk=; b=egzbW03afaADUux6PZNSQAyuf0GV9U5ObPWbwtxsiOBDI4kktP0dMJTiXVKDK3ELJUVVYJKQTX0K0I5OG+l5Dk+RB1rHWYD1Zm8t0z8wrG24i5d6SgDlbUer6tRh2GFz6k6jwpVwDbfurZYp6pxqlgzoST0T+bIKxB4SpuSQHHk= 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 BN8PR04MB6371.namprd04.prod.outlook.com (2603:10b6:408:dc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Sat, 1 May 2021 21:42:36 +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.4065.035; Sat, 1 May 2021 21:42:35 +0000 Subject: Re: The unreliability of AF_UNIX datagram sockets 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> From: Ken Brown Message-ID: Date: Sat, 1 May 2021 17:41:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [24.194.34.31] X-ClientProxiedBy: CH2PR03CA0028.namprd03.prod.outlook.com (2603:10b6:610:59::38) 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.18] (24.194.34.31) by CH2PR03CA0028.namprd03.prod.outlook.com (2603:10b6:610:59::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.27 via Frontend Transport; Sat, 1 May 2021 21:42:35 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 74723a3e-7f78-4b1f-a9dc-08d90cea0891 X-MS-TrafficTypeDiagnostic: BN8PR04MB6371: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2887; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jIgkidDrt6Dg6gvLpQ/QL6GSS3mL1dZg1Qq0bL/6CqaxXwuSx3IHJg4pJ8VqF68WZH9Esz8Ltup2ttTJUgo/SkCbKHs5vlXZ38BrKVYHTBiuDvtZ9lVpXJJmciiF6R/IgUsCjj8q9pG1Qe3amytiOGOCJfU1XFkZhjdGhiCkeoS+pxBrLwbZmkQOduWkPh7q270njAvZRIfU/vCBxZxErXKhIEuO6TUeBP4hz2ZWzuVH5BKoAiNpzAsLHUWKMQIly/uUd4iQHzSKbfPQrrAGeJLTZTGkf0gdPC2JKhp4OUUDLV1w6FCZfIU60yv/iPWicuxAu5QbGd44DuVbsHf2c6zwwXQC2HNvnJtJdjLqyvBVySWNuXQ7sunF4aAS/SrxbTe19j+iTdaCDI9s/ofIvp3jf/UIbaGDs04LGsUJxm9plSZLzcXLg3uoMtEhi0v58zx7gtCZw1x76T3Pz/DlsdE062by8nJsIZnmLU6B07btJGzxWPgllmuLS8Daaut2h5c2JKLxF6m3JhovfXC79RidFYaTPZao7AS+BOSS/s2n468Ip2hFktwl28n27dWqFw3MJ5Pz325tSouitkdsnrricEoe7cSnAzwzAS/kvfRLCd81fI6DvEv9DGvtKtJzaSLEdA2KFKQ7S5bepxUE0hN7V3FdGEWJBVWJq2pvPG453i75Cv+kJTMhNqxpyRrhAwMx67r4B1mrt62Ik0iJZS2iNZU2YU/cA3Iw0GzcGF7c1vcR78uid5alwyXRYXd96b6RLzIkM5s2J9mSvgz+65xE6ndKQ7b2/bnvJJ0Eqvg= 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)(346002)(396003)(376002)(39860400002)(366004)(136003)(6916009)(786003)(52116002)(16576012)(186003)(478600001)(31686004)(38350700002)(83380400001)(36756003)(8936002)(26005)(6486002)(31696002)(6666004)(75432002)(86362001)(956004)(16526019)(8676002)(966005)(66556008)(2616005)(2906002)(53546011)(45080400002)(38100700002)(66476007)(66946007)(316002)(5660300002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?eUtzWitWdVNlbGRQVnpSOXk5L1JScUl5NEQzVVVFZUVadVhJL2E4eXAvK1px?= =?utf-8?B?RHc3OVR5UXVDZ1FYbmxjN01wOStFM0UxRWZxWlBCVndHcnN6VHZiWFBEbmtt?= =?utf-8?B?eXR1REdxbTFxWUZERHY2aitITGRSOGQ3MlZJZUFURkYyMk1BZTRHcUlqSzlz?= =?utf-8?B?M1pjR21EZW84RE9qTHVGTkNVK2FJSmVOQ3FCdjk3MTh2TFNmNWJqYi9QQkRW?= =?utf-8?B?MUp4QURiK3RYNDFRcCtIcmtLSitOUnhYcmNrRWcyVmpEcUxLR0Q1anFsY3FT?= =?utf-8?B?eTl4U3I0K04vMnd0cEpyNmdpNU9hZTh3ZVBrdGE0QXVYWGRMZkFjT01xaVlj?= =?utf-8?B?aFVQTFRXdDQzQkhQbW9WdmMwMGtQekNJanFoMGxOdU1ZYlI3MmVnZ3pUQWRI?= =?utf-8?B?K0dnQllNbkdOZmFXZUdHMzh6REJVNStuOEV3UU01Y1BidnZLcDJoZUFKMTdZ?= =?utf-8?B?Q3U5cGhIWmU3TW1laXpwb3dKcXFxQk1EK1VoUzBvVDhiN2FLZDRRTXoxcnlC?= =?utf-8?B?NVpEMUl6Z1o2dVdDOWZDNnJZaUtORzBOY21xaHNCUlVMcmh0ZlZOS3drUW5N?= =?utf-8?B?OUJMeU5BWkFuOHJVYWVGUGhUZ2pYV1JLZk5kNWxhQ1J3ZHc4Mk9FUEhkS3Fz?= =?utf-8?B?RmltSDNEZkVRV2xqRFBtQk1ZSHZKYjdhcFFEbTNsRW4veU5OUVlDS0JrS05I?= =?utf-8?B?WCtRQWlvekZ1WGY2Q1hTYkdkZUIvc2lqdEh0elQyODdaR1hZb1BVUFhxRlNB?= =?utf-8?B?R2VBMTZFMXRrYTRPRVdOVG5RNTQwNGxMRVNTTVJjVVpERVV1RlpVMU4xR2ZF?= =?utf-8?B?MzNkdDl4bmpvVytHb0JZdEpuMC9sbWQvaTNLMWVaQldDR0VmMnNuWVJDQXVy?= =?utf-8?B?ZmxoUnhVZkJtVFdlcDgzemJmekFYaWZRSk5VRUQ4K2hsWHZaMVQrMmtTQnJh?= =?utf-8?B?aXpjcjIzUFNqYzhkT0M2eG5wNVBJRGVBWTNkUnZUV1dmRStLQWU5VWFic21Z?= =?utf-8?B?eDV0SlQ1K0pSUHE5MkpqWUxQeDU4K2U4N2EwRHp3NmNzSmJFa0NEUVVGemZI?= =?utf-8?B?eDZ0eC9oY0VaQ0EzKytLVDNUSTVwdEFpVlNmdVB4eUVjRS8wWjlpN0JoTWlp?= =?utf-8?B?eVRqWU5DTVVaVklWMmRxQmRkSzZKbE5zcDhGcnF4dVNGb2p3cUpROW1hb0px?= =?utf-8?B?eUh1cDBoeXhjVWNWNVJEQURRUUtGb3p0QWlza29vcWRWYzBNQmtsRG5aTUlz?= =?utf-8?B?TWUxeXdyWDJsNUo3SzZRTkNEbElZd2NMbTdqdG1pUnZEYzg3TWpTcUNxSDRm?= =?utf-8?B?UktrSDVTMEhQSDIvZHlaV1Z3alJvcExGMlFGL1VZQkpaNGJZM0gydmhRM2NH?= =?utf-8?B?eGUxSFFBTFhjOW94SGV2RGt5VnBVQnhUY2w5ZWlxcmFNWGl3ZERaOStLQmZV?= =?utf-8?B?L05hZUNNUjh5eGJHejMvQkEwTXRiYVRFTll3eFJ2NUJ6TVJ1Q1hzZkZldjJB?= =?utf-8?B?S3NSeFlNREVpeG5XMFV6aTkySktTblpwRGo0V1lDZEkzVjFXZ2xUbjhlREpF?= =?utf-8?B?TVl6VWhDeDVCV1o4aUpxWHlKNkM3Q21FcWxXRWVjdjB2YjJsZFBmazJjRjFh?= =?utf-8?B?UXltVm5iTU1xd3I2bTN2ZHc3UFJ2QUo3eWo1dEhEd25XYnBTeUpvaGtPYVp0?= =?utf-8?B?WDFYOXFMd1p1NmQ3QlFKeFBwWjMxVXp5dzZmVnluWm9ibWZMYVFIV0t3TU1V?= =?utf-8?Q?/8Gk5e+D/E566T1v2unN3GtoUUNiKQUE4V27ylA?= X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 74723a3e-7f78-4b1f-a9dc-08d90cea0891 X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2021 21:42:35.7349 (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: 5I5RbgCWQqf6fpiV+oz0OkxVgdghN8MwA9tRbGXKU7v452lT3t1i9a9ElPtvhIKDbvYDlZc35rjqiCZPUcGyLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR04MB6371 X-Spam-Status: No, score=-3.5 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: Sat, 01 May 2021 21:42:42 -0000 On 4/29/2021 1:39 PM, Corinna Vinschen wrote: > 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. I've been thinking about the overall design of using mqueues instead of pipes, and I just want to make sure I'm on the right track. Here are my thoughts: 1. Each socket needs to create its own mqueue that it uses only for reading. For writing, it opens its peer's mqueue. So each socket holds two mqueue descriptors, one for reading and one for writing. 2. A STREAM socket S that wants to connect to a listening socket T sends a message to T containing S's mqueue name. (Probably it's sufficient for S to send its unique ID, from which the mqueue name will be constructed.) T then creates a socket T1, which sends its mqueue name (or ID) to S, and S and T1 are then connected. In the async case, maybe S uses mq_notify to set up the thread that waits for a connection. 3. In fhandler_socket_unix::dup, the child will need to open any mqueues that the parent holds open. Maybe an internal _mq_dup function would be useful here. 4. I'm not sure what needs to be done after fork/exec. After an exec, all mqueue descriptors are automatically closed according to Kerrisk, but I don't see where this is done in the Cygwin code. Or is it somehow automatic as a consequence of the mqueue implementation (which I haven't studied in detail)? On the other hand, why does Cygwin's mq_open accept O_CLOEXEC if this is the case? And after a fork, something might need to be done to make sure that the child can set the blocking mode of its inherited mqueue descriptors independently of the parent. If I understand the mqueue documentation correctly, this isn't normally the case. In the terminology of Kerrisk, the mqueue descriptor that the child inherits from the parent refers to the same mqueue description as the parent's descriptor, and the blocking mode is part of the description. But again, this might be Linux terminology that doesn't apply to Cygwin. That's all I have for the moment, but I'm sure there will be more questions when I actually start coding. Ken