Jump to content

TM4C129 Ethernet client: http request loss when receiving continuous inquiries

Recommended Posts

Dear oh43 users,

I am facing trouble on an application providing on a webserver serving html documents and images from a SD card and running on a EK-TM4C1294XL platform.


Currently, I am bypassing the SD card storage and all the binary and html code are embedded in the source code.


The configuration is now quite simple, where the webserver is supplying an index.htm page and several jpeg images referred in this page.


For this this test purpose, and in order to increase the network traffic several jpeg image filenames are specified in the source code like tiger1.jpg, tiger.jpg, etc (total 10 images) therefore the webserver provide every time the same binary image stored into tiger_jpg array (defined in tiger.h).


Every time, the index.htm page and some of the images are loaded successfully (see screen capture in attachment). However, some images aren


log 2014-09-03 16h00 console msg about lost of receiving http request.txt

CAP 2014-09-03 16h00 network capture lost of http request.zip


Link to post
Share on other sites

Old browsers never used to open more than 2 concurrent connections to a server. Modern browsers will open up a boat load of concurrent socket connections. To see what is going on, use chrome and turn on the developer tools. Then reload and inspect your pages network resource usage and the timeline. In the timeline it displays all the concurrent connections attempting to download all your images at the same time. This works great for a webserver that expects more than 10k concurrent connections and is connected via giga-ethernet. Not so good for you.


The best web server content is the kind you don't serve more than once. You should look at adding HTTP cache headers to your response.


You can try slow loading your images driving the process with javascript, instead of using image tags.


You could try changing the max-persistent connections per server in your browser.


You could respond with HTTP/1.0 protocol header and the Connection: close as @ David Bender suggested.


Me personally, I think these connected devices work best as outbound only devices shipping their content to some other server capable of acting as a true webhost.



Link to post
Share on other sites

Well without looking too deeply, it's probable that the Ethernet library and your sketch just can't keep up... or maybe some RX buffer tunables could be adjusted here either in Ethernet or lwIP.  I haven't looked yet to see what they are.


But I think it underscores @@Rickta59 's point, these things aren't really meant to be high-performance webservers.  They do a pretty good job for what they are IMO.  Perhaps a TCP/IP-oriented RTOS could manage things better for this application.

Link to post
Share on other sites



Thanks for your feedback, currently I follow the Rickta59's recommandation and I am using an external server supplying the image files. The TM4C129 platform provides only the html pages from an SD card and the performance are much higher and stable.

Np, that should work ... Heck we often do a similar thing in larger webserving installations, with a "web tier" serving static content directly and certain paths for dynamic data internally redirected to an "application tier".


Side note- TI's new CC3100/CC3200 series WiFi chipsets/MCUs have a webserver feature built into the WiFi network processor, possibly to address this concern (although I'm not sure if its performance is up to par for the kind of rapid-fire image loading you're doing here).  But same idea--static content from the CC31xx wifi processor, dynamic content comes from the main MCU.

Link to post
Share on other sites

You probably can get decent web performance with the TM4C129. You can't use a naive web server though. I've written an embedded web server for my client (on an ARM chip as well) and can recommend the following:


1) Don't buffer the client request; try to parse the request as the data comes in. 98% of your requests are GETs and do not require buffering. Consequently you can boost the number of sockets you can process at a time.

2) I recommended trying Connection: close because I thought the browser may have been trying to reuse the socket and your code didn't seem to support that. Connection: close is BAD precisely because the client will use more socket resources. So try to reuse the socket.

3) Send etags back on all GETs and parse etags from the client. 304 responses take way less bandwidth.

4) I'm not sure what client.write() does, but it does not seem to distinguish between RAM and flash. LWIP can operate way more efficiently if it does not have to make a second copy of the data.

5) Though you can \n as a line terminator, just send \r\n. Do it.

6) Be nice to the user and send back a 429 when you've received too many web requests. So much nicer than a hang up.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...