> int sockbuflen = 0;
> setsockopt(sock, SOL_SOCKET, SO_RCVBUF,
> (char *)&sockbuflen, sizeof sockbuflen);
> This is kind of a user level bug, to set the socket buffer size to
> zero. However, the man page for setsockopt says,
> "SO_SNDBUF and SO_RCVBUF are options to adjust the
> normal buffer sizes allocated for output and input
> buffers, respectively. The buffer size may be increased
> for high-volume connections, or may be decreased to limit
> the possible backlog of incoming data. The system places
> an absolute limit on these values."
> By doing a getsockopt() I can see this lower limit is currently set to
> 256. However, for some reason this is too low! For some reason what
> ever I set with setsockopt() is multiplied by 2. (another bug?) I did
> trial and error and found for:
The reason for the *2 is that in Linux skbuff headers are accounted in the
socket buffer size too. To keep BSD compatibility which doesn't account them
the size is multiplied with two. It is crude, but it works.
> setsockopt getsockopt select() works?
> --------------------------------------------
> 1008 2016 No
> 1009 2018 Yes
> It other words if I try to set the recieve buffer to 1008 (or less)
> with setsockopt() the select() doesn't work, but it does with 1009 (or
> above).
> I'm running glibc-2.0.7 (rev.29, from redhat-5.2).
> Once I set sockbuflen above to a value greater than 1009 everything
> started working...
Why do you do that anyways? I agree that the kernel should set a bigger
minimum limit but to be honest - if you do something stupid like setting
the buffer size to zero what do you expect?
I wouldn't see it as a serious problem.
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/