[NUT-devel] Incomplete description of checksum algorithm

[Oded Shimon]

On Fri, Feb 17, 2006 at 09:47:16AM -0500, Rich Felker wrote:
> On Fri, Feb 17, 2006 at 01:56:03PM +0200, Oded Shimon wrote:
> > On Thu, Feb 16, 2006 at 04:31:59PM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Wed, Feb 15, 2006 at 10:43:25PM -0500, Rich Felker wrote:
> > > > On Thu, Feb 16, 2006 at 01:10:41AM +0100, Michael Niedermayer wrote:
> > > > > btw, why doesnt the syncpoint have a packet header / forward ptr !?
> > > > 
> > > > Because the damn thing is already way too big! :(
> > > 
> > > that makes it non-extendible which breaks one of nuts goals
> > 
> > IMO no.. frame headers can have arbitrary extendiblity, and syncpoints are 
> > unique - their checksum doesn't come at the end of the syncpoint, but at 
> > the following frame header...
> > 
> > As for forward ptr in checksum, it slightly annoys my coding because i do:
> > 
> > header -> temp buffer
> > forward_ptr - length of header+4 -> file
> > temp buffer -> file
> > checksum of temp buffer -> file
> > 
> > So I'd have to somehow push the forward ptr to the begginning of the temp 
> > buffer or some other solution. It doesn't matter badly though, I'm not 
> > really against it.
> > 
> > But syncpoints don't need forward ptr though because they are special, they 
> > carry themselves AND the following frame header... So you'd have to do some 
> > weird thing where the forward ptr only points to the end of the syncpoint, 
> > and then there's the frame header, and THEN there is the checksum. it's 
> > ugly IMO...
> 
> This is all your implementation issue.

BTW, implementation should have some importance, if there's no way to 
accomplish something without ugly hacks in code it's bad. :/ But this isn't 
such a scenario.

> 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??)

- ods15