Content-Type: text/plain; charset=ISO-8859-1
--------
In message <CAOdDvNqKxMuzvEC+p+ooZOsjUZ5Wd5V0YXrdbPHPTdFaWK_mmg@mail.gmail.com>
, Patrick McManus writes:
>[...] but it still represents 500ms of serialization time on a 1mb/s
>network..
Just because you _can_ send longer frames, doesn't mean that it is
a good idea to do so.
However, enforcing QoS by restricting frame-lengths is bad architecture,
when HTTP is being used for a lot of bulk applications as well.
>I've worked with a number of spdy devs doing server side deployments that
>make the frame size equal to the content length (assuming it fits in the
>more generous spdy frame size) and have had the forseeable problems with
>responsiveness. We can build a protocol that isn't susceptible to that, and
>we should.
It is not the protocol being "susceptible", it is developers being
under-clued.
You cannot enforce policy with a protocol.
--
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.