-
Notifications
You must be signed in to change notification settings - Fork 2
Wire Protocol
This page describes the Intrepid protocol specification. For source, see MessageEncoder and MessageDecoder.
Intrepid uses big endian byte ordering.
The basic message format is as follows:
--------------
| |
| Length | - 4 bytes
| (type + msg) | (See legacy info for versions < 4)
| |
|--------------|
| Message Type | - 1 byte
|--------------|
| |
~~~ ~~~
| Message | - "Length" - 1 byte
~~~ ~~~
| |
--------------
The length field is a 4-byte integer.
Object encoding (a.k.a. serialization) can be achieved via a number of mechanisms. The default encoder uses the Java Object Serialization Stream Protocol, but custom encoders may also be used.
During session initialization the protocol version is negotiated. In protocol versions prior to 3, the protocol version was only used for determining whether major features (such as "session reconnect tokens" or "invocation acknowledgement") are enabled. The exact message format was still largely controlled by a version field at the front of every message.
In protocol version 3, this (mostly) changed so that the wire format of each message is controlled by the protocol version. The main effect of this change is a more compact wire format.
Negotiation of protocol version causes the highest version which both client and server will accept to be used. In the event there is no overlap in acceptable versions, the session handshake fails and the connection is broken.
The length field occupies either 2 or 4 bytes depending on the size required. If the payload (type + message) is less than or equal to 0x7fff, the length field will be two bytes. When four bytes are used, the high order bit is set.
For example, a message with a payload length of 15 would be encoded as 00 0F. A message
with a payload length of 32855 would be encoded as 80 00 80 57.