Client GKSession think it's connected after denyConnectionFromPeer

I have a typical GKSessionModeServer/GKSessionModeClient setup.

When the server denies a client connection attempt with denyConnectionFromPeer:, the client's session:connectionWithPeerFailed: method is called, but then it receives a GKPeerStateConnected state change with my server's peerID. In other words the client thinks the connection succeeded while the server does not.

This seems to be at odds with common sense and the documentation for connectToPeer:withTimeout:, which says

If the connection to the remote peer is successful, the delegate’ session:peer:didChangeState: method is called for each peer it successfully connected to. If the connection fails or your application cancels the connection attempt, the session calls the delegate’s session:connectionWithPeerFailed:withError: method.

I know this doesn't say that the state change callback won't be called in the case of a connection failure, but the net result from the client's point of view is that a failed connection appears to result in a successful connection.

Clutching at straws I tried calling cancelConnectToPeer from the connectionWithPeerFailed callback, without result.

The client could work around this by ignoring the next GKPeerStateConnected,开发者_运维技巧 but this is kludgey and complicates reconnecting when the server starts accepting connections again.

So why can't the client session understand that it's over?

I have designed the same kind of application myself (GKSessionModeServer/GKSessionModeClient). When you refuse the connection to a peer, it will trigger the session:peer:didChangeState: delegate, with the GKPeerConnectionState argument set to GKPeerStateDisconnected. You just need to handle this properly in your code - I've never had any issue with that part whatsoever.