|
| void | note (const OrderCommand &c, std::int64_t now_ns) noexcept |
| |
| void | answered (ClientOrderId id) noexcept |
| | The venue said something about order id.
|
| |
| void | answered (const EventHeader &h) noexcept |
| | answered() for the order an event from the venue is about.
|
| |
| void | sent_over_rest (ClientOrderId id) noexcept |
| | Order id (noted last, or nearly) went out over REST rather than on the WebSocket order connection: losing that connection does not settle it.
|
| |
| void | connection_lost () noexcept |
| | The WebSocket order connection is gone: the requests sent on it will not be answered on it.
|
| |
| ClientOrderId | value (std::int64_t now_ns) noexcept |
| | The watermark for a snapshot requested now.
|
| |
| Mark | mark (std::int64_t now_ns) noexcept |
| |
| ClientOrderId | last_sent () const noexcept |
| | The last id sent, answered or not, and its send sequence (the order being sent, inside the connector's send path).
|
| |
| std::uint64_t | last_seq () const noexcept |
| |
The watermark stamped into an open-order snapshot's ReconcileMsg Begin: the engine's orders at or below it can be judged by the snapshot, the ones above it cannot.
It is the last client order id (New or Replace) the venue sent before the first one the venue has not answered yet (ack, reject, fill or cancel), in send order: an order still in flight when the snapshot is asked for may reach the matching engine, or the venue's open-order view, after the snapshot is taken (Binance Spot, 2026-09-26: an order sent 1 ms before openOrders.status and accepted by the matching engine was missing from the reply, and the engine cancelled it as gone). An order with no answer after kUnansweredNs no longer holds the watermark back, and neither does one sent on a WebSocket connection that is gone (it will not be answered on it); one sent over REST does, as its reply still comes.
One engine allocates its ids in the order it sends them; fastmm-gateway interleaves several engines' ids on one venue and finds the point the snapshot was taken at from the id itself (live/gateway.hpp), which is why the watermark is always an id that was sent.
The connector itself compares by send sequence: every New and Replace noted takes the next number (last_seq()), in send order over every engine behind the connector, and the watermark's sequence (Mark::seq) is that of the id it names. An order shadow stamped with its sequence is judged by the snapshot when its sequence is at or below the mark's, whichever engine sent it.