[NUT-devel] Incomplete description of checksum algorithm

Michael Niedermayer michaelni at gmx.at
Sat Feb 18 11:59:16 CET 2006


Hi

On Fri, Feb 17, 2006 at 12:36:31PM -0500, Rich Felker wrote:
> On Fri, Feb 17, 2006 at 07:05:48PM +0200, Oded Shimon wrote:
> > > If the header is enclosed in
> > > the checksum, it's natural to consider it part of the syncpoint packet
> > > anyway. Also there's no reason a checksum needs to come from just one
> > > buffer. As long as you pass a state pointer to your checksum function
> > > you can checksum arbitrarily many different buffers as if they were
> > > all connected..
> > 
> > Yes, I know, this is why I said I'm not against forward_ptr being in 
> > checksum, but I am against forward_ptr being in syncpoints!
> > 
> > The point of forward_ptr being in syncpoints is to be able to add fields to 
> > syncpoints, not to frame headers, cause we already have that, right?
> > The structure is:
> > 
> > <startcode> <forward_ptr> <syncpoint> <reserved> <frame header> <checksum>
> > 
> > (reserved being reserved bytes for syncpoint)
> > Now, where the hell does the forward_ptr point to? If it points to after 
> > the checksum like all other headers, you won't know where the hell to start 
> > parsing the frame header. Pointing to right before the frame header is 
> > weird, because the checksum comes later. Putting the reserved bytes of the 
> > _syncpoint_ after the frame header is even weirder (data of syncpoint cut 
> > in two pieces??)
> 
> OK, I agree. Michael, do you have comments?

none which will help

the clean way to do this is
2 checksums 1 for the syncpoint, 1 for the frame header, and ptr points to the
first checksum/frame header

so i agree that no forward ptr in syncpoints is ok, unless we come up with a 
clean&low overhead solution

[...]
-- 
Michael




More information about the NUT-devel mailing list