Multipeer connectivity framework: Stability and Recommendations

Question

I'm working on a project that uses MC framework as a communication channel, and after some tests I have the perception that this channel is somehow unstable to rely on.

I've been following Apple's documentations and videos in order to use the framework properly, but happens that:

• peers get disconnected kinda' often after paired, and even more ofter if I pair more than one peer.
• some data packages have mixed data

Is there any kind of recommendation to work with the framework? i.e:

• Specific project settings? (i.e: is there something in the capabilities section that needs to be enabled?)
• Multithreading restrictions? (i.e: always call mc methods from the same thread)
• Restrictions in terms of the amount of data to be sent?

I found this link that mentions something about the framework not performing ok under stress. That's the kind of advice I'm looking for :).

For the record:

• I'm using an implementation based on this post since Apple's project is not working for me.
• I'm using only one MCSession for all peers I try to pair with
• Encryption preference is set to MCEncryptionNone
• Using sendData: and sendResourceAtURL: to communicate with peers.

Answer 1

I'm using the MC framework in a game and have found a few workarounds for its apparent instability:

1) I use a "keep alive" transaction sent every 15 seconds to maintain activity on the links. I found that this resolves almost all the connection losses I was experiencing.

2) I dispatch all processing triggered by data reception to the main thread and never carry any MCPeer nor MCSession objects between threads (except for the initial connection protocol). I also did that to minimize the time spent in the data reception code so that the thread used by MC regains control as fast as possible (which I also found was a source of some disconnects). I do not apply this rule for sending data (only when receiving)

3) I have NOT found a clean solution to the repetition of peers that appears when trying to establish a connection (both using the standard UI and my own). So far comparing MCPeer IDs to avoid duplicates only seems to remove some of the duplication. Also, it seemed that using the same MCSession for advertising (MCAdvertiserAssistant) and connecting to peers caused some conflicts so i'm using a new, separate MCSession instance every time I start the assistant.

Answer 2

I'm using it in an app that transfers a large quantity of data regularly. A couple of workarounds have helped:

• As soon as the connection to a peer is established, set up an NSOutputStream/NSInputStream pair to use for communication. Don't use the send data or send resource methods in the multipeer connectivity framework at all.

• If an unexpected disconnect occurs, the state of the MCSession object cannot be trusted - tear it down and start again from scratch. UPDATE: An unexpected disconnection here is either of the streams being closed by the other end of the connection.

• Prompt your user to check that all devices are on the same WiFi access point. If the peers are on the same network segment, but a different Wifi the browsers will see the advertisers and be able to connect, but will disconnect a few seconds later.

Update:

To establish an output stream:

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

        case MCSessionStateConnected:
            outputStream = [session startStreamWithName:@"Stream" toPeer:peerID error:&error];
            // Setup a stream handler for the stream and open it
            break;
        // ...
    }
}

To establish an input stream, implement this method is MCSessionDelegate:

-(void)session:(MCSession *)session didReceiveStream:(NSInputStream *)stream withName:(NSString *)streamName fromPeer:(MCPeerID *)peerID
{
    // Setup a stream handler for the stream and open it
}

This will get called as the other end of the connection opens it's output stream.

Now you have two streams ready to use for bi-directional communication.