From owner-svn-src-all@FreeBSD.ORG Mon Jun 6 18:30:38 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 DE9DB1065673 for ; Mon, 6 Jun 2011 18:30:38 +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 B86908FC1C for ; Mon, 6 Jun 2011 18:30:37 +0000 (UTC) Received: from [4.59.13.245] (helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QTeZQ-0003rp-Ts; Mon, 06 Jun 2011 11:30:37 -0700 Message-ID: <4DED1CC5.1070001@FreeBSD.org> Date: Mon, 06 Jun 2011 11:30:29 -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: vadim_nuclight@mail.ru References: <201106041601.p54G1Ut7016697@svn.freebsd.org> <4DEA653F.7070503@FreeBSD.org> <201106061057.p56Av3u7037614@kernblitz.nuclight.avtf.net> In-Reply-To: <201106061057.p56Av3u7037614@kernblitz.nuclight.avtf.net> 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-all@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: Mon, 06 Jun 2011 18:30:39 -0000 On 6/6/2011 3:57 AM, Vadim Goncharov wrote: > Hi Maxim Sobolev! > > On Sat, 04 Jun 2011 10:02:55 -0700; Maxim Sobolev 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. > > I'm also don't know the hast internal protocol, but the very need to adjust > some *user* buffers while using _TCP_ is pretty strange: TCP doesn't depend on > sender's behavior only. May be setsockopt(SO_RCVBUF) needs to be used. Also, > why recv() is ever there on TCP, instead of read() ? Is that blocking or > non-blocking read? In the latter case kqueue(2) is very usfeul. > MSG_WAITALL might be an issue here. I suspect receiver's kernel can't dequeue two 32k packets until the last chunk arrives. I don't have a time to look into it in detail unfortunately. -Maxim