[NUT-devel] huge vs. damaged forward_ptrs in packets
Michael Niedermayer
michaelni at gmx.at
Thu Mar 9 18:44:48 CET 2006
Hi
On Thu, Mar 09, 2006 at 11:09:45AM -0500, Rich Felker wrote:
> On Thu, Mar 09, 2006 at 10:39:10AM -0500, Rich Felker wrote:
> > You mean just placing the checksum at arbitrary byte positions
> > independent of contents? I'm at least mildly against this since it
> > seems to complicate the implementation, requiring the data to be
> > copied around to make up for the checksums inserted at random
> > positions in it before it can be parsed.
yes, it was a bad idea, forget it
> >
> > IMO the only piece of data that needs to be protected more than the
> > whole-packet checksum is the forward_ptr (otherwise the demuxer may
> > read unboundedly into the future trying to verify the whole-packet and
> > its checksum). What if, instead of a checksum on the first N bytes of
> > a packet when the packet size is >N, we instead do just a checksum on
> > startcode+forward_ptr when the packet size is >N? This would eliminate
> > the need for buffering to write the data, and would get all the
> > benefits of the secondary-checksum (i.e. protecting forward_ptr).
>
> Forget it; Oded just told me that this is what you originally
> proposed. :) Sorry I misunderstood. I thought the secondary checksum
> was going to cover all bytes in the first N bytes of the packet, not
> just the startcode+forward_ptr.
yes, so we are back to the question of what value does N have
4k, 16k? variable and stored in main header and main header has always a 2nd
checksum
or every header always has a 2nd checksum and syncpoints have some >N rule?
somehow all these seem pretty much the same to me, only thing iam strongly
against is allowing very large N
personally i think a fixed N would be the best solution
[...]
--
Michael
More information about the NUT-devel
mailing list