On Mon, 2007-03-19 at 16:17 +0100, Per-Henrik Lundblom wrote: > Have I understood this right? If yes, is the solution to implement > fragmentation for the unacked/unsent queue in tcp_output()?
So, both sides have data to retransmit in the unacked/unsent queue, but they can't send it because the other side isn't advertising enough space because all its space is used up by the unacked/unsent queue? Changing the receive window length as you are doing is rather unusual, and although not technically illegal it may result in you advertising available space one minute, then reneging on that advert later by advertising a smaller window. It is normally assumed that once the right window edge has been advertised, it won't be made smaller (in sequence space) and that those buffers will continue to be available for receive. However, as I said, what you're doing is technically OK, just unusual, and so not the cause of your problem. The simple solution would be to set the size of the send queue to be slightly smaller so that there was always at least one MSS of space available for the receive window. This might limit your performance slightly (as you're putting a smaller limit on the send window) but shouldn't affect it too much as we're only removing one MSS from it. e.g Let's assume you have 16KB of memory for network buffers. If you set your max send queue len (in bytes) to be 12KB, there will always be 4KB of data for packets that aren't in the unacked/unsent queues, and they should be available for use for receiving packets. Being able to fragment a packet so that some of it could be sent probably wouldn't help you a great deal, because if you are able to get into this situation with less than 1 MSS of advertised space, you could get into the same situation but with zero advertised space. Then you couldn't send any data no matter how much you fragmented the packets, and so you'd be in the same hole. Hope that helps, Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
