Date: Mon, 06 Jun 2011 11:30:29 -0700 From: Maxim Sobolev <sobomax@FreeBSD.org> To: vadim_nuclight@mail.ru Cc: svn-src-all@FreeBSD.org Subject: Re: svn commit: r222688 - head/sbin/hastd Message-ID: <4DED1CC5.1070001@FreeBSD.org> In-Reply-To: <201106061057.p56Av3u7037614@kernblitz.nuclight.avtf.net> References: <201106041601.p54G1Ut7016697@svn.freebsd.org> <BA66495E-AED3-459F-A5CD-69B91DB359BC@lists.zabbadoz.net> <4DEA653F.7070503@FreeBSD.org> <201106061057.p56Av3u7037614@kernblitz.nuclight.avtf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/6/2011 3:57 AM, Vadim Goncharov wrote: > 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. > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DED1CC5.1070001>