Why does my MCSession peer disconnect randomly?

Question

Im using MCNearbyServiceBrowser and MCNearbyServiceAdvertiser to join two peers to a MCSession. I am able to send data between them using MCSession's sendData method. All seems to be working as expected until I randomly (and not due to any event I control) receive a MCSessionStateNotConnected via the session's MCSessionDelegate didChangeState handler. Additionally, the MCSession's connectedPeers array no longer has my peers.

Two questions: Why? and How do i keep the MCSession from disconnecting?

Oblivion

I have the same issue but i'am getting disconnected after some data was sent. Have you resolved this? – Unsuspected

One item I noticed is that pausing in the debugger breaks the MCSession. I ended up coding a mechanism to reestablish the session if it gets dropped. – Oblivion

I have the same problem. I notice if one device is backgrounded and messages are sent to it then disconnects happen. – Pendergrass

@Oblivion how did you reconnect the session? – Pendergrass

i'm not automatically reconnecting. Instead I let the user know and then they can reconnect. I stop the advertiser and browser and null the session and then recreate them all. – Oblivion

did you fix this problem? I'm having issues – Kurd

Answer 1

This is a bug, which I just reported to Apple. The docs claim the didReceiveCertificate callback is optional, but it's not. Add this method to your MCSessionDelegate:

- (void) session:(MCSession *)session didReceiveCertificate:(NSArray *)certificate fromPeer:(MCPeerID *)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler
 {
     certificateHandler(YES);
 }

The random disconnects should cease.

Wabash

Still getting disconnects even after implementing this – Pendergrass

Doesn't fix it for me either (in swift) – Azzieb

If you get to the point where you have received the didChangeState message with a MCSessionStateConnected value, and can successfully send data, then you have made a connection and this is not your problem. One of the other answers might have more information. However if you (like me) are mystified why when you try to accept a connection, you see MCSessionStateConnecting, and then MCSessionStateNotConnected a few seconds later with no other explanation, then it is likely that the answer given here is exactly your problem. – Aiglet

Answer 2

UPDATE After using a support ticket to Apple, they confirmed that calling sendData too often and with too much data can cause disconnects.

I have had disconnects when hitting break points and when backgrounding. Since the break points won't happen on the app store, you need to handle the backgrounding case by beginning a background task when your app is about to enter the background. Then end this task when your app comes back to the foreground. On iOS 7 this gives you about 3 background minutes which is better than nothing.

An additional strategy would be to schedule a local notification for maybe 15 seconds before your background time expires by using [[UIApplication sharedApplication] backgroundTimeRemaining], that way you can bring the user back into the app before it suspends and the multi peer framework has to be shutdown. Perhaps the local notification would warn them that their session will expire in 10 seconds or something...

If the background task expires and the app is still in the background, you have to tear down everything related to multi-peer connectivity, otherwise you will get crashes.

- (void) createExpireNotification
{
    [self killExpireNotification];

    if (self.connectedPeerCount != 0) // if peers connected, setup kill switch
    {
        NSTimeInterval gracePeriod = 20.0f;

        // create notification that will get the user back into the app when the background process time is about to expire
        NSTimeInterval msgTime = UIApplication.sharedApplication.backgroundTimeRemaining - gracePeriod;
        UILocalNotification* n = [[UILocalNotification alloc] init];
        self.expireNotification = n;
        self.expireNotification.fireDate = [NSDate dateWithTimeIntervalSinceNow:msgTime];
        self.expireNotification.alertBody = TR(@"Text_MultiPeerIsAboutToExpire");
        self.expireNotification.soundName = UILocalNotificationDefaultSoundName;
        self.expireNotification.applicationIconBadgeNumber = 1;

        [UIApplication.sharedApplication scheduleLocalNotification:self.expireNotification];
    }
}

- (void) killExpireNotification
{
    if (self.expireNotification != nil)
    {
        [UIApplication.sharedApplication cancelLocalNotification:self.expireNotification];
        self.expireNotification = nil;
    }
}

- (void) applicationWillEnterBackground
{
    self.taskId = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^
    {
        [self shutdownMultiPeerStuff];
        [[UIApplication sharedApplication] endBackgroundTask:self.taskId];
        self.taskId = UIBackgroundTaskInvalid;
    }];
    [self createExpireNotification];
}

- (void) applicationWillEnterForeground
{
    [self killExpireNotification];
    if (self.taskId != UIBackgroundTaskInvalid)
    {
        [[UIApplication sharedApplication] endBackgroundTask:self.taskId];
        self.taskId = UIBackgroundTaskInvalid;
    }
}

