Understanding Handler States

Handler's States

Please find all the available states of the Handler in the table below.

State	Description
OnixS::Eurex::DropCopy::HandlerState::Disconnected	The Handler is disconnected.
OnixS::Eurex::DropCopy::HandlerState::Disconnecting	The intermediate state when the Handler is not disconnected but not connected.
OnixS::Eurex::DropCopy::HandlerState::Connected	Handler is connected.
OnixS::Eurex::DropCopy::HandlerState::Connecting	The intermediate state when the Handler is not connected but not disconnected.

Tracking Handler's State

To track the Handler's state you need to implement OnixS::Eurex::DropCopy::HandlerStateListener class interface and register an instance with the Handler using OnixS::Eurex::DropCopy::Handler::registerHandlerStateListener member.

Handler's States Transitions

Handler's States Transition Diagram

Let's take a closer look what triggers transitions between the Handler's states.

Disconnected -> Connecting

• When OnixS::Eurex::DropCopy::Handler::connect is called.
• When the Handler is restarting.

Connecting -> Connected

• When the connection to Eurex is established and Logon Request is accepted.

Connecting -> Disconnected

• When the connection to Eurex can't be established.
• When the connection to Eurex is established but Logon request is rejected.

Connected -> Disconnecting

• When OnixS::Eurex::DropCopy::Handler::disconnect or OnixS::Eurex::DropCopy::Handler::disconnectAsync is called.
• When the connection is dropped and no reconnect attempts left.

Disconnecting -> Disconnected

• When the connection is closed and the Handler is stopped all the activity.

Connecting the Handler

If the Handler is in the Disconnected state and user code calls OnixS::Eurex::DropCopy::Handler::connect, user code will receive a callback with new state set to OnixS::Eurex::DropCopy::HandlerState::Connecting.

If the Handler is in any other state except Disconnected and user code calls OnixS::Eurex::DropCopy::Handler::connect, the Handler will first disconnects and only after successful disconnect user code will receive a callback with new state set to OnixS::Eurex::DropCopy::HandlerState::Connecting.

Disconnecting the Handler

If the Handler is in the Disconnected state and user code calls OnixS::Eurex::DropCopy::Handler::disconnect or OnixS::Eurex::DropCopy::Handler::disconnectAsync, user code will not receive any callback.

If the Handler is in any other state except Disconnected and user code calls OnixS::Eurex::DropCopy::Handler::disconnect or OnixS::Eurex::DropCopy::Handler::disconnectAsync, user code will receive a callback with new state set to OnixS::Eurex::DropCopy::HandlerState::Disconnecting.

disconnect blocks until the handler reaches OnixS::Eurex::DropCopy::HandlerState::Disconnected. disconnectAsync initiates the same session logout and disconnect sequence but returns without waiting for Disconnected.

Session Lifecycle

When OnixS::Eurex::DropCopy::Handler::connect is called, the handler executes the full EDCI connection sequence before transitioning to OnixS::Eurex::DropCopy::HandlerState::Connected. The steps are:

1. TCP connect and TLS handshake — the handler opens a TLS-secured TCP connection to the EDC gateway (EDCI Manual §4.2).
2. Session Logon (OnixS::Eurex::DropCopy::TemplateId::LogonRequest) — the handler authenticates the session using the OnixS::Eurex::DropCopy::Logon instance passed to OnixS::Eurex::DropCopy::Handler::connect (EDCI Manual §4.3.1).
3. Session Logon Response (OnixS::Eurex::DropCopy::TemplateId::LogonResponse) — the exchange confirms or rejects the session. Rejection causes the handler to transition to OnixS::Eurex::DropCopy::HandlerState::Disconnected (EDCI Manual §4.3.1).
4. Session List Notification (OnixS::Eurex::DropCopy::TemplateId::SessionListNotification) — the exchange delivers the list of trading sessions contributing to the EDC data stream. Fired as OnixS::Eurex::DropCopy::SessionListener::onSessionListNotification (EDCI Manual §4.3.5).
5. Partition List Notification (OnixS::Eurex::DropCopy::TemplateId::PartitionListNotification) — the exchange delivers the list of market partitions. Fired as OnixS::Eurex::DropCopy::SessionListener::onPartitionListNotification (EDCI Manual §4.3.6).

At this point OnixS::Eurex::DropCopy::Handler::connect returns and the handler transitions to OnixS::Eurex::DropCopy::HandlerState::Connected.

