The Communication Flow

(In progress)

This page serves to document the standardized flow of communication between subsystems and the core server, and is a good starting point for anyone looking to develop a subsystem.

Note: Throughout this page, 'client' is used as a substitute for 'subsystem', and 'core server' is shortened to 'server'.

The protocols on this page will be drastically changed when remote subsystems and encryption are implemented.

Registration

The first step in the communication flow is registration: clients must identify themselves, and in return (if authorized), will be given a permanent communication channel and computational resources server-side.

After the server completes startup, a win32 pipe is opened under the name FMBCRegister; this can be connected to locally or remotely (future release). To register themselves with the server, clients should connect to the pipe using CallNamedPipeA from the win32 api and follow the protocol described below. If the pipe is not available, clients should wait until it is.

The registration handshake is as follows:

• Request
  Once successfully connected to the pipe, the client should send a message consisting of a single byte specifying the request, directly followed with the process id of the client, and any data the request type requires. Possible request types are shown below:

  Type	Definition	Data
  REGISTER_NEW 0x01	Register a subsystem that has not already been registered this session	N/A
  REGISTER_RECONNECT 0x02	Register a subsystem that has already been registered this session. This should only be used if the client crashed, and is attempting to reconnect after restarting.	The session id assigned to the subsystem during it's previous connection.

  If the request type is invalid, or any provided data does not match the expected format, the client is disconnected from the pipe and a message is logged to the server console.

• Response
  The client will then receive a response, consisting of a one byte boolean specifying whether or not the request was accepted, and if true, a new 128 bit session id to be used in future authentication, and a handle to a memory-mapped file used for communication. If the request is refused, a message is logged the server console.
  
  In either case, the client is then disconnected from the pipe.

Data Flow

Communication then follows the rules of whatever features the subsystem supports (only one right now). The first byte is used to coordinate communication: a value of 0 means the client is preparing data, 1 means the client is waiting for that data to be processed by the server.