Re: [Q] Characteristics of different Inter Process Communication mechanism on Mac?

  • Finlay Dobbie wrote:

    > On 07/09/07, JongAm Park <joshua_park2006-applelist...> wrote:
    >> Hello.
    >> I became curious about IPC mechanisms on the Mac platform.
    >> Well.. there are at least 4 different type of IPC mechanism as far
    >> as I
    >> know.
    >> 1. AppleEvent
    >> 2. NSDistributedNotification
    >> 3. Remote Messaging
    > I believe the correct term you're looking for is "Distributed
    > Objects".
    >> 4. Conventional IPC mechanisms based on socket/pipe/shared memory
    > 5. Mach IPC

    6. BSD notifications

    >> I guess the method 4 is the basis of others.

    According to Apple, they all sit atop Mach messaging. Apple provide a
    summary of IPC options here:

    >> Although Apple pushes the AppleEvent for scriptable application,
    >> you can
    >> also use the mechanism for a simple IPC purpose, right? As far as I
    >> know, the AppleEvent was introduced as an IPC mechanism for the
    >> System 7.

    Yes and yes. Apple event IPC is basically just RPC. You can implement
    a query-driven Apple Event Object Model on top of it if you want to
    provide clients with a high-level interface for interacting with your
    application's data model, but this isn't a requirement and for purely
    private APIs may not be necessary/worth the effort.

    >> NS(Distributed)Notification mechanism seems to be widely used for
    >> Cocoa/Objective-C programmers nowadays.

    Note that NS/BSD notifications serve a different function to Apple
    events/distributed objects: the former for one-to-many broadcasting,
    the latter for issuing one-to-one commands.

    >> However, are there any special use cases where one method is
    >> preferred
    >> to others?

    Use NS/BSD notifications for event-driven interactions and AE/DO for
    imperative ones.

    > Distributed Notifications and DO have a higher overhead
    > (and DO requires you to use Foundation),

    I think higher overheads are true of any high-level IPC mechanism -
    e.g. Apple events require Carbon and are also slower than lower-level
    systems like Mach messaging and sockets. You're trading raw
    performance for features and convenience.

    I'd say that if you've two Cocoa applications that need to
    communicate with one another and you don't need to make the API
    available to third-parties then DO would be simplest.

    > AppleEvents are useful for
    > scripting and legacy Carbon code but probably unnecessarily fiddly
    > compared to "modern" alternatives,

    Apple event IPC is quite "modern" (except perhaps for its use of 4-
    byte OSTypes rather than more readable strings as keys) and
    straightforward enough to use for basic message passing, and it's
    pretty much the standard choice for providing publically accessible
    imperative APIs to desktop applications.

    The Apple Event Manager's C API is a bit longwinded and low-level but
    serviceable enough for this, and there are various higher-level APIs
    you can use on the client and/or server side to make life easier: the
    AEBuild* family of functions (client side), NSAppleEventDescriptor,
    NSAppleEventManager (server side), Cocoa Scripting (server side),
    objc-appscript (mainly client side), Scripting Bridge (client side;

    Things only really get fiddly if your server application needs to
    provide an Apple Event Object Model. For legacy reasons (i.e. process
    switching in OSes 7-9 was appallingly inefficient), the AEOM design
    is optimised towards fewer, more complex messages rather than many
    simple messages, and this increase in complexity makes designing and
    implementing a robust, reliable API to your server application a non-
    trivial task. (Even Apple's own Cocoa Scripting framework - which
    provides much of the underpinnings for implementing server side Apple
    event support - still contains flaws and bugs here after several years.)

    > sockets and pipes are compatible
    > with other operating systems, and Mach messaging can be very fast and
    > flexible.

    Note that Apple do advise against using Mach messaging unless you
    have a pressing need to do so.

    > It really depends on what technologies your processes are implemented
    > in, what they need to be compatible with, how often you'll be sending
    > messages, how much data you want to shift between them, etc.

    Agreed. If the OP wants more specific advice and recommendations,
    it'd help to say more about what it is they're writing, what it needs
    to do, and how it'll be used and by who.


previous month september 2007 next month
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today