Identification And Authentication

IP Addresses and Ports

The participant must establish a TLS-secured TCP/IP connection directly to an EDC gateway. Gateway IP addresses and ports are provided by the exchange via the Network Access Guide (EDCI Manual §3.4, §4.2). There is no prior gateway discovery step — EDCI uses a direct single-step connection model.

Once connected, the first message sent must be the Session Logon (OnixS::Eurex::DropCopy::TemplateId::LogonRequest) (EDCI Manual §4.3.1).

OnixS::Eurex::DropCopy::Handler::connect can throw exceptions if the TCP connection cannot be established:

• Cannot connect to [Host] on port [Port]. The requested address is not valid in its context.
• Cannot connect to [Host] on port [Port]. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
• Cannot connect to [Host] on port [Port]. No connection could be made because the target machine actively refused it.

In this case you should check:

1. EDC gateway IP/Port is correct?
2. EDC gateway is available?

If both is OK you should contact to OnixS Technical Support or Eurex Customer Technical Support.

Session Authentication

The Session Logon message must be the first message sent by the participant authenticating the Eurex EDCI session.

OnixS::Eurex::DropCopy::Handler::connect can throw exceptions in case of fields of Logon message are incorrect:

Tag	Fieldname	Exception
20055	PartyIDSessionID	Session ID not exist in refdata
554	Password	Session authentication failed

Reconnect Behavior

Automatic Reconnect

When a session is dropped (network failure, heartbeat violation, or exchange restart), the handler fires onError with ErrorCode::General and, if OnixS::Eurex::DropCopy::HandlerSettings::connectionRetries is non-zero, automatically retries the connection. Each retry executes the complete connection sequence:

1. TCP connect
2. TLS handshake
3. Session Logon / LogonResponse
4. SessionListNotification / PartitionListNotification

Steps 1–4 are handled by the SDK. After they complete, the handler transitions to OnixS::Eurex::DropCopy::HandlerState::Connected and the exchange immediately begins the order book synchronization sequence (OnixS::Eurex::DropCopy::TradSesEvent::StartOfOrderBookSynch → restatements → OnixS::Eurex::DropCopy::TradSesEvent::EndOfOrderBookSynch). The application must handle this sequence on every connect, not just the first. See Session Lifecycle for details.

Warning

Set OnixS::Eurex::DropCopy::HandlerSettings::connectionRetries to a sufficiently large value (or -1 for infinite retries) in production to survive transient network interruptions. If the handler exhausts its retry count and reaches OnixS::Eurex::DropCopy::HandlerState::Disconnected, it will not reconnect unless the application calls OnixS::Eurex::DropCopy::Handler::connect again.

There Is No Automatic Failover Between Gateways

OnixS::Eurex::DropCopy::Handler::connect has a two-argument overload that accepts primary and secondary gateway addresses:

handler.connect(primaryHost, primaryPort, secondaryHost, secondaryPort, logon);

This performs initial connection failover only: if the initial TCP connect to the primary gateway fails, the handler attempts the secondary. If the handler subsequently connects successfully to the primary and is later disconnected mid-session, it does not automatically switch to the secondary. Reconnection always targets the same gateway used for the original successful connection.

For active-passive gateway configurations, the application must implement failover explicitly: detect disconnection via onError or the state listener, determine the appropriate gateway, and call OnixS::Eurex::DropCopy::Handler::connect with the chosen address.

State Resynchronization After Reconnect

All local order state must be cleared on every connect and reconnect. The restatement sequence that follows OnixS::Eurex::DropCopy::TradSesEvent::StartOfOrderBookSynch delivers the current state of all open orders. Any state retained from before the disconnect is stale: orders may have been cancelled, filled, or modified by the exchange while the session was down.

The correct pattern is:

// using namespace OnixS::Eurex::DropCopy;
 
void onSessionStatusBroadcast(
    const SessionStatusBroadcast& msg, const MessageInfo&) override
{
    switch (msg.tradSesEvent) {
    case TradSesEvent::StartOfOrderBookSynch:
        orderBook_.clear();
        syncing_ = true;
        break;
    case TradSesEvent::EndOfOrderBookSynch:
        syncing_ = false;
        break;
    case TradSesEvent::OrderBookReset:
        orderBook_.clear();
        syncing_ = true;
        break;
    default:
        break;
    }
}

Retaining stale order state across a reconnect and applying live incremental updates on top of it produces a diverged local book that silently misrepresents the exchange state. There is no mechanism to detect this divergence after the fact.

Note

Even with a successful reconnect, orders that were open when the session dropped may have been cancelled by the exchange. Do not assume that orders present before the disconnect are still active after reconnect — wait for the restatement to confirm their current state.