我正在构建一个既有服务器又有客户端的 Objective-C 应用程序。客户端可以向服务器发送更新，而服务器需要能够向每个连接的客户端发送更新。我一直在考虑如何最好地实施这个系统，但正在征求您的建议。
目前，我在想，当有新的更新可用时，服务器将使用线程将更新依次发送给每个客户端。如果客户端超时，它们将断开连接。 我的网络经验很少，所以想请教您的见解。
你认为这个系统会运作良好吗？ 如果是这样，您对如何进行线程有任何建议？你可以指点我的任何NS课程吗？我在想，一定有某种可以使用的队列。
还有其他想法吗？
编辑：我预计客户数量最多不会超过 50 个左右。
【问题讨论】：
标签： objective-c cocoa networking communication-protocol
当服务器向客户端发送更新时，让一个线程处理所有更新可能会更容易，并且只使用异步套接字。当然，这也取决于您必须与多少客户打交道。
【讨论】：
只要客户端和服务器都是 OS X 应用程序并且都可以使用 Cocoa 框架在 Objective-C 中编写，我强烈建议您看看 Cocoa 中的Distributed Objects (DO) 技术。我不会尝试在这里给出分布式对象的教程，只是解释为什么它可能有用......
DO 为您处理异步网络详细信息（您的所有客户端更新都可能发生在单个线程上）。此外，与远程对象（客户端到服务器或反之亦然；一旦建立连接，DO 是双向的）通信的语义与进程内通信非常相似。换句话说，一旦您引用了远程对象（实际上是一个NSDistantObject，它充当连接另一端对象的代理），您的客户端代码就可以像发送消息一样向远程对象发送消息本地：
[remoteServer update:client];
来自客户或
[[remoteClientList objectAtIndex:i] update:server];
来自服务器。阅读Distributed Objects programming guide 后，我将留下设置连接以及获取remoteServer 或remoteClient 参考的详细信息。
使用 DO 的缺点是您与 Cocoa 相关联； 非常很难编写使用分布式对象进行通信的非 Cocoa 客户端或服务器。如果您可能希望拥有非 Cocoa 客户端或服务器实现，则不应使用 DO。在这种情况下，我会推荐一些简单的东西，有很多跨平台和语言支持。 HTTP 上的 REST 风格的 API 是一个不错的选择。查看 Cocoa URL Loading System 文档以获取有关如何实现 HTTP 请求和响应的信息。查看 Apple 的 CocoaHTTPServer 示例代码或 same name 的 code.google.com 项目，了解有关在 Cocoa 代码中实现 HTTP 服务器的信息。
作为最后一个选项，如果您想实现自己的网络协议，可以查看 Cocoa Stream Programming Guide。 NSStream 的子类将让您侦听网络套接字并处理对该套接字的异步读/写。很多人为此使用AsyncSocket。它包装了（较低级别的）CFStream 和 CFSocket，使编写网络代码更加容易。
【讨论】：
我不知道你打算如何设计你的系统，但通常服务器无法连接到客户端；客户端必须发起通信。如果客户端数量下限为 50 个，您可能不会考虑使用类似 Web 服务器/客户端的实现...
也就是说，基本上有两种方法可以处理客户端服务器通信： 1.客户端定期轮询服务器以获取更新 2. 客户端保持与服务器的连接打开，服务器以众所周知的（双方都理解）协议进行响应。
【讨论】：
在苹果开发者方面有几个网络示例。 我建议您检查的一个是可以下载的 URLCache。 此示例引用 Apple 的文档：
URLCache 是一个示例 iPhone 应用程序，它演示了如何从 Web 上下载资源，将其存储在应用程序的数据目录中，以及使用资源的本地副本。 URLCache 还演示了如何实现几个缓存策略：
【讨论】：
一个有趣的选项是来自Jens Alfke 的BLIP 协议。它就像BEEP 的精简版：一个面向消息的网络系统。它基本上为双向消息管道提供了低级抽象，因此您可以专注于在其之上分层您的通信协议。
它有一些有价值的追随者，例如Marcus Zarra（CoreData 圣经的作者）和 Flying Meat 软件的 Gus Mueller。
【讨论】：