- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 07 Jul 2014 21:58:13 +0000
- To: Roberto Peon <grmocg@gmail.com>
- cc: Willy Tarreau <w@1wt.eu>, Johnny Graettinger <jgraettinger@chromium.org>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CAP+FsNdq4O0awp=B=5EPFh4y5XN=KKM2xr6DvcVkrMKpSzDn6Q@mail.gmail.com>, Roberto Peon wri tes: >In the response path, gateways can have significantly more leeway than the >proposed change (requiring buffering) would allow-- today I can know, by >virtue of the fact that I'm running both the gateway and the server, that >the server isn't going to do anything that can't be checked on a key-value >basis (as opposed to a full-headers basis), and requiring buffering for >each gateway on that path induces more latency than needs to be there, [...] Can you please tell me, blow by blow, packet by packet, where that latency comes from, because I can't find a place to fit it in ? Just because you get your HEADERS in a single frame doesn't mean you cannot process it byte by byte (or MTU by MTU) if you want to ? The only real difference is that you get to know up front how much will be coming your way. I have a hard time seeing how that can hurt your latency ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 7 July 2014 21:58:37 UTC