[Http-crcsync] General comments on crcsync document

[Gervase Markham]

On 15/07/09 17:11, Alex Wulms wrote:
> How about making crc32c the default, that must be supported by any crcsync
> server and client but foresee in the protocol that other algorithms might be
> added in future if pilot testing by early adapters might show that crc32
> gives too many clashes in practice or if crc32 works fine for most people but
> in a specific deployment with a specific usage scenario it turns out to be
> too weak.

It may or may not be wise to allow changes of algorithms. But surely we 
can calculate mathematically the chances of a collision using various 
forms of CRC? We don't have to guess. Let's not complicate things 
unnecessarily, let's do the maths and pick the best trade-off between 
size and clashes. That might even be 16-bit, I don't know. If 1 in 
10,000 had to be retransmitted rather than 1 in 10,000,000 but there was 
a speed gain for the other 9,999, it might still be worth it.

> Or am I now overcomplicating things?

I think so :-)

Gerv