[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] lwip and fragmented http messages

From: David Crocker
Subject: [lwip-users] lwip and fragmented http messages
Date: Sat, 31 May 2014 22:59:10 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Hi list,

I'm having a problem with lwip 1.4.0 that I don't understand. It's an
embedded application that I have inherited, without an RTOS, using the
TCP/IP raw API. I've modified the original web server to handle multiple
concurrent connections, and that's working fine. I've also written it to
handle incoming messages that are greater than the TCP MSS (which is set
to 1432) and so arrive in multiple packets. These large messages are
used when uploading files, and I can specify the maximum amount of data
(the block size) to be sent in each HTTP message.

What I'm finding is this:

- If I set the block size to 950 bytes or less, then the HTTP request
typically fits within the MSS so it goes as a single message. This works.

- If I increase the block size by a modest amount e.g. to 1200 bytes,
then the HTTP request is sent as one MSS-sized packet followed by a
smaller packet. This also works. Wireshark shows no errors or

- If I increase the block size some more e.g. to 1500 or 2000 bytes,
then the file upload becomes very slow. Wireshark shows that the client
sends the first of the two TCP packets, then the second. Then the
lwip-based server sends an ACK for the first. Then usually, nothing
happens for 300ms. Then the client resends the second packet. Often,
there is again no activity for 600ms, and the client resends the second
packet again. About 2ms after that, the client sends the HTTP response.
Then the cycle repeats.

So it looks as though lwip is discarding the second packet, sometimes
more than once. I have tried the following:

- Increasing lwipopts parameters MEM_SIZE, MEMP_NUM_PBUF,

- Changing my app to discard the data instead of processing it, in case
processing it was taking too long and not calling into lwip often enough
to preserve its responsiveness

Any suggestions, please?

David Crocker, Escher Technologies Ltd.
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

reply via email to

[Prev in Thread] Current Thread [Next in Thread]