Re: #555: frame synchronization

As I already said, I don't see any need. Desync ends pretty quickly with a
GoAway.
On Jul 20, 2014 3:55 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

> <https://github.com/http2/http2-spec/issues/555>
>
> Anyone with thoughts on this?
>
>
>
> On 12 Jul 2014, at 4:30 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> > Another issue I don't want to raise in the current melee, but I
> > think we should take it as an isssue, discuss it and close it,
> > so we can claim that we thought about it:
> >
> >
> > Has anybody considered frame-desynchronization ?
> >
> > The framing layer has neither pattern, checksum or sequence numbers
> > to help us tell if the sender and receiver have become mis-synchronized,
> >
> > If we wanted to be strictly compliant with "end-to-end argument" we
> > should have an integrity check, but given that we have a CRC and
> > sums in the layers below I don't think that's really an overhead
> > which would justify itself.
> >
> > However, it would make good sense to add a pattern or sequence
> > number to the frame header to give us a "must match field" to detect
> > frame misalignment.  (I looked at the current frames and there
> > are no fields which lend themselves naturally to this).
> >
> > If a frame header gets misaligned one byte either way, there are
> > pretty good chances that it will still look legit enough for
> > processing to commence.
> >
> > Given that many people talk about processing frames while they are
> > still being received, adding a more robust misalignment detection
> > sounds like a good idea to me.
> >
> > The easiest is probably a single byte sequence number which just
> > increments from frame to frame.  That number could be included
> > in RST frames to indicate which frame caused the error.
> >
> > --
> > 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.
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>