I finally got to the root of this
problem. It does not seem to be an issue with LWIP, but is an issue with browsers. Browsers are not truly duplex;
they allow only one TCP
Window's worth of data to be 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 hang
and 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
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
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
|