[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