谷歌协议缓冲区 - 位错误的概率以及减少错误的方法
我通过 TCP 通过互联网无线 VPN 传输相当大量的 google 协议缓冲区消息,我觉得我得到了相对较高的错误率(例如,布尔字段从 false 切换为 true 或类似的东西)。大约在一万分之一到五万分之一之间。
这可能吗?维基百科指出 TCP 的校验和较弱,但这通常在底层协议中得到解决:
按照现代标准,TCP 校验和是较弱的检查。具有高误码率的数据链路层可能需要额外的链路纠错/检测功能。弱校验和可以通过在 TCP 和 IP 之下的第 2 层普遍使用 CRC 或更好的完整性检查来部分补偿,例如在 PPP 或以太网帧中使用。
有谁有任何预期的经验吗?错误率应该是多少?如果以上速率是可能的,建议/最简单的修复方法是什么?复制字段?消息发送两次?或者是否可以采取其他措施来提高可靠性?
谢谢
I transmit a fairly large amount of google protocol buffer msgs over a VPN over wireless over internet via TCP, and I feel like I get a relatively high error rate (e.g. a boolean field switching from false to true or sth similar). Something between 1 in 10,000 and 1 in 50,000.
Is that possible? Wikipedia states that TCP has a weak checksum, but that this is typically fixed in underlying protocols:
The TCP checksum is a weak check by modern standards. Data Link Layers with high bit error rates may require additional link error correction/detection capabilities. The weak checksum is partially compensated for by the common use of a CRC or better integrity check at layer 2, below both TCP and IP, such as is used in PPP or the Ethernet frame.
Does anyone have any experience what expected error rates should be? If above rate is possible, what would be the recommended / easiest way of fixing it? Duplicating the fields? Sending the message twice? Or is there something else that can be done to increase reliability?
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
不,这是不可能的。假设您没有遇到硬件故障(内存、网卡等),这应该很容易检查 - 它是否发生在不止一台计算机上?
更有可能的是,您的应用程序代码中存在无效的内存访问等,或者您发送的数据根本不是您想要的。尝试在 valgrind 等下运行您的代码。
将复制字段作为正常操作一部分的想法似乎很荒谬:基本上没有人在野外这样做,而且您也不需要这样做。您的系统中有多层针对静默数据损坏的保护,因此这很可能是一个简单(或者可能不那么简单)的应用程序错误。
No it is not (reasonably) possible. Assuming that you are not suffering a hardware failure (of memory, your network card, etc.), which should be easy to check--does it happen on more than one computer?
Much more likely is that you have an invalid memory access or the like within your application code, or that the data you are sending is simply not what you intended. Try running your code under valgrind or the like.
The idea of duplicating fields as part of normal operation seems absurd: basically nobody does that in the wild, and you shouldn't need to either. There are multiple layers of protection against silent data corruption in your system, so it's most likely a simple (or maybe not-so-simple) application error.
John Zwink 的答案是正确的,因为你的结果不合理,并且在应用程序层修复是一个错误。
如果网卡引入这么多错误,VPN(假设软件层)将会崩溃并失去连接。
按照建议尝试 Valgrind,看看您的软件是否损坏了缓冲区。
另外,如果内存的“易于检查”似乎并非如此,那么 memtest86 是一个不错的选择,http://www .memtest86.com,您可以将其粘贴在 USB 驱动器或 CD 上,并让其运行过夜或周末。
John Zwink's answer is correct in that your results are not reasonable, and fixing at the application layer is a mistake.
The VPN (assuming SW layer) would go bonkers and lose connection if the network card were introducing that many errors.
Try Valgrind, as suggested, to find if your SW is corrupting the buffer.
Also, in case "easy to check" for the memory didn't seem so, a good bet is memtest86, http://www.memtest86.com, which you can stick on a USB drive or CD, and let run overnight or over the weekend.