> the business about the last 1100ish bytes of a 4096 byte send being
> delayed by nagle only implies that the stack's implementation of nagle
> was broken and interpreting it on a per-segment rather than a per-send
> basis.
+
> software, or the host TCP stack. otherwise, the persistent connections
> would have worked just fine.
Exactly.
But, actually, there exist the situation (in http-1.1, but not in the nature,
as it is now 8)), when explicit push is required even with ideal nagling.
Look: http-1.1, asynchronous one, the first request is sent, but not acked.
Time to send the second one, but it is blocked by Nagle. If there is no
third request, the pipe stalls. Seems, this situation will be usual,
when http-1.1 will start to be used by clients, because of dependencies
between replys (references) frequently move it to http-1.0 synchronous
mode, but with some data in flight. See?
Solution is evident. On such kind of connections explicit push
must be made as soon as we complete some request _and_ there are no
more pending requests in queue.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/