Re: Distributed Objects question

FROM : Mike Kobb
DATE : Fri Jul 21 19:37:33 2006

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_removed>> 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
>