lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [bug #20506] HTTP server doesn't call tcp_output


From: Frédéric Bernon
Subject: [lwip-devel] [bug #20506] HTTP server doesn't call tcp_output
Date: Thu, 19 Jul 2007 14:01:40 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Follow-up Comment #20, bug #20506 (project lwip):

>Splitting into two is a dirty hack and shouldn't even be tried. It won't
work with many stacks (who count bytes rather than packets for the delayed
ack algorithm) so at best is just making your end less efficient. 

You're right !!! But... (yes there is a "but") I would like to understand
this little experience I did (if you can help me, once again, I'm not expert
of tcp part). I think the answer is in "It slowly increases the bandwidth
each round trip by increasing the number of packets it can have in flight,
but it starts off very conservatively incase the network is already
loaded.".

So, for application like web server, but is you have to reduce latency on a
LAN (by example, your device implement a xml web services interface to drive
a device or something like that), this dirty hack seems to be useful. To give
a measure on my target, I do this test:

My IE7 do a GET of a GIF file. In both tests, NAGLE is disabled (note I use
the socket interface). In both, I send first my Http headers, and next, the
file. But, in one test, to send datas, I do multiple calls of "send()" with
max. 1024 bytes (what I call, "with hack", not it's done at application
level, and not in the stack), and in the second test, I call the "send" with
the full size (here, the file has a 11488 bytes size). I attach the capture
trace I got. 192.168.1.85 is my IE7/WINDOWS/PC, 192.168.1.246 my lwIP web
server.

If I understand what I see, "with hack", the first data of the GIF file is
sent before receiving the first data ACK. "without_ack," we wait (~190ms) the
first data ACK (something like Vipin). After that, there is no "big" wait in
both cases. 

Statistics give:

- "with hack" 24 packets for the GET completion (I don't count the FIN
sequence, I look between SYN in packet #1 and the HTTP end in #24), in ~5ms.

- "without hack" 18 packets (for same result) in ~196ms.

Ok, once again, I'm agree, it's really dirty !!! And I'm sure it's not
working with all stacks. But... it's an interesting experience... I even
think I could improve that with send the http headers in two calls, and data
file in one call.

Perhaps it's a little bit "outside" the problem, but I find funny this
experience (since it's only done at application level)...


(file #13397, file #13398)
    _______________________________________________________

Additional Item Attachment:



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?20506>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/





reply via email to

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