From owner-svn-src-head@FreeBSD.ORG Sat Jun 4 16:01:30 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1F4F1065670; Sat, 4 Jun 2011 16:01:30 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id C21D38FC08; Sat, 4 Jun 2011 16:01:30 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id p54G1UjV016699; Sat, 4 Jun 2011 16:01:30 GMT (envelope-from sobomax@svn.freebsd.org) Received: (from sobomax@localhost) by svn.freebsd.org (8.14.4/8.14.4/Submit) id p54G1Ut7016697; Sat, 4 Jun 2011 16:01:30 GMT (envelope-from sobomax@svn.freebsd.org) Message-Id: <201106041601.p54G1Ut7016697@svn.freebsd.org> From: Maxim Sobolev Date: Sat, 4 Jun 2011 16:01:30 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r222688 - head/sbin/hastd X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 16:01:30 -0000 Author: sobomax Date: Sat Jun 4 16:01:30 2011 New Revision: 222688 URL: http://svn.freebsd.org/changeset/base/222688 Log: 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 Modified: head/sbin/hastd/proto_common.c Modified: head/sbin/hastd/proto_common.c ============================================================================== --- head/sbin/hastd/proto_common.c Sat Jun 4 15:22:01 2011 (r222687) +++ head/sbin/hastd/proto_common.c Sat Jun 4 16:01:30 2011 (r222688) @@ -194,6 +194,8 @@ int proto_common_recv(int sock, unsigned char *data, size_t size, int *fdp) { ssize_t done; + size_t total_done, recvsize; + unsigned char *dp; PJDLOG_ASSERT(sock >= 0); @@ -210,9 +212,19 @@ proto_common_recv(int sock, unsigned cha PJDLOG_ASSERT(data != NULL); PJDLOG_ASSERT(size > 0); + total_done = 0; + dp = data; do { - done = recv(sock, data, size, MSG_WAITALL); - } while (done == -1 && errno == EINTR); + recvsize = size - total_done; + recvsize = recvsize < MAX_SEND_SIZE ? recvsize : MAX_SEND_SIZE; + done = recv(sock, dp, recvsize, MSG_WAITALL); + if (done == -1 && errno == EINTR) + continue; + if (done <= 0) + break; + total_done += done; + dp += done; + } while (total_done < size); if (done == 0) { return (ENOTCONN); } else if (done < 0) {