用于处理可靠性的序列 ID
我正在尝试找出一种简单的方法来处理 UDP 消息的可靠性。 我想我只需向每个邮件发送一个序列 ID，然后通过将该 ID 与之前收到的 ID 进行比较，就可以检测到丢失情况。 我通常只使用整数，但是它会无限期地增加的想法并不适合我。
我可以使用 base64，但这只会使其更具可读性，但并不能真正解决任何问题。
我还考虑过在日期标记前加上前缀，但是在处理午夜左右收到的消息时，这会有点草率。
我觉得必须有一个更好的解决方案有人可以建议，即使只是坚持使用整数。
I'm trying to figure out a simple way to handle reliability for UDP messages. I figured I would just send each one with a sequencing ID and by comparing the ID to the one previously received, a loss can be detected. I would normally just use integers however the idea that it would just keep incrementing indefinitely did not sit right with me.
I could use base64, but that would only make it a bit more readable but doesn't really solve anything.
I also considered prefixing a date stamp however that would be kind of sloppy when dealing messages received around midnight.
I feel like there must a better solution that someone could suggest, even if that is to just stick with integers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我对这个特定工作的偏好是使用带有高分辨率时间戳的递增（至少 64 位）整数序列。 这样，即使发送端发生状态丢失，当序列从那时起重新播种时，它很可能会简单地向前跳跃。 任何可能引入的 Year 10K 错误都留给 Lazarus Long 作为练习。 :-)
请记住，序列间隙检测本质上是一种优化。 发送端需要重传，直到收到 ack，而 nack（对于间隙或损坏的数据报）只会引发更早的重传。 （ZMODEM 是该规则的一个罕见例外，其默认操作模式是在流末尾使用单个 ack 以及由 nack 控制的所有其他重传；然而，作为一种文件传输协议，它本质上是一个巨大的协议多部分数据报。）
My preference for this particular job is to use an incrementing (at least 64-bit) integer sequence seeded with a high-resolution timestamp. In this way, even if there is a loss of state at the sending end, when the sequence is re-seeded from the time, it will in all likelihood simply jump forward. Any Year 10K bugs that this might introduce are left as an exercise for Lazarus Long. :-)
Keep in mind that sequence-gap detection is essentially an optimization. The transmitting end needs to retransmit until an ack is received, with a nack (for a gap or corrupted datagram) simply eliciting earlier retransmission. (ZMODEM is a rare exception to this rule, with its default mode of operation being the use of a single ack at the end of the stream and all other retransmissions governed by nacks; as a file transfer protocol, however, it is essentially one giant multipart datagram.)
使用TCP？ 这就是 TCP 与 UDP 不同的原因
我无意讽刺，但是这就是 TCP 存在的原因。
Use TCP? This is why TCP is different to UDP
I don't mean to be sarcastic, but this is why TCP is there.