Objective-C networking - best practices?

问题:

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.

回答1:

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 NSDistantObject which 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:

[remoteServer update:client];

from the client or

[[remoteClientList objectAtIndex:i] update:server];

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.

回答2:

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.

回答3:

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:

URLCache is a sample iPhone application that demonstrates how to download a resource off the web, store it in the application's data directory, and use the local copy of the resource. URLCache also demonstrates how to implement a couple of caching policies:

回答4:

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.

回答5:

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.