我正在构建一个具有服务器和客户端的 Objective-C 应用程序。 客户端可以向服务器发送更新，并且服务器需要能够向每个连接的客户端发送更新。 我一直在考虑如何最好地实施这个系统，但我想征求您的建议。
目前，我认为当有新的更新可用时，服务器将使用线程将更新依次发送给每个客户端。 如果客户端超时，它们就会断开连接。
我的网络经验很少，所以想请教您的见解。
您认为这个系统运作良好吗？
如果是这样，您对如何进行线程有什么建议吗？ 你可以指点我一些 NS 课程吗？ 我想，必须有某种我可以使用的队列。
还有其他想法吗？
编辑：我预计客户端数量最多不会超过 50 左右。
I'm building an Objective-C app that has both a server and a client. The client can send updates to the server, and the server needs to be able to send updates to each connected client. I've been thinking about how best to implement this system, but am asking for your suggestions.
Currently, I'm thinking that when new updates are available, the server will use threads to send the update to each client in turn. If a client times out, they are disconnected.
I have very little networking experience, so am asking your insight.
Do you think that this system would work well?
If so, do you have any suggestions about how to do the threading? Any NS classes you can point me at? There's got to be some kind of queue I can use, I'm thinking.
Any other thoughts?
EDIT: I do not expect the client count to get much above 50 or so, at the max.
发布评论
评论（5）
只要客户端和服务器都是 OS X 应用程序，并且都可以使用 Cocoa 框架用 Objective-C 编写，我强烈建议您查看 Cocoa 中的分布式对象 (DO) 技术。 我不会尝试在这里提供分布式对象教程，只是解释为什么它可能有用...
DO 为您处理异步网络详细信息（您的所有客户端更新都可以在单个线程上发生）。 此外，与远程对象（客户端到服务器或反之亦然；一旦建立连接，DO 就是双向的）通信的语义与进程内通信非常相似。 换句话说，一旦您引用了远程对象（实际上是一个
NSDistantObject，它充当连接另一端对象的代理），您的客户端代码就可以向远程对象发送消息对象就好像它是本地的一样：来自客户端或
来自服务器。 在阅读 分布式对象编程指南。
使用 DO 的缺点是你必须依赖 Cocoa； 编写使用分布式对象进行通信的非 Cocoa 客户端或服务器将非常困难。 如果您有可能想要非 Cocoa 客户端或服务器实现，那么您不应该使用 DO。 在这种情况下，我会推荐一些简单的、具有大量跨平台和语言支持的东西。 基于 HTTP 的 REST 风格的 API 是一个不错的选择。 看看 Cocoa URL 加载系统 文档，了解如何实现 HTTP 请求和响应的信息。 查看 Apple 的 CocoaHTTPServer 示例代码或 code.google.com 项目同名，了解有关在 Cocoa 代码中实现 HTTP 服务器的信息。
作为最后一个选择，您可以查看 Cocoa Stream 编程指南 如果你想实现自己的网络协议。 NSStream 的子类将允许您监听网络套接字并处理对该套接字的异步读取/写入。 许多人使用 AsyncSocket 来实现此目的。 它包装了（较低级别的）CFStream 和 CFSocket，并使编写网络代码变得更加容易。
As long as both client and server are OS X apps and can both be written in Objective-C using the Cocoa frameworks, I would highly recommend you take a look at the Distributed Objects (DO) technology in Cocoa. I won't try to give a tutorial in Distributed Objects here, just explain why it might be useful...
DO handles asynchronous network details for you (all your client updates could happen on a single thread). In addition the semantics of communication with a remote object (client to server or visa versa; DO is bidirectional once the connection is established) are very similar to in-process communication. In other words, once you have a reference to the remote object (really an
NSDistantObjectwhich acts as a proxy to the object on the other end of the connection), your client code can send messages to the remote object as if it were local:from the client or
from the server. I'll leave the details of setting up the connection and for getting the remoteServer or remoteClient reference to you after reading the Distributed Objects programming guide.
The downside of using DO is that you are tied to Cocoa; it will be very difficult to write a non-Cocoa client or server that communicates using Distirbuted Objects. If there's a chance you may want to have non-Cocoa client or server implementations, you should not use DO. In this case, I would recommend something simple with a lot of cross-platform and language support. A REST-style API over HTTP is a good option. Have a look at the Cocoa URL Loading System documentation for info on how to implement HTTP requests and responses. Have a look at Apple's CocoaHTTPServer example code or a code.google.com project of the same name for info on implementing an HTTP server in your Cocoa code.
As a very last option, you can take a look at the Cocoa Stream Programming Guide if you want to implement your own network protocol.
NSStream's subclasses will let you listen on a network socket and handle asynchronous reads/writes to/from that socket. A lot of people use AsyncSocket for this purpose. It wraps the (lower-level) CFStream and CFSocket and makes writing network code somewhat easier.当服务器向客户端发送更新时，让一个线程处理所有更新并使用异步套接字可能会更容易。 当然，这也取决于您需要处理的客户数量。
When the server sends updates to the clients, it would probably be easier to just have one thread handle them all, and just use async sockets. Of course this would depend on how many clients you had to deal with too.
苹果开发者端有几个网络示例。
我建议您检查一下 URLCache，它可以下载。
引用苹果文档中的这个例子：
There's several networking examples in the apple developer side.
One I would recommend that you check out is the URLCache, which can be downloaded.
Quoting from the Apple's documentation for this example:
一个有趣的选择是来自 BLIP 协议.mooseyard.com/" rel="nofollow noreferrer">延斯·阿尔夫克。 它就像 BEEP 的精简版本：面向消息的网络系统。 它基本上为双向消息管道提供了低级抽象，因此您可以专注于在其之上分层通信协议。
它有一些值得追随者，例如 Marcus Zarra（CoreData 圣经的作者）和 Flying Meat 软件的 Gus Mueller。
An interesting option is the BLIP protocol from Jens Alfke. It's like a stripped down version of BEEP: a message oriented networking system. It basically provides the low-level abstractions for a bidirectional message pipe so you can concentrate on layering your communication protocol on top of it.
It has some worthy followers such as Marcus Zarra (author of the CoreData bible) and Gus Mueller of Flying Meat software.
我不知道你打算如何设计你的系统，但通常服务器无法连接到客户端； 客户端必须发起通信。 由于客户端的下限为 50 个，您可能不会考虑类似 Web 服务器/客户端的实现...
也就是说，基本上有两种方法来处理客户端服务器通信：
1. 客户端定期轮询服务器以获取更新
2. 客户端与服务器保持开放连接，服务器使用众所周知的（双方都理解的）协议进行响应。
I don't know how you plan to design you system, but usually a server cannot connect to a client; the client must initiate the communication. With a low limit of 50 clients, you may not be looking at a web-server/client-like implementation...
That said, there are basically two ways to handle client server communication:
1. The client polls the server periodically to get updates
2. The client keeps a connection open to the server and the the server responds with a well known (as in both sides understand it) protocol.