svn commit: r222688 - head/sbin/hastd

[Maxim Sobolev]

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 at 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