> When doing some tests for the streaming process under linux I noticed that
> if the sender reaches a RecvQ full to upto 32k, my process hangs until there
> is more space in the RecvQ. the problem is that I cannot go around this
> desync since varying network conditions produces it.
> Is the only way to solve this problem the implementation of buffering on
> both ends of the connection in my software to keep the RecvQ and SendQ low ?
> or is there a parameter I could change within the kernel to allow for bigger
> RecvQ SendQs ?
Linux limits itself to unscaled 32K windows to interoperate with 16bit TCP
stacks that do broken signed arithmetic. If you know that you don't want
to communicate with such a stack you can increase the MAX_WINDOW parameter
in net/tcp.h to 64k. You will also need to increase the send and receive
buffers of the socket with the SO_RCVBUF/SO_SNDBUF socket options.
In 2.1/the upcoming 2.2 there is a complete solution for the problem:
it implements the TCP window scaling extensions of RFC1323 which allows
nearly arbitary big TCP windows. To use them you still have to increase
the send and receive buffers though (using the sysctls /proc/sys/net/core
/{rmem,wmem}_{max,default} and the SO_RCVBUF/SO_SNDBUF socket options)
-Andi
-
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/