> Well, generically speaking Ethernet's FCS field is a 32-bit CRC of the > whole data frame. However if I understand the math correctly that means > that only 32-bit or shorter errors (remember Ethernet is serial) can be > detected reliabliy and "only" about 99.955% of error bursts longer than > 32 bits can be detected. Ethernet frames containing TCP or UDP IP > packets can be large -- up to ~1500 bytes.
I think you got that wrong about CRC. It's much better and especially suitable for serial streams. Every bit goes into the calculation and it's close to impossible (don't know %) that you can correct even one wrong bit to get the same result. Similar use is MD5.
One could presumably enhance this by encrypting the connection (eg. SSL) so that the encryption system supplies another layer of error detection. Anyone know how much, if any, that improves the result?
As far as I followed the discussions here I think that the problem is not the main transport over ethernet but the real (not fully lockable) cvs operation on the server if you access a NFS repository with :local: Only if the server cvs does the operation itself it can lock it and therefore the need for a cvs server protocol. bye Fabi _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
