• 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: Interprocess communication on Mac OS X
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interprocess communication on Mac OS X


  • Subject: Re: Interprocess communication on Mac OS X
  • From: Ryan McGann <email@hidden>
  • Date: Thu, 30 Jan 2003 23:25:10 -0800

On Thursday, January 30, 2003, at 04:52 AM, Stiphane Sudre wrote:

On Thursday, January 30, 2003, at 09:54 AM, Ryan McGann wrote:

Can anybody give me a suggeston on how we should implement communications in a multi-process environment? Here's the scenario:

We have several processes, each of which may or may not be running at any time. There is always one process running, our daemon, which runs as root and is started via a StartupItem. The rest of the processes are a mixture of command line tools, background-only applications and Cocoa applications.

We need to communicate between all the process(es). For example my daemon needs to tell our application that the preferences were changed by the daemon, and vice versa. Most of the time the data that we're sending is Foundation/CoreFoundation types like CFStrings.

On Mac OS X there are a plethora of IPC mechanisms, but I can't find one that I like.

- AppleEvents: Plagued by bootstrap server issues and has problems being used in GUI-less applications in Jaguar (it's used by some of our other apps and I know the problems they've gone through on this one, so it's basically out as an option).

- BSD sockets: Has no problems with bootstrap server issues and can be used anywhere, but are slower than other lower-level mechanisms, and harder to use with CF/Foundation types.
- CFMessagePort: Message ports created by processes in the root boostrap context cannot be seen by non-root processes when started from the command line (e.g. our app wouldn't be able to send messages to the daemon if the daemon were killed by me during debugging)
- CFNotifiticaitonCenter: Since it's implemented using CFMessagePort, has all of the above problems plus the fact that it's not very secure (e.g. any application will receive our >> notifications).
- CFMachPort: Has problems of CFMessagePort since it uses the same privileges, plus the fact that it's much more messy
- FIFOs: Same pros/cons as BSD sockets

So, fellow developers, which would you choose? I lean towards BSD sockets simply because they have no known issues with bootsrap contexts and other things I barely understand, but I like the APIs for CFMessagePort better simply because it's easier to pass CF/Foundation types to it, which is what our application uses.

From what I've experienced in both 10.1 and 10.2, your description is 90% accurate. The other 10% are for:

- the CFNotifiticationCenter thing is working better than the CFMessagePort thing as the notifications are seen by non root processes.
Yes, CFNotificationCenter works for going from privileged to non-privileged. Unfortunately going the other way doesn't work.

It's possible to implement a solution like this:

- CFNotifiticationCenter for Daemon to Application
- CFMessagePort for Application to Daemon
I thought about that, and it's definitely doable but a nasty hack. Since I'm starting over, I was hoping to come up with something cleaner for a fresh start.

The BSD sockets solution may work but it's a nightmare to handle all the cases: time-out, what happens if you communication is blocked by a bad ipfw rule, read, write size limitations, etc...
Yes, BSD sockets has many limitations and hazards associated with it.

The only issue I'm seeing and experiencing with the solution above is the fact that you can't easily debug this solution due to the bootstrap issue which was not there on 10.1. I'm still waiting for an Apple's explanation on this new bug introduced in 10.1.
Yes, debugging it is a pain, but it also brings up another issue for us. As a safety precaution the current version will load a process if it's not running already (like if some malicious user had killed it). We can't do that, because if the process is started up in the current boostrap context instead of the pre-login boostrap context, we can't "see" it. We wouldn't be able to have such a safety net if we choose CFMessagePort (or anything based on it, like distributed objects).

I was hoping I was missing some glaringly obvious choice. Of course, as was pointed out earlier, I can use Mach ports. I have the code for CFMessagePort to base my code on, but I'm 100% unfamiliar with Mach ports so it would be a very real test.

Thanks,
Ryan

There are three kinds of people in the world: Those that can count, and those that can't.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
  • Follow-Ups:
    • Re: Interprocess communication on Mac OS X
      • From: Stéphane Sudre <email@hidden>
  • Prev by Date: Re: Adding design-time 'live' functionality to IB palette items
  • Next by Date: rendering 256 color image in NSBitmapImageRep
  • Previous by thread: Interprocess communication on Mac OS X
  • Next by thread: Re: Interprocess communication on Mac OS X
  • Index(es):
    • Date
    • Thread