On 6/6/2011 3:57 AM, Vadim Goncharov wrote:
Hi Maxim Sobolev!
On Sat, 04 Jun 2011 10:02:55 -0700; Maxim Sobolev<[email protected]> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "[email protected]"
