There's not much in the way of documentation on Multipeer Connectivity, so these answers are based on my own experiments:
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 theconnectedPeers
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 inconnectedPeers
. 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.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.
I answered a question about session management here that may be helpful Best option for streaming data between iPhones
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.