Re: Distributed Objects question
Re: Distributed Objects question
- Subject: Re: Distributed Objects question
- From: Mike Kobb <email@hidden>
- Date: Fri, 21 Jul 2006 10:37:33 -0700
All of that is incredibly helpful. Thanks very much (and to Tom
Harrington as well)!
One question about something you brought up. The Cocoa DO docs
encourage setting a protocol for the connection as a way to reduce
the overhead of message dispatch. So, I have done that on the client
side, as shown in the docs, right after I call
rootProxyForConnectionWithRegisteredName.
As it happens, I do provide a delegate mechanism like the one you've
described in order to allow the server to send status messages to the
client. Similar to what I did on the server side, I make an
NSProtocolChecker with a second protocol (defining the status
messages), and pass it through from the client to the server (thanks
for the "oneway" tip, by the way -- I'll add that!)
So, the question: is there some way to inform the DO system that this
other direction of communication only uses that second protocol? It
was obvious how to do this on the client side, because I was having
to call rootProxyForConnectionWithRegisteredName, but on server side,
all I get is a message from the client containing an object (id).
Here's the declaration of my registration method:
- (BOOL)registerClient:(byref id)client withIdentifier:(int)ident;
So, it's not totally clear where I'd call setProtocolForProxy.
Thanks so much for your assistance.
--Mike
PS: I have implemented the notification stuff and the exceptions, and
they all work great (I tested with notification disabled first to
validate my exception handlers, then turned on the notifications).
On Jul 20, 2006, at 8:28 PM, Michael Ash wrote:
On 7/20/06, Mike Kobb <email@hidden> wrote:
Greetings,
If this is covered someplace in Apple's docs, please point me there.
I've looked and looked.
I'm using Distributed Objects to communicate between two Cocoa apps.
It all seems to work very well. My "server" app vends an object by
registering an NSProtocolChecker with the default NSConnection, and
the client gets the object just fine.
Here's what I couldn't find in the documentation. Let's say that the
server needs to shut down. Is there some graceful way for it to do
so to ensure that connected clients know that it has gone away, and
Another alternative to what's already been mentioned is to have each
client register a delegate of some sort with the server. DO works in
both directions pretty much transparently, so you can do this with
very little effort. Then when the server needs to tell the client
something, it can just send a message to all of the delegates.
Keep in mind that this means the *server* needs to watch out for
*client* disconnects. It would be a good idea to make the delegate
messages oneway void, and wrap everything in short timeouts and
exception handlers.
And, a more-general question. Apple's developer documentation says
that one should not depend upon notifications for critical events,
because although every effort is made to deliver them, they're not
guaranteed. In practice, just how reliable are they?
That only applies to distributed notifications, which are a very
different beast from regular notifications. If you're looking at using
notifications as a secondary communications channel between your
server and your clients then you'd be using the distributed kind. But
if you're just trying to catch NSConnectionDidDieNotification then
that's a local notification (that happens to be triggered by a remote
event).
Local notifications are *always* delivered, and they're generally
delivered instantly. You can look at them as a kind of superpowered
message dispatch; when somebody posts a notification, all of the
observers receive it right away, before the poster continues
executing.
Distributed notifications are, as you note, not guaranteed to arrive.
In practice I've never so much as heard of it actually happening.
However they ought to be avoided when possible, both because of this
and because it's a centralized system that has a lot of overhead
affecting all apps, not just your own. Since you already have a
communications channel set up, you shouldn't need to make another one.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden