NSOutputStream 或twistedreactor合并TCP数据包数据
我正在为与 Python Twisted 后端交互的 iPhone 应用程序编写一些网络代码。我最近遇到了一个问题,似乎我的 NSOutputStream 使发送时的有效负载加倍,或者扭曲使接收时的有效负载加倍。
我正在使用“Apple 推荐”风格的 TCP 套接字,EG 非轮询。
流程如下:
客户
- NSStreamEventHasSpaceAvailable: 发送 X 字节数据的数据包
- NSStreamEventHasSpaceAvailable: 发送另一个 Y 字节数据包
服务器
- Twisted 接收大小为 (X + Y) 字节的数据包
我确保如果 outputStream 的状态为“,则明确不发送数据” NSStreamStatusWriting”。还要确保如果未抛出 NSStreamEventHasSpaceAvailable 则不允许从客户端发送数据。
关于可能导致有效负载加倍/合并的任何想法? Twisted 代码相当简单,使用我的协议中的标准 dataReceived:
def dataRecieved(self, data): # do logic in order to decide how to handle data # ... # print of len(data) here reveals merged packet size
iOS 代码也相当标准:
if (eventCode == NSStreamEventHasSpaceAvailable) { [outputStream write:[packet getData] maxLength:[packet getPacketSize]]; } // [packet getData] simply returns a standard UInt8 array. // [packet getPacketSize] returns the size of that array.
当连续调用上述 iOS 代码两次时(例如,依次发送两个数据包),扭曲的代码报告合并数据的大小。
预先感谢您的任何意见或建议。
I'm working on some networking code for an iPhone application that interfaces with a Python Twisted backend. I've been running into a problem recently where it appears as though either my NSOutputStream is doubling up the payload on send OR twisted is doubling up the payload on receive.
I'm using the "Apple Recommended" style of TCP sockets, E.G. non-polling.
The process is as follows:
CLIENT
- NSStreamEventHasSpaceAvailable: send a packet of X bytes of data
- NSStreamEventHasSpaceAvailable: send another packet of Y bytes of data
SERVER
- Twisted receives packet of size (X + Y) bytes
I'm making sure I explicitly don't send data if the status of the outputStream is "NSStreamStatusWriting". Also ensuring that data is not allowed to be sent from the client if NSStreamEventHasSpaceAvailable has not been thrown.
Any ideas as to what may be causing this double-up/merger of the payload? The Twisted code is fairly straight-forward, using the standard dataReceived in my Protocol:
def dataRecieved(self, data): # do logic in order to decide how to handle data # ... # print of len(data) here reveals merged packet size
iOS code is fairly standard as well:
if (eventCode == NSStreamEventHasSpaceAvailable) { [outputStream write:[packet getData] maxLength:[packet getPacketSize]]; } // [packet getData] simply returns a standard UInt8 array. // [packet getPacketSize] returns the size of that array.
When the above iOS code is called twice in a row (e.g., sending two packets one after another), the twisted code reports the merged data size.
Thanks in advance for any advice or suggestions.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
基于 TCP 的通信中没有可预测的行为;您和远程主机之间可能存在任意数量的路由器、NAT 边界、愚蠢的代理或其他任何东西,它们决定了看似意外的行为。
哎呀,甚至可能有信鸽逐字节携带着你的数据包。
然而,在现实世界中,这种行为通常是相当可预测的。但并非总是如此,永远不是 100% 的时间,而且总是有可能某些客户的管道堵塞了。
使用 TCP,您至少可以保证通常 数据包将按发送顺序接收,除非出现错误。再次假设两者之间的所有点都已正确实现或非恶意(后一点意味着您必须假设有时数据会被损坏)。
即使这样的保证也没有多大意义。您可能会收到 10 个数据包中的前 8 个数据包...或者您可能会收到所有入站数据,但当您去响应时却发现出站连接已断开...
底线;双方的缓冲算法必须假设缓冲区可能被随机突发填充,这些突发与首先卡在另一侧的数据大小完全不匹配。虽然不是严格要求,但您的应用程序最好通过防御随机连接失败来获得服务;防止缓冲区截断、连接随机中断和数据损坏。
早期的字节长度字段和校验和是你的朋友。假设您是 !hjfdahjdas8y!$(&($@#&^@#)^&!@#&_[连接丢失]
There is no predictable behavior in TCP based communications; there may be any number of routers, NAT boundaries, goofy proxies or whatever in between you and the remote host that dictate behavior that appears unexpected.
Heck, there might even be carrier pigeons carrying your packets byte by byte.
Real world, though, the behavior is generally fairly predictable. But not always, never 100% of the time, and always with the potential of some customer somewhere with clogged tubes.
With TCP you are, at least, guaranteed that generally packets will be received in the order they are sent unless there is an error. Assuming, again, that all points between are either implemented correctly or non-malicious (that latter bit means that you have to assume that sometimes data will be corrupted).
Even that guarantee doesn't mean much; you may receive the first 8 of 10 packets... or you might receive all of the in-bound data only to find the out-bound connection is dead when you go to respond....
Bottom line; your buffering algorithm on both sides must assume that the buffer may be filled in random bursts that completely mismatch the size of data stuck in the other side in the first place. While not strictly required, your app will be best served by defending against random connection failures; against truncated buffers, randomly broken connections and data corruption.
Early byte-length fields & checksums are your friend. Assumptions are you !hjfdahjdas8y!$(&($@#&^@#)^&!@#&_[CONNECTION LOST]