18 reputation
3
bio website
location
age
visits member for 1 year, 6 months
seen May 22 '13 at 11:02

May
22
comment Increased CRC collision probability when adding bits to input message
Ahh, I see! Thanks for your advice.
May
22
comment Increased CRC collision probability when adding bits to input message
@JohnDeters: The constraint is in the limited bandwidth. We could change the message specification to always include a version number (which probably should have been done in the first place, and would probably be non-trivial now), but then around 5 percent of all traffic would entirely be version information. The tradeoffs are well understood. It IS brittle. But it's also necessarily high performance.
May
21
accepted Increased CRC collision probability when adding bits to input message
May
21
comment Increased CRC collision probability when adding bits to input message
I will pour over your post again later, but for now, what does "format the V2 messages as having an additional CRC, inserted before the 1-byte CRC is computed" mean? Does this change the length of the transmitted message, or is this only used as additional input bits?
May
21
comment Increased CRC collision probability when adding bits to input message
On second thought: if I use two polynomials as you describe, that only gives me two different version numbers, correct? This wouldn't be flexible enough to provide three numbers. Of course, detecting three versions would reduce the original idea to 1/64 chance of false positive.
May
21
comment Increased CRC collision probability when adding bits to input message
Re-defining a field to implicitly define a version is an interesting idea, but I think the protocol is too tight for that. Most encoded numbers are unsigned, and there are no numbers which have been defined with room for adding a version.
May
21
comment Increased CRC collision probability when adding bits to input message
In layman's terms, I could sum up your post by saying "instead of using the same polynomial on a longer message, use a different polynomial on the same message to differ between V1 and V2 messages". And your conclusion is that such a design would allow more robust error detection (and fewer false positives when detecting version number)?
May
21
comment Increased CRC collision probability when adding bits to input message
Neat idea, but unfortunately the length of the message is very rigidly fixed.
May
9
awarded  Editor
May
9
awarded  Scholar
May
9
revised Increased CRC collision probability when adding bits to input message
deleted 111 characters in body
May
9
comment Increased CRC collision probability when adding bits to input message
Okay, you're absolutely right about the "once every hundred years". I didn't design the protocol, I just assumed. Poor assumption. But it can't be changed now, so I guess my requirement is mostly that it not get much worse. I'll tweak my question.
May
9
comment Increased CRC collision probability when adding bits to input message
Yeah, I struggled with where to put it. I figured this forum may have a better math knowledge than the CS area. Math forum might have worked, but I thought this forum might have a better sense of the "space" of a hash.
May
8
awarded  Student
May
8
asked Increased CRC collision probability when adding bits to input message