Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Jun 2011 17:57:03 +0700
From:      Vadim Goncharov <vadim_nuclight@mail.ru>
To:        Maxim Sobolev <sobomax@FreeBSD.org>
Cc:        svn-src-all@FreeBSD.org
Subject:   Re: svn commit: r222688 - head/sbin/hastd
Message-ID:  <201106061057.p56Av3u7037614@kernblitz.nuclight.avtf.net>
In-Reply-To: <4DEA653F.7070503@FreeBSD.org>
References:  <201106041601.p54G1Ut7016697@svn.freebsd.org> <BA66495E-AED3-459F-A5CD-69B91DB359BC@lists.zabbadoz.net> <4DEA653F.7070503@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Maxim Sobolev! 

On Sat, 04 Jun 2011 10:02:55 -0700; Maxim Sobolev <sobomax@FreeBSD.org> 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.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106061057.p56Av3u7037614>