Skip to content

IPC Inter process communication

Jump to bottom
Christopher Ross-Gill edited this page Aug 1, 2016 · 1 revision

This document is for discussing IPC requirements and options.

It would be nice to have a matrix or priority ranking, so we can see what our targets are, and how important each is.

Table of Contents

To daemon or not to daemon

This is the first question. Not because we need to answer it first, but because we need to keep it in mind when answering the other questions. For example, the format of endpoints may be different if they are only for local use versus net use.

Should we use a daemon, so there is only one model for IPC on a single machine as well as across the net? Can we still do everything we would want to do on a single machine without a daemon? What problems or challenges does a daemon pose? Can the implementation be such that if the endpoints are local, it can use something like a memory mapped file, and only require the daemon if remote endpoints are used?

See also: Threading

Endpoints

What do endpoints (addresses) look like?

Can, and should they be standard URLs, with the scheme defining the protocol?

Jabber uses an email format for Jabber IDs. The resource-id identifies specific objects that are associated with a user, such as devices or locations. 

user@domain.com/resource-id

What kind of "processes" are we talking about as endpoints? Is it about communication between R3 tasks (within a single process), about multiple R3 processes on the same machine, R3 processes across a LAN? WAN? Heterogenous processes?

Messages

What do messages look like? Can it be any simpler than this? 

[opt header  body]

For interop purposes, how do you map from native Rebol format to JSON, XML, or other formats?

Interface/API

What methods do we need? What kind of state management if any? Synchronus versus asynchronous and the ability to wait for a given message. e.g. the tuplespace model where a worker asks for a tuple matching a given pattern and "blocks" until it is notified when a matching tuple arrives.

What kind of messages do we have?

  • request
  • reponse
    • error
Should it work basically like HTTP? RestMS?

Threading

Do we use the same mechanism for inter-thread messaging?

Is this at all possible?

Is this simply mimicked using a common Rebol API running over two different engines?

Advantages:

  • Consistency in API
  • Possible ability to control rebol threads directly using process-level as well as thread-level IPC
Disadvantages:
  • Depending on chosen model and/or target platform, it might be suboptimal performance-wise.
  • Not all IPC models might support this both conceptually and/or programatically.

Implementation

Should this be coded right into the host-kit as a default part of Rebol or as an extension?

If an extension model is used, should it be included by default in the host or loaded at run-time?

Interop

  • What other systems and mechanisms might we want to interoperate with?
  • What is the model for translation to and from other formats?

Other things to consider

  • Discovery
  • Security
  • Presence (and its associated overhead)
  • Persistence
  • Service guarantees
  • Leases
  • Channels
  • Workflow
  • Monitoring
  • DHT
  • Routing

References and other models

Dialect thoughts

  • connect
  • disconnect
  • find/discover
  • join
  • call
  • send
  • receive/recv
  • reply
  • respond
  • tag
  • log
  • answer/hello?
  • hello
  • goodbye
  • ask
  • query
  • lookup
  • start
  • stop
  • restart
  • shutdown
  • quit
  • leave
  • check
  • who's-there?
  • lease
  • expired?
  • still-working?
  • job status
  • service provider
  • monitor
    • service monitor
    • job monitor
  • request producer/job maker
  • job manager/job controller
Clone this wiki locally