From owner-cvs-src-old@FreeBSD.ORG Sat Jun 4 16:01:43 2011 Return-Path: Delivered-To: cvs-src-old@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA10510656E9 for ; Sat, 4 Jun 2011 16:01:43 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 98F838FC13 for ; Sat, 4 Jun 2011 16:01:43 +0000 (UTC) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.4/8.14.4) with ESMTP id p54G1hYw054776 for ; Sat, 4 Jun 2011 16:01:43 GMT (envelope-from sobomax@repoman.freebsd.org) Received: (from svn2cvs@localhost) by repoman.freebsd.org (8.14.4/8.14.4/Submit) id p54G1ha2054775 for cvs-src-old@freebsd.org; Sat, 4 Jun 2011 16:01:43 GMT (envelope-from sobomax@repoman.freebsd.org) Message-Id: <201106041601.p54G1ha2054775@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: svn2cvs set sender to sobomax@repoman.freebsd.org using -f From: Maxim Sobolev Date: Sat, 4 Jun 2011 16:01:30 +0000 (UTC) To: cvs-src-old@freebsd.org X-FreeBSD-CVS-Branch: HEAD Subject: cvs commit: src/sbin/hastd proto_common.c X-BeenThere: cvs-src-old@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 16:01:43 -0000 sobomax 2011-06-04 16:01:30 UTC FreeBSD src repository Modified files: sbin/hastd proto_common.c Log: SVN rev 222688 on 2011-06-04 16:01:30Z by sobomax Read from the socket using the same max buffer size as we use while sending. What happens otherwise is that the sender splits all the traffic into 32k chunks, while the receiver is waiting for the whole packet. Then for a certain packet sizes, particularly 66607 bytes in my case, the communication stucks to secondary is expecting to read one chunk of 66607 bytes, while primary is sending two chunks of 32768 bytes and third chunk of 1071. Probably due to TCP windowing and buffering the final chunk gets stuck somewhere, so neither server not client can make any progress. This patch also protect from short reads, as according to the manual page there are some cases when MSG_WAITALL can give less data than expected. MFC after: 3 days Revision Changes Path 1.13 +14 -2 src/sbin/hastd/proto_common.c