Characteristices common to IM2000 protocols

The various IM2000 protocols have a common structure and common transport layer requirements.

Structure of IM2000 protocols

The IM2000 protocols are client-driven, authenticated, protocols that permit multiple non-overlapping transactions within a single session. The identity of the client and the server vary according to the protocol. Transactions are non-overlapping in that only one transaction may be outstanding in a session at any given time.

Overview of the operation of the protocols

The protocols operate as follows:

Transactions as sequences of commands and responses

Transactions comprise a sequence of one or more non-overlapping command and response pairs.

A transaction comprises either

Each command and response is a single Protocol Data Unit, transmitted via the transport layer.

All response PDUs comprise some common elements:

Clients must only use the transaction abort flag in a response PDU to determine whether a transaction is being aborted. They must not use the status code to determine this. An error response may, depending from the type of transaction, be permitted to occur within a transaction that comprises a sequence of multiple commands and responses, without aborting the transaction.

Transport layer requirements of IM2000 protocols

IM2000 protocols require a transport layer that is capable of reliable, sequenced, bidirectional, half-duplex, transmission of PDUs. The protocols can be layered over either stream-based or message-based protocols.

The protocols can thus be transported via TCP (for general Internet use), or via an operating system's local stream-based or message-based interprocess communication facility (such as, for example, named pipes).

For stream-based transport protocols, each PDU is transmitted across the transport layer as a stream of octets preceded by a 4-octet word (in "big-endian" network order) denoting the length (not including that word itself) in octets of the PDU.

For message-based transport protocols, the length of each PDU is encapsulated in the message itself, and is not otherwise explicitly transmitted.

Clients, servers, and transport protocols must support PDUs up to 64KiB long, and must be capable of skipping PDUs that are too long for them to handle without affecting either the status of the session or the correct handling of further PDUs.

Transport protocols that fragment PDUs must do so transparently. As far as clients and servers are concerned, PDUs are transported en bloc.

Sessions begin with a command PDU sent from the client to the server. This permits transport protocols such as TCP to perform the optimization of sending the completion of the connection handshake and the command PDU together in a single network layer datagram.

Transport layer security in IM2000 protocols

Transport layer security for the IM2000 protocols is provided by encrypting the octet streams in both directions. As far as the protocols are concerned, this is done entirely transparently. The protocols have no "home grown" encryption mechanisms.

When the transport layer is TCP (for general Internet use), an IM2000 service has three transport-level security options:

© Copyright 2004-2004 Jonathan de Boyne Pollard. All rights reserved. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp information is preserved.