- (void) applicationWillTerminate
{
    [self killExpireNotification];
    [self stop]; // shutdown multi-peer
}

You'll also want this handler in your MCSession delegate due to Apple bug:

- (void) session:(MCSession*)session didReceiveCertificate:(NSArray*)certificate fromPeer:(MCPeerID*)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler
 {
     if (certificateHandler != nil) { certificateHandler(YES); }
 }

Pendergrass

When backgrounding, can you maintain the connection when bringing the app back from background? – Hearn

You can as long as your background time does not run out. If it does, you have no choice but to kill the session or crash. – Pendergrass

@PsychoDad did you learn anything on what was considered calling sendData too often from your encounter with Apple DTS? – Foeman

Yes, they recommended not calling sendData too often (I limit it to about 30 times a second at most). In addition, if you debug or pause threads, peers will get disconnected. – Pendergrass

Answer 3

There are many causes of this, and the two answers thus far are both correct in my experience. Another which you'll find in other similar questions is this: Only one peer can accept another's invitation.

So, to clarify, if you set up an app where all devices are both advertisers and browsers, any devices can freely invite any others found to join a session. However, between any two given devices, only one device can actually accept the invitation and connect to the other device. If both devices accept each others' invitations they will disconnect within a minute or less.

Note that this limitation does not prevent the desired behavior because - unlike what my intuition stated before I built my multipeer implementation - when one device accepts an invitation and connects to another device they both become connected and receive connection delegate methods and can send each other messages.

Therefore, if you are connecting devices which both browse and advertise, send invitations freely but only accept one of a pair.

The problem of only accepting one of two invitations can be solved a myriad of ways. To begin, understand that you can pass any arbitrary object or dictionary (archived as data) as the context argument in an invitation. Therefore, both devices have access to any arbitrary information about the other (and of course itself). So, you could use at least these strategies:

• simply compare: the display name of the peerID. But there's no guarantee these won't be equal.
• store the date your multipeer controller was initialized and use that for comparison
• give each peer a UUID and send this for comparison (my technique, in which each device - indeed each user of the app on a device - has a persistent UUID it employs).
• etc - any object which supports both NSCoding and compare: will do fine.

Zucker

I thought this was my issue. So I concocted a convoluted delay invite even, but still neither of them connect. – Spatial

This was actually the issue: Please note: Bluetooth networking is not supported in Simulator. – Spatial

Answer 4

I've been having similar problems. It seems though that if I have run my app on one iOS device, and connected to another, then quit and relaunch (say when I rerun from Xcode), then I am in a situation where I get a Connected message and then a Not Connected message a little later. This was throwing me off. But looking more carefully, I can see that the Not Connected message is actually meant for a different peerId than the one that has connected.

I think the problem here is that most samples I've seen just care about the displayName of the peerID, and neglect the fact that you can get multiple peerIDs for the same device/displayName.

I am now checking the displayName first and then verifying that the peerID is the same, by doing a compare of the pointers.

- (void)session:(MCSession *)session peer:(MCPeerID *)peerID didChangeState:(MCSessionState)state {

    MyPlayer *player = _players[peerID.displayName];

    if ((state == MCSessionStateNotConnected) &&
        (peerID != player.peerID)) {
        NSLog(@"remnant connection drop");
        return; // note that I don't care if player is nil, since I don't want to
                // add a dictionary object for a Not Connecting peer.
    }
    if (player == nil) {
        player = [MyPlayer init];
        player.peerID = peerID;
        _players[peerID.displayName] = player;
    }
    player.state = state;

...

Withdrawn

This is still relevant, 2 years on in Swift3! – Equipment

Answer 5

I was disconnecting immediately after I accepted the connection request. Observing the state, I saw it change from MCSessionStateConnected to MCSessionStateNotConnected.

I am creating my sessions with:

[[MCSession alloc] initWithPeer:peerID]

NOT the instantiation method dealing with security certificates:

 - (instancetype)initWithPeer:(MCPeerID *)myPeerID securityIdentity:(NSArray *)identity encryptionPreference:(MCEncryptionPreference)encryptionPreference 

Based on Andrew's tip above, I added the delegate method

   - (void) session:(MCSession *)session didReceiveCertificate:(NSArray *)certificate fromPeer:(MCPeerID *)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler {
         certificateHandler(YES);
     }

and the disconnects stopped.

Stearn