Protocol Expected Behavior

The exchange expects a certain behavior from clients. All communication is asynchronous and requires clients to implement basic message state tracking.

Acknowledge ACK messages are always the first response to any message submitted to the exchange. ACK messages will contain a generated Message ID MID which will be used to track the state of each message through its life cycle but also acts as an entry ID if the submitted message is an order type. After a message is submitted the context blocks for a certain period/timeout for expected ACK message(s). these message can be processed via your processor.

Exchange Unavailability Scenarios

  • Client sends a message and doesn’t receive an ACK (S1)
  • Client sends a message and receives an ACK but not a response (S2)
  • Client sends a message and receives both an ACK and a response (S3)

Scenario 1

In this scenario it is the client’s responsibility to resend a message until it receives an ACK.

Scenario 2

In this scenario it is the client’s responsibility to maintain a queue of messages that received an ACK.

Once the exchange is back online a client could query the exchange for a set of messages they might have missed through MessageReplay.

Scenario 3

Once a response is received that contains the same MID for that particular message, the client is now free to discard the 3 messages (i.e., the message sent, the ACK received, and the final response).

Trade requests (e.g., limit order, quotes) are an exception in this scenario as the response to these requests is an unpredictable number of action reports as long as the client is connected to the exchange. Therefore the client must not discard the trade request’s MID until the last action report received reports a size of zero. If the connection is severed before the action report’s size reaches zero the client must query the exchange for outstanding trade notifications through MessageReplay to synchronize their internal CLOB with the exchange’s.

Batch Messages

Batch messages provides the ability to send up to 200 messages in a single call. These messages are executed in the order provided by the client. Unlike stream messages, Batch operations have different behaviour.

Once a batch message is sent to the exchange, an ACK is received holding the MID of the batch message sent. A Batch message should be received after the ACK that contains a list of ACK for each message contained within the client Batch message. At this point, it’s the client’s responsility to maintain these ACK replies. Shortly, responses for messages sent within the client’s Batch message follow each with the MID of its corresponding client’s message.

Exchange Run IDs and Run Change

All messages received contain a run_id field that contains an identifier of the current exchange run. In case the exchange is restarted, a different id is generated and set to all messages run_id field. At this point all open orders that existed before exchange restart are canceled. So, you should make sure you know which orders during the old run.

run_id is likely to first change on either ACK messages or heartbeats. In case an ACK is received with the newer run_id it means the message sent executed within the new run.