From owner-svn-src-all@FreeBSD.ORG Sat Jun 4 17:24:14 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8E42106564A; Sat, 4 Jun 2011 17:24:14 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id A01E58FC13; Sat, 4 Jun 2011 17:24:14 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QSuFa-000BrK-SM; Sat, 04 Jun 2011 10:03:03 -0700 Message-ID: <4DEA653F.7070503@FreeBSD.org> Date: Sat, 04 Jun 2011 10:02:55 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <201106041601.p54G1Ut7016697@svn.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r222688 - head/sbin/hastd X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 17:24:14 -0000 On 6/4/2011 9:33 AM, Bjoern A. Zeeb wrote: > I don't know about the hast internal protocol but the above reads kind of > wrong to me. Hmm, not sure what exactly is wrong? Sender does 3 writes to the TCP socket - 32k, 32k and 1071 bytes, while receiver does one recv(MSG_WAITALL) with the size of 66607. So I suspect sender's kernel does deliver two 32k packets and fills up receiver's buffer or something. And the remaining 1071 bytes stay somewhere in sender's kernel indefinitely, while recv() cannot complete in receiver's. Using the same size when doing recv() solves the issue for me. -Maxim