- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Labels:
-
SDK 2.4.1
-
SDK 3.x
-
Web Services
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Oleg,
Thanks for sharing the fix.
Seyhan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.