Protocol

The exact choice of messaging and internal data structures should be carefully considered as the time taken to read and write data into and out of the Aeron buffers directly impacts Aeron Cluster throughput and latency.

Static Data Protocol¶

Instruments

Instruments will hold a minimal set of data - an instrument ID, the minimum quantity and a flag indicating if active or not.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

<sbe:message name="AddInstrument" id="101" description="Record for Instruments held in a repository">
    <field name="correlation" id="1" type="uuidString"/>
    <field name="cusip" id="2" type="cusip"/>
    <field name="enabled" id="3" type="BooleanType"/>
    <field name="minSize" id="4" type="int32"/>
</sbe:message>

<sbe:message name="SetInstrumentEnabledFlag" id="102" description="Set instrument enabled field">
    <field name="correlation" id="1" type="uuidString"/>
    <field name="cusip" id="2" type="cusip"/>
    <field name="enabled" id="3" type="BooleanType"/>
</sbe:message>

Commands relating to Instrument:

• AddInstrument - used to add a new Instrument to the state machine. Note that it includes very limited data - not even a name or otherwise. This is because this is all the state machine needs. Gateways around the edges can translate the instrument ID into something appropriate for external consumption.
• SetInstrumentEnabledFlag - used to enable or disable the instrument. All RFQs in progress with this instrument would be canceled, and new RFQs for this instrument would fail validation. Two parameters are required: cusip & enabled.

RFQ Interaction Protocol¶

Since there are good number of possible interactions, only a few samples are included to illustrate the design.

CreateRfqCommand

This is sent by a User to initiate a new RFQ.

<sbe:message name="CreateRfqCommand" id="106" description="Command to create a RFQ">
    <field name="correlation" id="1" type="uuidString"/>
    <field name="expireTimeMs" id="2" type="int64"/>
    <field name="quantity" id="3" type="int64"/>
    <field name="requesterSide" id="4" type="Side"/>
    <field name="cusip" id="5" type="cusip"/>
    <field name="requesterUserId" id="6" type="int32"/>
</sbe:message>

You'll notice that the command include data on the user performing the request. The cluster will validate these user ID's against those within the Users object.

CreateRfqConfirmEvent

This is the reply sent by the state machine to the cluster client session that sent the CreateRfqCommand. Note that the response to the RFQ Creation is encoded as a SBE enum.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

<enum name="CreateRfqResult" encodingType="int32">
    <validValue name="SUCCESS">0</validValue>
    <validValue name="UNKNOWN_USER">1</validValue>
    <validValue name="UNKNOWN_CUSIP">2</validValue>
    <validValue name="INSTRUMENT_MIN_SIZE_NOT_MET">3</validValue>
    <validValue name="INSTRUMENT_NOT_ENABLED">4</validValue>
    <validValue name="RFQ_EXPIRES_IN_PAST">5</validValue>
</enum>

<sbe:message name="CreateRfqConfirmEvent" id="122">
    <field name="correlation" id="1" type="uuidString"/>
    <field name="rfqId" id="2" type="int32"/>
    <field name="result" id="3" type="CreateRfqResult"/>
</sbe:message>

RfqCreatedEvent

This is broadcast by the state machine to all connected clients following the creation of a new RFQ.

1
2
3
4
5
6
7

<sbe:message name="RfqCreatedEvent" id="112">
    <field name="cusip" id="1" type="cusip"/>
    <field name="expireTimeMs" id="2" type="int64"/>
    <field name="quantity" id="3" type="int64"/>
    <field name="requesterSide" id="4" type="Side"/>
    <field name="rfqId" id="5" type="int32"/>
</sbe:message>