3

I've looked into Apple's documentation but is still uncleared about one thing, the session.

  1. When - (void)advertiser:(MCNearbyServiceAdvertiser *)advertiser didReceiveInvitationFromPeer:(MCPeerID *)peerID withContext:(NSData *)context invitationHandler:(void (^)(BOOL, MCSession *))invitationHandler is called, we need to pass in a session to the invitationHandler. What will happen to this session? When A invites B to join a session that A created, does B provide a new session to A as well? What is inside B's session? Is it just A alone or does it include all the peers that are currently in A's session? Should B keep track of the session that's been used to accept A's invitation? Inside this article, http://nshipster.com/multipeer-connectivity/, the tutorial creates a new session on the fly and uses it to accept the invitation, wouldn't you lose the session once the function is ended; thus losing information to connected peers?

  2. Assuming that B, C and D are all invited by A, and now B wants to send something to C. Is it required that B needs to send the information to A first or can B send the information directly to C?

  3. According to the Apple's documentation, a single session can only hold no more than 8 peers. Is it possible to make an array of sessions so that you can invite more than 8 people to join your device? If that is the case, does client also need to respond with an array so that it can carry more than 8 peers in its list?

  4. Assuming A and B are now connected, and A now invites C to join. How does B know that C is now in the session?

Thank you for reading such a long post.

rmaddy
  • 314,917
  • 42
  • 532
  • 579
Alex Su
  • 277
  • 4
  • 14

3 Answers3

1

There's not much in the way of documentation on Multipeer Connectivity, so these answers are based on my own experiments:

  1. There are lots of questions inside this one question, but in a nutshell A's session(s) manage invitations that A has sent or accepted. So if B invites and A accepts, the session that A passes when accepting will then be used in the MCSessionDelegate session: peer: didChangeState: callback to say whether the connection happened. At this point the connectedPeers property of A's session will contain B (if the connection succeeded). The session that B used to send the invitation will also get the same callback once A accepts, and will contain A in connectedPeers. Neither A nor B will have any information on the other's session that managed this connection between them. And yes, if you want to send any data to the newly connected peer, you need to keep a reference to the session that handled the connection. I've yet to see any real advantage in creating a new session for each invitation.

  2. Based on the above, B has no information on who A is connected to. So if A is connected to B,C and D, the only peer B knows about is the peer that it connected to - A. What Multipeer Connectivity offers here is the ability for B to discover C or D via A. So if the A-B connection was made over WiFi, and A-C over Bluetooth, but B does not have Bluetooth enabled, and C is on a different WiFi network to B, B and C can still discover each other through A. The process of inviting and accepting is still up to B and C to handle though.

  3. I answered a question about session management here that may be helpful Best option for streaming data between iPhones

  4. B doesn't know anything about A connecting to C. All B can do is discover C for itself and add C to it's own session.

Community
  • 1
  • 1
ChrisH
  • 4,468
  • 2
  • 33
  • 42
1

  1. From quickly looking over Chris's answer it seems accurate from what I've been working on at my job.

  2. I'm currently working on a game using multipeer connectivity and have found that:

    (Assuming everyone is on wifi) if A connects to B and A connects to C, then B will be connected to C and be able to send messages to C.

    the Multipeer Framework is a P2P framework and automatically connects everyone together.

    even if (as in my current project) you set it up as a Server-client model, all peers will still be connected and you can send messages between B and C without going through A. Depending on what you are doing with your app.

  3. Go with Chris's answer

  4. Addressed in #2

I recommend looking at the example project in the Apple Docs and carefully watch what happens in the debug area when you connect.

Also, as a side note:

Scenario:(A is only on wifi),(B is on wifi and bluetooth),(C is on bluetooth only)

if A connects to B via wifi, and B connects to C via bluetooth, A will still be connected to C but you won't be able to send a message from A directly to C because they are on different networks.

SirCharlesWatson
  • 400
  • 1
  • 12
  • If you have at least 3 devices to test with, it makes it a lot easier to be able to watch what is happening between all the devices. – SirCharlesWatson Apr 02 '14 at 20:54
0

@SirCharlesWatson:

(Assuming everyone is on wifi) if A connects to B and A connects to C, then B will be connected to C and be able to send messages to C.

the Multipeer Framework is a P2P framework and automatically connects everyone together.

My question is: when B automatically connected to C, will B & C receive a state change notification on the existed session?

  • A: session:peer:B didChangeState(MCSessionStateConnected)
  • B: session:peer:A didChangeState(MCSessionStateConnected)
Community
  • 1
  • 1
fan2
  • 181
  • 2
  • 4