Unfortunately, by the time the reciever sees the frame the damage is likely already done. As a result of sending a large frame, the session may back up and prevent other data from being sent on other streams either successfully, or without undue delay. Essentially, the receiver not being DoS'd is the smaller of the problems here-- the sender causing random, unnecessary HoL blocking/contention and not effectively being able to switch to using the TCP channel for higher importance data is the bigger issue, coupled with the likelihood of exercising all of the code regularly (and if you don't think that is an issue, try using the not-regularly-sent parts of HTTP/1.0 and see if it is successful on many implementations...) -=R On Wed, Feb 6, 2013 at 11:23 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > Content-Type: text/plain; charset=ISO-8859-1 > -------- > In message <CABP7Rbdv-zuAg3=O6oHRqJY0= > xBYsBZ7kQpV0cqjePjk3+O2EA@mail.gmail.com> > , James M Snell writes: > > >flow (honestly, I think allowing 32-bit > >length control frames is just asking for trouble by encouraging bad > >behavior). > > The important thing is that you have to announce your bad behaviour > up front, that makes it very easy to deal with it on the receiving end. > > > -- > 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 Wednesday, 6 February 2013 20:14:56 UTC