LWIP fail to transfer large files (HTTP requests)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello Guys,

I have HTTP server. Some of my webcontent files are quite large 50-150KB. When I build for NetX_Duo, HTTP file requests are completed successfully. However, when I build for LWIP files get truncated when they get to the client, thus webcontent does not get properly displayed in the browser. Also none of the following HTTP requests are responded by the server.  I am working with WICED 3.1.2. LWIP works ok with small files.

There have been a discussion : http://community.broadcom.com/message/9742#9742

But it does not seem to have been resolved.

Basically, I have noticed that LWIP fails to transfer large files in response to HTTP requests. I cannot figure out the size threshold yet.

Any ideas, how to resolve this limitation?

Many thanks.

Oleg

0 Likes
5 Replies
Anonymous
Not applicable

It has been solved.

Apparently, LWIP 1.4.0 does not yet support non-blocking netconn_write

Modify network_tcp_send_packet function in tcpip.c:

    //status = netconn_write( socket->accept_handler, data, length, NETCONN_COPY | NETCONN_DONTBLOCK );

      status = netconn_write( socket->accept_handler, data, length, NETCONN_COPY );

After that LWIP can transfer large files to the HTTP client

Hope this helps.

0 Likes

Hi Oleg,

Thanks for sharing the fix.

Seyhan

0 Likes
Anonymous
Not applicable

Hi,

I think your statement is not entirely true.

The LwIP in WICED SDK does support non-blocking netconn_write.

It probably has somme bugs in LwIP for non-blocking case.

Well, the version of LwIP in the SDK is pretty old, I have suggested on the

forum that it's better to upgrade the version LwIP but seems got no feedback.

There are also some bugs in SDK it self, e.g. looking at the

wiced_tcp_send_buffer() function, it does not properly handle the case

if wiced_tcp_send_packet() fails.

It needs to return the length has been successfully sent, otherwise the caller

does not know how to resend the rest of data.

Change to blocking write may solve the issue you hit, but I'm wondering if

it has other side-effects (especially in high-loading/OOM case).

0 Likes
Anonymous
Not applicable

Hi Sam,

There is a TODO note in netconn_write function definition:

/* @todo: for non-blocking write, check if 'size' would ever fit into snd_queue or snd_buf */

The thing is there is no such check. And for a non-blocking transfer if there is no available space in a snd_buf it seems that the transfer is abrupt and is neither retried nor checked again.

There are actually a lot of @todo in LWIP 1.4.0. 🙂

I have worked with LWIP 1.3.2 and it seemed to be more stable.

I have put aside LWIP within WICED SDK for the time being and use NetX_Duo that seems more stable in many ways. But I would actually prefer using LWIP because of the source code.

Please share if you get more findings.

Oleg

0 Likes
Anonymous
Not applicable

ouzenkov wrote:

Hi Sam,

There is a TODO note in netconn_write function definition:

/* @todo: for non-blocking write, check if 'size' would ever fit into snd_queue or snd_buf */

The thing is there is no such check. And for a non-blocking transfer if there is no available space in a snd_buf it seems that the transfer is abrupt and is neither retried nor checked again.

Ah, right, I remembered I have read that before.

We still have missing packets issue no matter using blocking or non-blocking

netconn_write. Sometimes transferring a 2M file to remote side has some

packet lost, so the received file does not match the original file.

I have checked all return code from wiced_* level and don't see any error code.

I'm still unclear about where the root cause is.

0 Likes