GCDAsyncUdpSocket on iOS missing multicasted datagrams
Asked Answered
M

3

7

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).

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.

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);
    }
}

Solution for anybody who comes looking here in the future:

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>

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).

Mumbletypeg answered 28/10, 2012 at 21:59 Comment(5)
you do realize that UDP packets are not guaranteed to be delivered by design? your application needs to be able to handle this case.Olav
Yes, I know that UDP is unreliable but could it really be the cause for that many packets going uncaptured? Also, the app receives every packet without a problem as long as the NIC has monitor mode enabled.Mumbletypeg
@Mumbletypeg could you tell which device did you use?Polio
@Dudi Sure! As far as I can tell, this works on any iOS device. It's functionality has been tested on an iPod Touch (4th gen), iPad Mini, iPad 2, iPhone 5, and the simulator.Mumbletypeg
i have implemented these code but only one delegate is called "didreceivedata" other like socketdidconnect or other delegate method not caledLoathly
C
13

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:

  1. As long as in active mode, the adapter is quite responsive. I have response times of 3-5ms.

  2. 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.

  3. 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.

This behavior is completely reproducible by issuing ping commands. E.g.

ping -i 0.2 <ios-device-ip>

sets the ping interval to 200ms and keeps my iPads network adapter in the active state.

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.

Check out whether the ping trick helps.

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.

Hope this helps.

Conceivable answered 17/1, 2013 at 15:27 Comment(4)
Hmmmm very interesting. I never would have thought to try that. I will try this out tonight.Mumbletypeg
Yes, we were puzzling about the latency behavior for at least a month. ;-)Conceivable
It worked! I'm still missing some of the packets but it's a negligible amount. Thanks so much.Mumbletypeg
I have iPhone 4 and 5 with iOS 6. That don't solve the problem. CocoaAsyncSocket still missing multicasted package.Polio
I
1

I had the same issue.

Starting the network activity indicator solved that problem for me:

UIApplication* app = [UIApplication sharedApplication];
app.networkActivityIndicatorVisible = YES;
Iveyivie answered 2/5, 2013 at 19:9 Comment(0)
K
1

If you want to view the packet on the iOS device, you can tether your iOS device to a Mac and mount the wifi adapter using shell command rvictl. You can then use wireshark, tcpdump, etc. to monitor the traffic on your 802.11 interface on your iOS device.

As far as not receiving data until 3 to 7 seconds - Most likely your device is entering into power save mode (IEEE PSM) which is an 802.11 feature that essentially puts the wireless NIC to sleep.
PSM mode can yield poor performance on devices - especially in your case where you have periodic bursts of data every 1/2 second. Your periodic ping is waking the NIC up.

Kurtiskurtosis answered 11/1, 2014 at 4:41 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.