Sydi follows the design philosophy of 'everything is a message-passing node'. There are two central parts to Sydi:

Some terminology used:

Message-passing in Sydi

There are two types of message passing channels in Sydi: (each is implemented via a different protocol)

A 'centralized' system (actually local to each node) manages the message-passing channels. If a module wants to communicate with another module, it requests that the local channel manager create a new channel -- which is assigned a globally-unique identifier; the second module then connects to said channel and can begin passing messages back and forth as necessary.

This, of course, is not very feasible as it stands: there needs to be some common knowledge (i.e. the channel ID) before communication can begin. To that end, particular channels can be made non-anonymous by binding them to a name. Then, a module can ask to open a bound channel by name for reading/writing.

General memory-based MP architecture

Several contiguous pages are shared in memory between the various modules. Each channel has a designated region for a control header, and the rest is reserved for messages. No checks are placed upon what is read/written to/from the channel, and as a result, any of the connected modules are capable of putting the channel into an invalid state.

To alleviate the difficulties of dealing with such things, a userspace API will be provided to manipulate the contents of the channels properly, and also to read with complete error-checking. Conforming programs will use the API to write, and hence not cause any problems; conforming programs will use the API to read as well, so if a non-conforming program tweaks the contents of a channel accidentally, the conforming programs (with the error-checking API) will not cause any undue failures.

The API functions will return a special ERRNO-style value when the channel has been compromised.

Queue

The header contains the following elements:

Each message has the following header:

To send a message, the following operations take place:

To receive a message, the following operations take place:

Broadcast

The channel header contains the following elements:

Each message has the following header:

General network-based MP architecture

There are, as before, two separate

Distributed topography

The fact that Sydi operates in a distributed fashion is one of the trickier things to deal with. When a new Sydi node is started, it needs the IP addresses of already-started node(s). If none respond to requests, then it begins a new Sydi cluster. There are no plans to allow clusters to merge.

Nodes within a Sydi cluster follow a traditional distributed network model: each node is connected to a number of other nodes, but perhaps not all. Nodes are required to forward communications between their neighbours if their neighbours do not 'know about' each other, i.e. have no direct connection.

There are some operations that require a global lock to be held, such as:

These are accomplished via a broadcast mechanism typical of distributed systems.

Control messages

Nodes in a cluster maintain TCP connections with each other to send control messages to each other. A short list of such message types:

Request types

Notification types

Module migration

If a node is deemed overloaded, and a module is estimated to be 'good' to move, then the contents of the address space of the module are transferred to another node, and network relays are added to allow the channels to continue uninterrupted.

The weighting formula includes:

Eventually the address space information will be compressed using gzip or something similar to save bandwidth, but not immediately (for simplicity).

Node-to-node communication encryption

Certain tasks, such as module migration, may involve sensitive information being transmitted between nodes. To that end, Sydi will provide the option to have all node-to-node communication encrypted via a simple Diffie-Hellman handshake/AES running in CBC. Such a model is vulnerable to man-in-the-middle attacks, but will defeat passive monitoring.