Important: This document may not represent best practices for current development. Links to downloads and other resources may no longer be valid.
For interprocess communication, you should use XPC instead; see XPC Services API Reference for more information.
Configuring a Connection
You can control some factors of distributed objects communication by configuring
NSConnection objects. You can set timeouts to limit the amount of time an
NSConnection object waits on a remote message, set the mode it awaits requests and responses on, and control how an
NSConnection object manages multiple remote messages. In addition to these parameter settings, you can change an
NSConnection object’s registered name or root object for dynamic alteration of your distributed application.
NSConnection object uses two kinds of timeouts, one for outgoing messages and one for replies. An outgoing network message may take some time to send. Once it goes out, there is usually a delay before any return value arrives. If either of these operations exceeds its timeout, the
NSConnection object raises an
NSPortTimeoutException. You can set the values for these timeouts with the
setReplyTimeout: messages, respectively. By default these timeouts are set to the maximum possible value.
NSConnection objects that vend objects await new connection requests in
NSDefaultRunLoopMode (as defined by the
NSRunLoop class). When an
NSConnection object sends a remote message out, it awaits the return value in
NSConnectionReplyMode. You cannot change this mode, but you can use it to set up
NSTimer objects or other input mechanisms that need to be processed while awaiting replies to remote messages. Use
addRequestMode: to add input mechanisms for this mode.
NSConnection object forwards remote messages to their intended recipients as it receives them. If your application returns to the run loop or uses distributed objects either directly or indirectly, it can receive a remote message while it is already busy processing another. Suppose a server is processing a remote message and sends a message to another application through distributed objects. If another application sends a message to the server, its
NSConnection object immediately forwards it to the intended recipient, even though the server is also awaiting a reply on the outgoing message. This behavior can cause problems if a remote message causes a lengthy change in the server application’s state that renders it inconsistent for a time: Other remote messages may interfere with this state, either getting incorrect results or corrupting the state of the server application. You can turn this behavior off with the
setIndependentConversationQueueing: method, so that only one remote message is allowed to be in effect at any time within the
NSConnection object’s thread. When independent conversation queueing is turned on, the
NSConnection object forwards incoming remote messages only when no other remote messages are being handled in its thread. This only affects messages between objects, not requests for new connections; new connections can be formed at any time.
One other way to configure a named
NSConnection object is to change its name or root object. This effectively changes the object that applications get using the techniques described in Getting a Vended Object, but does not change the proxies that other applications have already received. You might use this technique to field-upgrade a distributed application with an improved server object class. For example, to install a new server process have the old one change its name, perhaps from “Analysis Server” to “Old Analysis Server”. This hides it from clients attempting to establish new connections, but allows its root object to serve existing connections (when those connections close, the old server process exits). In the meantime, launch the new server which claims the name “Analysis Server” so that new requests for analyses contact the updated object.
Note that for inter-host communication, you cannot use the default connection, default
NSPort subclass, or default port name server. You must use an
NSPort subclass that supports inter-machine communication, such as
NSSocketPort. You might configure the server as shown in the following code fragment.
NSSocketPort *port = [[NSSocketPort alloc] init];
NSConnection *connection = [NSConnection connectionWithReceivePort:port sendPort:nil];
[[NSSocketPortNameServer sharedInstance] registerPort:port name:@"doug"];
You would then configure the client as follows.
NSSocketPort *port = [[NSSocketPortNameServer sharedInstance] portForName:@"doug" host:@"*"];
NSConnection *connection = [NSConnection connectionWithReceivePort:nil sendPort:port];