From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.atof.net (smtp1.atof.net [52.86.233.228]) by sourceware.org (Postfix) with ESMTPS id 372DF386100A for ; Tue, 23 Mar 2021 19:20:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 372DF386100A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gluelogic.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gs-cygwin.com@gluelogic.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-Spam-Language: en X-Spam-Relay-Country: X-Spam-DCC: B=; R=smtp1.atof.net 1102; Body=1 Fuz1=1 Fuz2=1 X-Spam-RBL: X-Spam-PYZOR: Reported 0 times. Date: Tue, 23 Mar 2021 15:20:28 -0400 From: Glenn Strauss To: sten.kristian.ivarsson@gmail.com Cc: cygwin@cygwin.com Subject: Re: AF_UNIX/SOCK_DGRAM is dropping messages Message-ID: References: <04cc01d71ffa$7d1e6cf0$775b46d0$@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <04cc01d71ffa$7d1e6cf0$775b46d0$@gmail.com> X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 19:20:39 -0000 On Tue, Mar 23, 2021 at 04:37:52PM +0100, Kristian Ivarsson via Cygwin wrote: > Hi all > > Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems to drop messages or at least they are not received in the same order they are sent > > Attached C:ish (with C++ threads though) sample program that essentially creates a "client" that writes as much as possible and a "server" that consumes as much as possible > > It seems like some buffer is filled and then messages are dropped (or at least it appears so) (if someone is about to test this, the "sleep" might need to be adjusted in order to make this happen) > > Hopefully it's just a flaw in our application (and sample), but as far as we can see, this should work > > > Does anyone, perhaps named Ken, have any insightful thoughts about this ? > const int size = BUFSIZ * 2; > char buffer[size] = {}; > > for( int idx = 0; idx < count; ++idx) > { > memcpy( buffer, &idx, sizeof idx); > > const ssize_t result = sendto( fd, buffer, size, 0, (struct sockaddr*)&address, sizeof address); > const ssize_t result = recv( fd, buffer, size, 0); ... > int index = 0; > memcpy( &index, buffer, sizeof idx); This appears to be a programming error, unrelated to Cygwin. I know that what you provided was an example test case, but you might want to check if your app is sending way too much when the actual payload size is much smaller. In the example you provided, you are sending 16KB instead of 4 bytes for the count. Is your code handling partial read/recv and partial write/sendto? (It is definitely a bug in the use of recv() in the sample code.) Partial reads and writes can occur more frequently with non-blocking sockets, but it is still good defensive programming to detect and handle partial read/writes. It goes without saying that if your protocol sends a fixed size chunk of data, that you should ensure that you read the entire fixed size, even if only using part of the data. Cheers, Glenn