Hello -
I'm trying to understand Linux's (2.4.1) behavior with regard to
socket send buffers. In particular, the kernel appears to accept far
more data than the socket send buffer size would prescribe. The data is
correctly written, the only issue that on a blocked socket, Linux allows
more data to be written than the buffer size reported by getsockopt(fd,
SOL_SOCKET, SNDBUF...).
For example, opening a TCP connection to itself, my Linux box reports
a rcvbuf of 87380, and a sendbuf size of 16384 before the connect,and
49440 (3 * (16384 + 16 + 80)) afterwards. That appears consistent with
tcp_fixup_sndbuf(). If I then do not issue a read, but continue to
write a byte at a time, I manage to write 118785 bytes, 66525 of which
are in the recv buff (why not 87380?), 52260 in the send buffer. Notice
that 52260 > 49440.
Running the same test on FreeBSD exhibits the behavior you'd expect,
namely the snd and recv buffers both fill up to the size advertised by
getsockopt(). For my purposes, I need a bound on the maximum amount of
data that can be in flight, where in flight refers to accepted by the
kernel at one end, but not yet read by the other end. I would expect
that to be (sndbuf + rcvbuf) as reported by getsockopt().
Sorry if this is a stupid question, but can somebody clue me in on
what I'm missing?
Thanks!
- Alex
--
NMS / PDOS Groups
MIT Laboratory for Computer Science
545 Technology Square, NE43-512, Cambridge, Massachusetts 02139
http://nms.lcs.mit.edu/~snoeren
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
