iOS上的GCDAsyncUdpSocket缺少多播数据报 [英] GCDAsyncUdpSocket on iOS missing multicasted datagrams
问题描述
我在网络上有一个设备通过UDP组播一个非常小的文件。我正在开发的iOS应用程序负责读取这些数据包，我选择使用 GCDAsyncUdpSocket 来执行此操作。该文件每半秒发送一次，但我几乎没有收到它（大约每3-10秒接收一次）。
I have a device on the network that is multicasting a very small file via UDP. The iOS app I am developing is responsible for reading these packets and I have chosen to use GCDAsyncUdpSocket to do so. The file is sent every half second, however I am not receiving it nearly that often (only receiving about every 3-10 seconds).
认为这可能是设备的问题，我开始使用Wireshark监控流量。这似乎反映了我在我的应用程序中看到的内容，直到我在Wireshark中启用监控模式，此时每个UDP数据包都被捕获。此外，iOS模拟器开始接收所有丢失的数据包，因为它与我正在开发的Mac共享NIC。
Thinking that it may be an issue with the device, I began monitoring the traffic with Wireshark. This appeared to reflect what I was seeing in my app until I enabled "Monitor Mode" in Wireshark, at which point every UDP packet was being captured. In addition, the iOS simulator began receiving all of the missing packets since it shares the NIC with the Mac I am developing on.
有没有办法启用监控模式 在iOS设备上或我遗漏的东西会让丢失的数据包进来？我还看到GCDAsyncUdpSocket中有一个readStream方法。也许我需要使用它而不是beginReceiving？虽然我不知道如何在Objective-C中设置流。如果是这样的话。
Is there a way to enable "Monitor Mode" on an iOS device or something I am missing that would allow the missing packets to come in? I also see that there is a readStream method in GCDAsyncUdpSocket. Perhaps I need to use this instead of beginReceiving? Though I do not know how to set up streams in Objective-C if that is the case.
这是我现在的测试代码：
Here is my test code as it is now:
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
NSLog(@"View Loaded");
[self setupSocket];
}
- (void)setupSocket
{
udpSocket = [[GCDAsyncUdpSocket alloc] initWithDelegate:self delegateQueue:dispatch_get_main_queue()];
NSError *error = nil;
if (![udpSocket bindToPort:5555 error:&error])
{
NSLog(@"Error binding to port: %@", error);
return;
}
if(![udpSocket joinMulticastGroup:@"226.1.1.1" error:&error]){
NSLog(@"Error connecting to multicast group: %@", error);
return;
}
if (![udpSocket beginReceiving:&error])
{
NSLog(@"Error receiving: %@", error);
return;
}
NSLog(@"Socket Ready");
}
- (void)udpSocket:(GCDAsyncUdpSocket *)sock didReceiveData:(NSData *)data
fromAddress:(NSData *)address
withFilterContext:(id)filterContext
{
NSString *msg = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
if (msg)
{
NSLog(@"RCV: %@", msg);
}
else
{
NSString *host = nil;
uint16_t port = 0;
[GCDAsyncUdpSocket getHost:&host port:&port fromAddress:address];
NSLog(@"Unknown message from : %@:%hu", host, port);
}
}
未来任何人的解决方案：
根据ilmiacs的回答，我能够显着减少丢失数据包的数量ping目标iOS设备。使用Mac，我在终端中运行了这个 -
Based on ilmiacs's answer, I was able to significantly reduce the number of missing packets by pinging the target iOS device. Using a Mac, I ran this in the terminal -
sudo ping -i 0.2 -s 4 <Target IP>
现在，我已经让它运行Mac ping iOS设备，我将调查Apple的iOS ping示例，看看我是否可以让设备ping自己以刺激自己的无线适配器（127.0.0.1）。
Now that I have it running with a Mac pinging the iOS device, I am going to look into Apple's iOS ping examples and see if I can have the device ping itself to stimulate its own wireless adapter (127.0.0.1).
推荐答案
通过我在iOS设备的网络应用程序方面的工作，我发现他们的网络适配器有两种不同的模式，让我们把它们称为主动和被动。我没有找到任何关于此的文档。以下是我的发现：
Through my work on networking apps for iOS devices I have revealed that their network adapters have two different modes, let's call them active and passive. I did not manage to find any documentation on this. Here are my findings:
-
只要处于活动模式，适配器就会非常敏感。我的响应时间为3-5ms。
As long as in active mode, the adapter is quite responsive. I have response times of 3-5ms.
经过一段时间不活动后，iOS的网络适配器从主动模式转为被动模式。发生这种情况的时间取决于实际的设备型号。第三代iPad大约200ms。对于iPhone 4，它更像是50ms。
After some time of inactivity, the network adapter of the iOS falls from active to passive mode. The time for this to happen, depends on the actual device model. 3rd gen iPad it is around 200ms. For the iPhone 4 its more like 50ms.
ping请求或TCP数据包会将适配器从被动模式移动到主动模式。这可能需要50毫秒到800毫秒，平均大约200毫秒。
A ping request or a TCP packet will move the adapter from passive to active mode. This may take anything from 50ms to 800ms, with an average of around 200ms.
这种行为完全可以通过发布来重现ping命令。例如，
This behavior is completely reproducible by issuing ping commands. E.g.
ping -i 0.2 <ios-device-ip>
将ping间隔设置为200ms并使我的iPad网络适配器保持活动状态。
sets the ping interval to 200ms and keeps my iPads network adapter in the active state.
如果适配器（通常情况下）在被动模式下忽略UDP数据包，则此行为与您的观察结果完全一致。 wireshark活动可能会将其保持在活动模式，因此它将获得UDP。
This behavior is completely consistent with your observations, if the adapter (more often than not) ignores UDP packets when in passive mode. The wireshark activity probably keeps it in active mode so then it would get the UDPs.
检查ping技巧是否有帮助。
Check out whether the ping trick helps.
通过打开并连接设备本身的两个插槽并定期发送自己的数据包，可能会使iDevice的网络适配器保持活动状态。这会引入一些最小的开销。
One probably could keep the network adapter of the iDevice in the active state by opening and connecting two sockets on the device itself and regularly sending itself packets. This would introduce some minimal overhead.
至于为什么苹果公司决定实施这样的功能，我只能推测。但是可能保持适配器有效会花费足够的电池电量来合理这样的设计选择。
As to why apple decided to implement such a feature, I can only speculate about. But probably keeping the adapter active costs sufficient battery power to legitimate such a design choice.
希望这会有所帮助。
这篇关于iOS上的GCDAsyncUdpSocket缺少多播数据报的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