However, the EDCI data stream is not yet ready for consumption. The exchange immediately begins the order book synchronization phase per partition (EDCI Manual §4.4):

1. Trading Session Event: Start of Order Book Synchronization (OnixS::Eurex::DropCopy::TradSesEvent::StartOfOrderBookSynch) — signals that the exchange is about to replay the current state of all open orders for this partition. Delivered via OnixS::Eurex::DropCopy::OrderHandlingListener::onSessionStatusBroadcast. The application must clear all local order state on receipt.
2. Extended Order Information restatements — a series of OnixS::Eurex::DropCopy::OrderExecReportBroadcast messages with OnixS::Eurex::DropCopy::ExecType::Restated is sent, one per open order. If there are no open orders, no restatement messages are sent.
3. Trading Session Event: End of Order Book Synchronization (OnixS::Eurex::DropCopy::TradSesEvent::EndOfOrderBookSynch) — signals that the restatement stream is complete. Only after receiving this event should the application treat local order state as consistent and begin processing live updates.

After OnixS::Eurex::DropCopy::TradSesEvent::EndOfOrderBookSynch the stream transitions to live mode: all subsequent OnixS::Eurex::DropCopy::OrderExecReportBroadcast and OnixS::Eurex::DropCopy::DeleteOrderBroadcast messages reflect real-time order events.

Warning

OnixS::Eurex::DropCopy::HandlerState::Connected does not mean the data stream is ready. The stream is initialized only after OnixS::Eurex::DropCopy::OrderHandlingListener::onSessionStatusBroadcast delivers OnixS::Eurex::DropCopy::TradSesEvent::EndOfOrderBookSynch. Treating messages that arrive before this event as live updates will produce an order book inconsistent with exchange state.

Initial Synchronization vs Live Updates

EDCI delivers order state in two distinct phases after each session logon (EDCI Manual §4.4).

Restatement Phase (Initial Snapshot)

Between OnixS::Eurex::DropCopy::TradSesEvent::StartOfOrderBookSynch and OnixS::Eurex::DropCopy::TradSesEvent::EndOfOrderBookSynch, the exchange replays the current state of all open orders as OnixS::Eurex::DropCopy::OrderExecReportBroadcast messages with OnixS::Eurex::DropCopy::ExecType::Restated. Each message represents the complete current state of one order — not a delta. Apply as an insert or full-replace of the local order record.

Rules during the restatement phase:

• Do not apply restatement messages as incremental updates.
• Do not emit live order events to downstream consumers until OnixS::Eurex::DropCopy::TradSesEvent::EndOfOrderBookSynch is received.

Live Update Phase

After OnixS::Eurex::DropCopy::TradSesEvent::EndOfOrderBookSynch, all messages are incremental. Each OnixS::Eurex::DropCopy::OrderExecReportBroadcast or OnixS::Eurex::DropCopy::DeleteOrderBroadcast reflects a single order event. Apply them in arrival order to maintain consistent local state.

Why the Distinction Matters

OnixS::Eurex::DropCopy::ExecType::Restated can appear in both phases with different semantics:

• During initial sync: delivers the full current state of an order as a snapshot.
• During live mode: re-delivers the full order state following a system event (Derivatives Message Reference §6.2). Apply as a full-replace, same as during sync.

Track synchronization state with a flag set on OnixS::Eurex::DropCopy::TradSesEvent::EndOfOrderBookSynch and cleared on OnixS::Eurex::DropCopy::TradSesEvent::StartOfOrderBookSynch or OnixS::Eurex::DropCopy::TradSesEvent::OrderBookReset:

// using namespace OnixS::Eurex::DropCopy;
 
bool synced_ = false;
 
void onSessionStatusBroadcast(
    const SessionStatusBroadcast& msg, const MessageInfo&) override
{
    switch (msg.tradSesEvent) {
    case TradSesEvent::StartOfOrderBookSynch:
        orderBook_.clear();
        synced_ = false;
        break;
    case TradSesEvent::EndOfOrderBookSynch:
        synced_ = true;
        break;
    case TradSesEvent::OrderBookReset:
        orderBook_.clear();
        synced_ = false;
        break;
    default:
        break;
    }
}
 
void onOrderExecReportBroadcast(
    const OrderExecReportBroadcast& msg, const MessageInfo&) override
{
    orderBook_.upsert(msg);          // always update state
    if (synced_) {
        downstream_.publish(msg);    // only emit live events after sync
    }
}