• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Distributed Objects question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributed Objects question


  • Subject: Re: Distributed Objects question
  • From: "Michael Ash" <email@hidden>
  • Date: Thu, 20 Jul 2006 23:28:07 -0400

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


  • Follow-Ups:
    • Re: Distributed Objects question
      • From: Mike Kobb <email@hidden>
References: 
 >Distributed Objects question (From: Mike Kobb <email@hidden>)

  • Prev by Date: Re: Environment/permissions on NSTask-launched app
  • Next by Date: Re: Newbie question about Authorization Services
  • Previous by thread: Re: Re: Distributed Objects question
  • Next by thread: Re: Distributed Objects question
  • Index(es):
    • Date
    • Thread