我正在为我的 iPhone 应用程序编写一个服务器应用程序。我正在处理的服务器部分是中继服务器。这实质上是通过服务器使用 TCP 套接字在 iPhone 之间中继消息。服务器从流中读取 header 的长度，然后从流中读取该字节数。它反序列化 header ，并检查消息是否要中继到另一部 iPhone(而不是在服务器上处理)。
如果必须中继，它开始从发送方的套接字读取字节，一次 1024 字节。每收到 1024 个字节后，它会将这些字节(作为字节“数据包”)添加到按顺序处理的传出消息队列中。
然而，这一切都很好，但是如果发送方被打断会发生什么，所以它没有发送所有字节(比如，在它必须发送的 3,000 个字节中，发送方 iPhone 在 2,500 个字节后进入隧道字节)？
这意味着所有其他设备都在等待剩余的 500 字节，这些字节不会中继给它们。然后，如果发件人(或其他任何人)向这些套接字发送数据，他们认为新消息的开头是最后一个消息的结尾，从而破坏数据。
很明显，从上面的描述中，我使用的是消息框架，但我认为我遗漏了一些东西。据我所知，消息框架似乎只允许接收方在将它们组装到一个对象之前知道从套接字读取的确切字节数。一旦一两个字节在某个时候误入歧途，一切都会变得不同步，事情会不会开始变得毛茸茸？是否有重新同步的标准方法？
最佳答案
Wont things start to get hairy once a byte or two goes astray at some point, throwing everything out of sync? Is there a standard way of getting back in sync again?
TCP/IP 本身确保没有字节在单个套接字连接上“丢失”。
在您的情况下，事情要复杂一些，在这种情况下(如果我理解正确的话)您将服务器用作一种多路复用器。
在这种情况下，这里有一些选项:
- 让服务器缓冲来自 A 点的整个消息，然后再将其发送到 B 点。
- 如果从 A 侧检测到异常关闭，则关闭 B 侧 socket 。
- 更改协议(protocol)的接收端，以便 B 端客户端可以检测部分 A 流并从中恢复，而无需终止和重新建立套接字。例如，如果服务器为每个传入的 A 流提供了唯一的 ID，则 B 客户端将能够检测到是否有不同的流开始。或者有一个额外的长度前缀，这样 B 客户端就知道预期的整个长度和单个消息的长度。
您选择哪个选项取决于您传输的数据类型以及更改不同部分的难易程度。
无论解决方案如何，请务必包含 detection of half-open connections .
关于c# - 使用 TCP 套接字 (C#)，如何在接收方端检测消息在传输过程中是否被中断？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6562133/