Connection successful only 10% of the time

[sudeepag]

I have set up PeerKit as per the example from the Cards Against app and have managed to get two devices to connect to each other.

However, this connection is only successful ~10% of the time. The other times, .onDisconnect is called right away. Is there any reason why this is happening, or am I doing something wrong?

Also, what is the procedure to attempt a reconnection after the connection is unsuccessful? Should I call .transceive again after creating a new Transceiver?

[danshev]

Also seeing this behavior -- any updates?

[jpsim]

Can you confirm that the problem is with PeerKit rather than Multipeer Connectivity? MPC itself isn't necessarily a paragon of reliability.

[danshev]

Fair point; will investigate MPC directly.

Any guidance on @sudeepag 's question:

"Also, what is the procedure to attempt a reconnection after the connection is unsuccessful? Should I call .transceive again after creating a new Transceiver?"

[jpsim]

I'm not sure, I haven't touched PeerKit in a while.

[dkun7944]

@danshev Any progress on this? I'm noticing the same issue with my own app, though I used the ConnectionManager struct from Cards Against.

[danshev]

@dkun7944 unfortunately, I concluded it was the general unreliability of the MPC framework.

[pdyakov]

I found that problem is in Advertiser class in didReceiveInvitationFromPeer handler: let accept = mcSession.myPeerID.hashValue > peerID.hashValue Most of the time it resolves to "false" which lead to disconnection. If I change it to "true" peers connecting successfully all the time. @jpsim can you please review this line? Why current peerID hash should be greater then external peerID hash for accepting connection?

[ashtonmeuser]

👍

[stevenbedrick]

I ran into similar problems, and eventually traced it back to the same place that @pdyakov did... my guess is that this test might be here to prevent an Advertiser from accepting an invitation from a Browser that was running on the same device (as in the case of transceiving)? If so, it should probably be comparing the hashValue of myPeerID/peerID's displayName properties. I've made that change in my local version of PeerKit, and it seems to be helping quite a lot, but am not confident enough in my understanding of the issue to submit a pull request. @jpsim, I'd be happy to do so if my reasoning is correct.

[qiulang]

I believe this is to fix a problem in iOS7 https://developer.apple.com/library/content/qa/qa1869/_index.html

If you don't need to support iOS 7 you can just accept invitation.

[stevenbedrick]

That certainly does appear to be the explanation, thanks, @qiulang!

[qiulang]

I think the main problem with current implementation is when peers first connected then disconnected, they won't connect again. Because when after they accept the invitation, advertiser.stopAdvertising(). So I added a state property in Session and re-start advertising when disconnect.