The IPC library - softgitron/potku-console GitHub Wiki

For reasons of modularity, security and availability, all modules of the project have been decided to have their own dedicated processes. To avoid writing a complete IPC suite for each module separately, a dedicated IPC library will be created. The aim of the library is to standardize all communication between the modules, regardless of the type of data being sent. The modules can merely use a simple command from the library, attach the relevant data and it will go where it's supposed to go swiftly and reliably.

The actual IPC data transfer will be done using Unix Domain Sockets. Sockets were decided to be the ideal fit for the project due to their TCP-style compatability and high data throughput. As such, modules could be able to be placed behind a TCP-communication on a different server with minimal code rewrites.

All data transferred from one module to another is expected to be in the standard core API format. As such, all data should be sent and received through the commands provided by the library instead of direct socket access.

TODO: List requirements

• a separate command for each call
• modules should use only commands that they require
• core API related documentation
• TODO: add more requirements

• TODO: define why separate layers are necessary
• TODO: define how and why each layer formats data

This is the outermost layer and holds all the data necessary to ensure the message is sent and received properly by the correct parties. All information in the control layer will be automatically inserted by the library itself with no module interaction. Necessary data is expected to be readble from the module, such as the name.

This layer is generated each time a message is sent between the modules.

• Session control header
  • Tells when to begin a new seperate communication session or to close the current one
  • Allows a single module to handle multiple different communications sessions through a single socket
  • Ensures all communication happens within a defined context
• Message sender
  • Name of the module which sent the request
  • Used to tell if the communication came from the expected party
  • Grabbed by the library from the module's info
• Message target
  • Name of the target module which is intended to receive the message
  • Used in preventing modules from handling unintended information
  • Specified in the command used in the module
• Session ID
  • Unique identifier for the current messaging session
  • Ensures that commands are always executed in the correct context
  • Generated per session at the start
• Message ID
  • Unique message identifier
  • Prevents accidental execution of unintended repeat commands
  • Generated per message
• Response flag
  • Tells if a message has been sent as a response to another message
  • Added in specific commands
• Main data body
  • The actual data the module wants to send
  • See the next section for more details

This layer will handle the core API formatting

TODO: Link to the core API specification for details once it's ready

• http response code
• http headers
• http verb
• http API path

The last message layer will simply contain arbitrary data in whatever format the sending module has decided. It can be anything from complete JSON files to simple IP-addresses as strings. The library is not concerned with the data located here and does not touch or process it in any way.

On module initialization, a socket will be opened by the core specifically for the started module.

TODO

TODO

TODO: Add the standard format for sending messages