Protocol Expected Behavior¶
The exchange expects a certain behavior from clients. All communication is asynchronous and requires clients to implement basic message state tracking.
ACK messages are always the first response to any message submitted to the
ACK messages will contain a generated Message ID
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
ACK message(s). these message can be processed via your
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
of the batch message sent. A Batch message should be received after the
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
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.