[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