0

我正在为与 Python Twisted 后端接口的 iPhone 应用程序编写一些网络代码。我最近遇到了一个问题，看起来好像我的 NSOutputStream 在发送时将有效负载加倍，或者在接收时将有效负载加倍。

我正在使用 TCP 套接字的“Apple 推荐”样式，例如非轮询。

过程如下：
CLIENT
    - NSStreamEventHasSpaceAvailable：发送一个 X 字节数据包
    - NSStreamEventHasSpaceAvailable：发送另一个 Y 字节数据
SERVER
    - Twisted 接收大小为 (X + Y) 字节的数据包

如果 outputStream 的状态是“NSStreamStatusWriting”，我确保我明确不发送数据。如果没有抛出 NSStreamEventHasSpaceAvailable ，还要确保不允许从客户端发送数据。

关于什么可能导致有效载荷的这种双重/合并的任何想法？Twisted 代码相当简单，使用我的协议中的标准 dataReceived：

    def dataRecieved（自我，数据）：
        # 做逻辑以决定如何处理数据
        # ...
        # print of len(data) here显示合并的数据包大小

iOS 代码也相当标准：

    如果（事件代码 == NSStreamEventHasSpaceAvailable）
    {
        [outputStream write:[packet getData] maxLength:[packet getPacketSize]];
    }
    // [packet getData] 只返回一个标准的 UInt8 数组。
    // [packet getPacketSize] 返回该数组的大小。

当上述 iOS 代码连续调用两次（例如，一个接一个地发送两个数据包）时，扭曲的代码会报告合并后的数据大小。

提前感谢您的任何意见或建议。

4

1 回答 1

1

我同意——我不应该期望缓冲区边界匹配，但我认为这是一个可预测的行为问题。

基于 TCP 的通信中没有可预测的行为；在你和远程主机之间可能有任意数量的路由器、NAT 边界、愚蠢的代理或任何东西，它们决定了出现意外的行为。

哎呀，甚至可能有信鸽逐字节地携带您的数据包。

然而，在现实世界中，这种行为通常是相当可预测的。但并非总是如此，绝不是 100% 的时间，而且总是有一些客户可能会在某处堵塞管道。

使用 TCP，至少可以保证，除非出现错误，否则通常会按照发送的顺序接收数据包。再次假设，之间的所有点要么是正确实现的，要么是非恶意的（后一点意味着您必须假设有时数据会被破坏）。

即使是这样的保证也没有多大意义。您可能会收到 10 个数据包中的前 8 个……或者您可能会收到所有入站数据，但在您响应时却发现出站连接已失效……

底线；双方的缓冲算法必须假设缓冲区可能被随机突发填充，这些突发完全不匹配首先卡在另一侧的数据大小。虽然没有严格要求，但您的应用程序最好通过防御随机连接失败来提供服务；针对截断的缓冲区、随机断开的连接和数据损坏。

早期的字节长度字段和校验和是您的朋友。假设是你！hjfdahjdas8y！$(& ($@#&^@#)^&! @#& _[连接丢失]

于 2011-05-10T04:45:56.290 回答