客户端 GKSession 在拒绝连接后认为已连接

发布于 2024-10-23 13:33:14 字数 841 浏览 6 评论 0原文

我有一个典型的 GKSessionModeServer/GKSessionModeClient 设置。

当服务器使用 denyConnectionFromPeer: 拒绝客户端连接尝试时,客户端的 session:connectionWithPeerFailed: 方法将被调用,但随后它会收到 GKPeerStateConnected 状态更改我的服务器的peerID。换句话说,客户端认为连接成功,而服务器则认为连接成功。

这似乎与常识和 connectToPeer:withTimeout: 的文档不一致,其中说

如果与远程对等点的连接成功,则会为其成功连接的每个对等点调用委托的 session:peer:didChangeState: 方法。如果连接失败或您的应用程序取消连接尝试,会话将调用委托的 session:connectionWithPeerFailed:withError: 方法。

我知道这并不是说在连接失败的情况下不会调用状态更改回调,但从客户端的角度来看,最终结果是连接失败似乎会导致在成功的连接中。

我抓住了救命稻草,尝试从 connectionWithPeerFailed 回调中调用 cancelConnectToPeer,但没有结果。

客户端可以通过忽略下一个 GKPeerStateConnected 来解决此问题,但这很麻烦,并且当服务器再次开始接受连接时,重新连接会变得复杂。

那么为什么客户端会话不能理解它已经结束了呢?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

内心荒芜 2024-10-30 13:33:14

我自己设计了相同类型的应用程序(GKSessionModeServer/GKSessionModeClient)。
当您拒绝与对等点的连接时,它将触发 session:peer:didChangeState: 委托,并将 GKPeerConnectionState 参数设置为 GKPeerStateDisconnected
你只需要在你的代码中正确处理这个问题 - 我从来没有对这部分有任何问题。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文