[Http-crcsync] General comments on crcsync document

[Toby Collett]

2009/7/16 Gervase Markham <gerv at mozilla.org>

> 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.
>

I agree we need to do the numbers (and also that supporting multiple crc
choices is probably a bad idea, maybe add a hook for graceful modification
in a v2 of the protocol if it is found to be needed.)

The issue with the numbers is that in the case of say a credit card
transaction, if we have a strong hash failure we cannot simply retransmit
the data, which means the user will see an error page. So this means it is
not a simple trade-off of data saved vs. retransmissions. I will sit down
later today and see if I can come up with some numbers and then run them
past the list...

Toby


>
> > Or am I now overcomplicating things?
>
> I think so :-)
>
> Gerv
> _______________________________________________
> Http-crcsync mailing list
> Http-crcsync at lists.laptop.org
> http://lists.laptop.org/listinfo/http-crcsync
>



-- 
This email is intended for the addressee only and may contain privileged
and/or confidential information
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/http-crcsync/attachments/20090717/ce2fb580/attachment.htm