> > I think we had this discussion before, but 32 bit CRC is overkill for
small
> > chunks of data. For example, MSX floppy uses 16 bit CRC for sectors (512
> > bytes long).
>
> A quick and interesting checksum algorithm is the one used for
> TCP/IP (one's complement of the sum of the one's complement of each word
> in the packet).
It really sucks and it is described terribly by TCP/IP (you also have to add
the borrow, who would think of that???). You don't want to know how long I
have puzzled over it. And I don't see the big advantage over a checksum. At
least not concerning the complementing. I can imagine the added borrow
increases the reliability.
> Another interesting one is that used in PPP frames. There
> is an implementation (FCS - Fast Checksum S-i-dont-remember-what-this-
> letter-means) that uses a 512 bytes lookup table; the cost of
> the checksum is two XOR operations per byte and the resulting checksum
> is a constant for any packet (I don't remember the value by heart).
> If someone is interested, I can give a source code example.
I can too... :)
FCS is quite nice actually... The end of the stream can be detected quite
easily, so if you use a packet protocol, you don't need to check for the
packet end every time, only when the GOOD_FCS has been reached. But at the
other hand, that complicates error detection. Anyways, it's very nifty. I
still don't fully understand how it's done exactly, only that it works.
However, I still think a checksum is good enough for JoyNet. It is quite
reliable (isn't it?), and the risk of undiscovered errors is quite small
unless the connection is very bad, and actually a lot of errors occur. And
in that case it is better to terminate the link than to proceed with so much
errors.
~Grauw
--
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
email me: [EMAIL PROTECTED] or ICQ: 10196372
visit my homepage at http://grauw.blehq.org/
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
