I finally got to the root of this problem. It does not seem to be
anissue with LWIP, but is an issue with browsers. Browsers are not
trulyduplex; they allow only one TCP Window's worth of data tobe
downloaded (in my case, this was 64K) while a upload (ie httpt POST with
large file data) is in progress. If you try to send more data to the
browser before the upload is finished, LWIP will just hangand not send
any more data to the browser. And because LWIP is hung, it no longer
continues the upload either. So it deadlocks.
The workaround is to wait until the upload is complete, before sending
the response.
-Mark
On 12/21/2012 2:11 AM, [email protected] wrote:
Mark Lakata wrote:
I'm not sure how to get the size of the "connections's TX/RX window
sizes".
The easiest way is wiresharp. Posting a pcap here might help us to
look at what's going on.
Here is a snippet from the lwipopts.h.
[..]
#define TCP_SND_BUF (2*TCP_MSS)
#define TCP_WND (2*TCP_MSS)
Using half the MSS should work (if it doesn't, it should be a bug in
lwIP), but it's not recommended to do so. TCP needs at leasst 4*MSS to
work efficiently. I bet with TCP_SND_BUF and TCP_WND set to 2*TCP_MSS,
your problems are gone.
The problem here is that TCP tries to prevent sending too many
ACKs/window-updates. Most TCP implementations only send an ACK if the
resulting change for the remote client is one MSS, this is why you
easily run into problems with WND==2*MSS and lwIP splitting up
send-data into MSS-sized chunks.
Simon
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
