RE: [lwip-users] HTTP transfer delayed by errors with Firefox - lwIP 1.3.0 on Xilinx Microblaze

[Bill Auerbach]

Lou,

I've always questioned the use of tcp_poll and stopped using it.  It seems
to me that when the stack wants more data, it will call tcp_sent to get it.
I'm not sure why tcp_poll needs to try to also send data.  Chances are it
doesn't go or tcp_sent would be called, and it eventually leads to that
retry timeout in tcp_poll.  Maybe a developer can tell us what is the
purpose of tcp_poll and why does it look like it can cause problems.

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of Lou Cypher
>Sent: Wednesday, June 03, 2009 9:44 AM
>To: address@hidden
>Subject: [lwip-users] HTTP transfer delayed by errors with Firefox -
>lwIP 1.3.0 on Xilinx Microblaze
>
>I'm using lwIP on Xilinx (S3A) Microblaze, and I used both their
>application note XAPP1026 (heavily modified, since it's quite buggy) and
>the stock raw httpd in contrib (with a few changes).
>
>My problem arises when I serve a page with "large" content, like with an
>image of some KiB.
>The web page is composed by some parts, in this example the main file
>  "m5.html" has references to
>   "css/main.css" and
>   "images/mainlogo.png"
>What happens is that after "m5.html" has been loaded, Firefox opens
>"images/mainlogo.png", then *during* this data transfer, it requests
>"css/main.css".
>This behavior seems to confuse lwIP, that "forgets" to complete data
>transfer for the CSS file, and that's not all.
>After a couple of seconds it calls the tcp_poll() handler, that has not
>yet data to send, because the HTTP/"GET css/main.css" request has *not*
>been delivered to the tcp_recv() handler.
>
>Trying with IE7, that doesn't seem to use interleaved reads, everything
>goes fine, no matter the type/size of files.
>Firefox appears to work well when I download single files, that go
>smooth even when tens or hundreds of KiB.
>
>Options in lwipopts.h are almost the default ones, beside memory
>allocation, that on this board is quite generous.
>
>This is a short log of messages inserted in httpd.c, in functions
>http_poll() - the "POLL" message, printed RS-232 when incrementing
>number of retries - and
>http_rcv() - when I recognize file to send and start it.
>Numbers in parentheses are file sizes, numbers in brackets is system
>time in milliseconds.
>------------------------------------------------------------------------
>-----
>httpd: GET /m5.html (383)  {31485}
>httpd: close conn
>httpd: GET /images/mainlogo.png (7728)  {31549}
>httpd: close conn
>httpd: POLL, left: 0, file: 0, data: 0, retr.: 1
>             loc.: 80, rem.: 3407, state: 4  {33481}
>httpd: GET /css/main.css (1300)  {34540}
>httpd: close conn
>------------------------------------------------------------------------
>-----
>
>The same numbers can be seen on the attached log from Wireshark.
>Port 3407 is opened for requesting main.css (in frame 23) but it gets no
>reply, then on frame 35 there's a retransmission by client and it
>finally gets answered, but it's three seconds later!
>
>- Is there some option I'm missing?
>- The function called on tcp_poll() handler works for output *and*
>input? How to handle broken/incomplete input with it?
>
>
>Lou
>