MCCI Wire Protocol

Part of MCCI.

Motivation

Specifying the MCCI system as a wire protocol removes platform-specific and language-specific dependencies from the codebase. The goal of this system is to be interoperable with as wide of a platform base as possible.

The communications strategy should also be simple and efficient in terms of processing, favoring O(1) packing and unpacking of the basic data structures. (IK: I'm not sure whether the ability to pack everything as a set of fixed-length fields followed by one variable-length field for accessing via a struct is better than just putting it in a protobuf and relying on the speed of their implementation). (TES: I think we should not require Protobuf to encode/decode the basic wire messages.)

Normal Operation

After the system is configured, launched, and running, there are several desired modes to be supported. The currency of this system is named data (data packets), originating on a specific server node and having a specific variable name (a.k.a. "queue name", as it is called in PubSub). The server assigns revision numbers to each named piece of data, starting from 1 and guaranteed to be increasing contiguously.

A data packet is organized as follows:

Node Address	unsigned integer
Variable ID	unsigned integer
Revision	unsigned integer
Payload	byte array

• The Node Address is similar to an IP address. It uniquely identifies the MCCI server -- each MCCI server in the system of autonomous vehicles must have a distinct address. The value of 0 is a special case, indicating the "localhost" MCCI server.
• The Variable ID represents the name of the data (a string) according to its entry in the Distribution Schema.
• The Payload is the value of the data. Note that "who published the data" and "when the data was published" are not part of this structure; if they are desired, they must be included as part of the payload and are invisible to MCCI.

Publishing New Data

Data produced by a client is sent to its server as a production packet.

Variable ID	unsigned integer
Response ID	unsigned integer
Payload	byte array

• The Response ID will be used by the server in response to this request; it can be any value the client wants, however a value of 0 indicates that the client does not want a response sent.

The server responds with an acceptance packet.

Response ID	unsigned integer
Revision	unsigned integer

• The Response ID is copied from the production packet, and the server provides the revision of the data packet that resulted from the client's original production packet.

Requesting Existing Data

All requests for data are sent to a client's own server.

Timeout	unsigned integer
Node Address	unsigned integer
Variable ID	unsigned integer
Revision	unsigned integer
Quantity	unsigned integer
Direction	bit

• The Timeout is a timestamp in milliseconds (IK: Can't use timeout duration, otherwise forwarding the request would result in never-ending timeouts) specifying the deadline that the server should honor for the request to be fulfilled. (See: MCCI Server Operation).
• The Node Address specifies the origin of the desired data. (If either are 0, it means "localhost". If -1, it means "any host". These requests will not be forwarded under any circumstances.)
• The Variable ID specifies the name of the desired data. (If 0, it means wildcard. These requests will not be forwarded under any circumstances.)
• The Revision specifies the desired revision, with 0 being a special case that means "the latest".
• The Quantity specifies how many packets following the Revision should be returned. (If Revision is 0, this will be the number of packets preceding the most recent revision.) (IK: Quantity=0 is undefined, not sure what to do with it.)
• The Direction specifies whether the Data Packets should be returned in chronological (revision) or reverse-chronological order. This might be implemented as the sign bit on Quantity.

Initial Operation

Server Bootup

The server's configuration contains:

• The server's Node Address
• Other items TBD

Client Connection

TBD: the handshaking that happens between client and server to establish how many bytes might be used in each Variable ID and Node Address. The server and client should also verify that they are using the same (SHA1-same) Distribution Schema. Alternatively, the schema could be read by the server only, and the client could query the server for the relevant mappings. This alternate approach might be problematic because it would require the client to abort at runtime (rather than at startup) if any variable names are not available.

See Also

• MCCIProtocolTestCases