Internal Messages

Introduction

This section defines messages sent over the IPC shared memory message bus by applications that are included in the core n2svcd package.

These message formats are documented for the benefit of application developers and maintainers. The structures defined in some of these messages are also mirrored in some external configuration or API definitions.

Message Context

In most IPC message passing, the $sender_context and/or $context contains a single integer which is the “Instance Index” within the sending or receiving application. This is a simple lookup key into the application’s instance map.

i.e. For a simple one-shot request response the following is normal behavior:

1. A instance within the requesting app wants to send a request. It first obtains a handle for the destination application.

2. The sender calls send_message specifing the destination application handle, and the message name.

3. The sender sets the $sender_context to be its own instance index.
   The $context (which is the receiver context) is always undef at the start of the interaction.

4. The receiving application receives the one-shot request and creates its own internal instance to process it. It performs (usually asynchronous) processing, and at some time later will send back a response by calling send_message back to the original sender.

5. The $context on the response will be set to be the original $sender_context. If this is the end of the transaction (i.e. if this is a simple request/response) then the $sender_context for the response will be undef.

6. On receiving the response, the application takes the $context and uses that as the instance index to look up in its hash of instances. It can find the original sender instance and resume processing for that instance.

If the transaction is more than a simple one-shot response, then the $sender_context for the response will contain the far-end’s instance index which allows both applications to maintain context during the interaction.