Authentication and Connection Monitoring Messages


ENCODING_REQUEST [s_EncodingRequest structure] Client >> Server

Requirements: Not required for Servers. Required for Clients if the Client needs to discover the encoding the Server uses.

The ENCODING_REQUEST message is a message requesting to change the DTC encoding for messages.

For the procedure to work with this message, refer to Encoding Request Sequence.

Field Name Field Description
[unsigned int16] Size

The standard message size field. Automatically set by constructor.

[unsigned int16] Type

The standard message type field. Automatically set by constructor.

[int32] ProtocolVersion

The protocol version supported by the Client. Automatically set by constructor.

[EncodingEnum] Encoding

The DTC message encoding the Client is requesting the Server to use.

[char] ProtocolType

The ProtocolType field needs to be set to the text string "DTC".

This field is automatically set with the binary encoding data structures.

This field is used for the Server to know that it is communicating with a DTC compliant Client.

ENCODING_RESPONSE [s_EncodingResponse structure] Server >> Client

Requirements: Required for Servers. Required for Clients if the Client needs to discover the encoding the Server uses.

The ENCODING_RESPONSE is a message from the Server to the Client, telling the Client what message encoding it must use to communicate with the Server.

For the procedure to work with this message, refer to Encoding Request Sequence.

Field Name Field Description
[unsigned int16] Size

The standard message size field. Automatically set by constructor.

[unsigned int16] Type

The standard message type field. Automatically set by constructor.

[int32] ProtocolVersion

This field is automatically set by the constructor.

[EncodingEnum] Encoding

The DTC message encoding to be used.

This value may be different from the requested DTC encoding if the Server does not support the requested encoding from the Client.

[char] ProtocolType

The ProtocolType field needs to be set to the text string "DTC".

This field is automatically set with the binary encoding data structures.

This field is used for the Client to know that it is communicating with a DTC compliant Server.

LOGON_REQUEST [s_LogonRequest structure] Client >> Server

The LOGON_REQUEST message is sent from the Client to the Server requesting to logon to the Server.

This is the very first message the Client sends to the Server before being allowed to send any other message other than the ENCODING_REQUEST.

Field Name Field Description
[unsigned int16] Size

The standard message size field. Automatically set by constructor.

[unsigned int16] Type

The standard message type field. Automatically set by constructor.

[int32] ProtocolVersion

The protocol version supported by the Client. Automatically set by constructor.

[char] Username

Optional username for the server to authenticate the Client.

[char] Password

Optional password for the server to authenticate the Client.

[char] GeneralTextData

Optional general-purpose text string. For example, this could be used to pass a license key that the Server may require.

[int32] Integer_1

Optional. General-purpose integer.

[int32] Integer_2

Optional. General-purpose integer.

[int32] HeartbeatIntervalInSeconds

The interval in seconds that each side, the Client and the Server, needs to use to send HEARTBEAT messages to the other side.

This should be a value from anywhere from 5 to 60 seconds.

This field is required.

[TradeModeEnum] TradeMode

This is an optional field. This can be set to indicate to the Server that the requested trading mode to be one of the following: Demo, Simulated, Live.

It is optional for the Server to implement the use of this field.

Demo is simulated trading for demonstration purposes which may involve fictitious prices in the market. Simulated is standard simulated trading involving actual prices in the market. Live is actual live trading involving real money.

[char] TradeAccount

This should only be set to a trade account identifier if that is required to login. Usually this would be the case if the log in is bound to a particular account and not changeable after the log in. Otherwise, this should be empty and Client will discover the accounts through an Account List Request.

[char] HardwareIdentifier

Optional: This is the computer hardware identifier. The intention of this is that this will be implemented by the Client program developer on a case-by-case basis for specific Data/Trading service providers. It will be a reasonable implementation to uniquely identify a system and will not be publicly disclosed. It will never contain personally identifiable information.

[char] ClientName

The Client name. This is a free-form text string.

LOGON_RESPONSE [s_LogonResponse structure] Server >> Client

This is a response message indicating either success or an error logging on to the Server.

Field Name Field Description
[unsigned int16] Size

The standard message size field. Automatically set by constructor.

[unsigned int16] Type

The standard message type field. Automatically set by constructor.

[int32] ProtocolVersion

This is automatically set by the constructor.

[LogonStatusEnum] Result

This can be set to one of the following constants:

  • LOGON_SUCCESS
  • LOGON_ERROR
  • LOGON_ERROR_NO_RECONNECT
  • LOGON_RECONNECT_NEW_ADDRESS

LOGON_ERROR_NO_RECONNECT means that there has been an error logging on and the Client should not try to reconnect.

The Server can set this field to LOGON_RECONNECT_NEW_ADDRESS to instruct the Client to reconnect to the Server at a different address. The new address is specified through the ReconnectAddress field. This supports dynamic connections to a server farm.

[char] ResultText

Optional freeform text to provide information related to a successful or unsuccessful logon. The Client will display this text to the user.

[char] ReconnectAddress

Server address/IP number and optional port number to reconnect to. Format: [Server Address:Port Number]. Only used if Result is set to LOGON_RECONNECT_NEW_ADDRESS.

[int32] Integer_1

Optional. General-purpose integer for the Server to communicate to the Client an integer value on logon.

[char] ServerName

Optional free-form text for the Server to fill out.

It is recommended that the Server fill this in with descriptive text identifying itself to the Client.

The length of this text string is 60 characters when fixed length strings are used.

[unsigned int8] MarketDepthUpdatesBestBidAndAsk

Set this to 1 to indicate that the Server will only be sending market depth updates and not best bid and ask updates. The Client will use depth at level 1 to update the best bid and ask prices.

Some Clients will maintain separate best bid and ask prices from market depth data.

[unsigned int8] TradingIsSupported

Set this to 1 to indicate the Server supports trading. Otherwise, the Client will not send through any trading messages.

[unsigned int8] OCOOrdersSupported

Set this to 1 to indicate the Server supports OCO orders.

[unsigned int8] OrderCancelReplaceSupported

Set this to 0 if Server does not support the CANCEL_REPLACE_ORDER message.

[char] SymbolExchangeDelimiter

Some Clients will usually consider the Symbol and Exchange fields as a single text string. If the Server will be using the Exchange field in DTC messages that have a Symbol and Exchange fields, it must specify the SymbolExchangeDelimiter field to provide a standard delimiter for the Client to use to combine the Symbol and the Exchange into a single text string.

It is recommended to use a "-" or ".". Examples of how the Client will then combine the Symbol and exchange.

  • Symbol-Exchange
  • Symbol.Exchange

If this field is unset, then this is an indication to the Client that the Exchange field in DTC Protocol messages are not used.

Even if the symbols supported by a Server have an Exchange text string, does not mean the Server has to use the Exchange field in DTC messages. The Server can combine the Symbol and the Exchange in Security Definition responses into the Symbol field only.

When a Client sees that the SymbolExchangeDelimiter field is set, then it can use this delimiter to combine the Symbol and Exchange into a single text string. When the Client is setting the Symbol and Exchange in DTC messages, it needs to separate out the Symbol and Exchange from the larger text string and set those fields separately.

[unsigned int8] SecurityDefinitionsSupported

Set to 1 if the Server supports Security Definition messages.

[unsigned int8] HistoricalPriceDataSupported

Set this to 1 if the Server supports the HISTORICAL_PRICE_DATA_REQUEST message.

[unsigned int8] ResubscribeWhenMarketDataFeedAvailable

Set this to 1, so that when the Client receives a MARKET_DATA_FEED_STATUS indicating the market data feed is restored, it will resubscribe to market data and market depth for all of the symbols it was previously tracking.

[unsigned int8] MarketDepthIsSupported

Set this to 1, if the Server supports the MARKET_DEPTH_REQUEST message.

The default is 0.

[unsigned int8] OneHistoricalPriceDataRequestPerConnection

The server can optionally set the OneHistoricalPriceDataRequestPerConnection field to 1 in the LOGON_RESPONSE message to indicate that it only will accept one historical price data request per network connection.

After the first request is served or rejected, the network connection will be gracefully closed at the appropriate time by the Server. This method simplifies the serving of historical price data on the Server side and the implementation on the Client side when data compression is used.

[unsigned int8] BracketOrdersSupported

Set this to 1 to indicate the Server supports bracket orders.

[unsigned int8] UseIntegerPriceOrderMessages

When this is set to 1, it is an indication from the Server to the Client to use the integer order entry messages and integer order modification message. These are SUBMIT_NEW_SINGLE_ORDER_INT, SUBMIT_NEW_OCO_ORDER_INT, and CANCEL_REPLACE_ORDER_INT.

[unsigned int8] UsesMultiplePositionsPerSymbolAndTradeAccount

If the Server can report more than one Trade Position for a specific Symbol and Trade Account, then it needs to set UsesMultiplePositionsPerSymbolAndTradeAccount to 1.

When the server has set to 1, it must always set PositionIdentifier in the POSITION_UPDATE message to the identifier of the Trade Position.

When the Client checks that this is set to 1, then it knows that it can expect there potentially can be more than one Trade Position for a specific Symbol and Trade Account being reported by the POSITION_UPDATE messages. The Client can then handle this appropriately.

[unsigned int8] MarketDataSupported

Set this to 1, if the Server supports the MARKET_DATA_REQUEST message.

The default is 1.

LOGOFF [s_Logoff structure] Server >> Client and Client >> Server

A LOGOFF is a message which can be sent either by the Client or the Server to the other side. It indicates that the Client or the Server is logging off and going to be closing the connection.

When one side receives this message, it should expect the connection will be closed. It should not be expected that any messages will follow the LOGOFF message, and it should close the network connection and consider it finished. The side receiving this message can send a LOGOFF message to the other side before closing the connection.

Field Name Field Description
[unsigned int16] Size

The standard message size field. Automatically set by constructor.

[unsigned int16] Type

The standard message type field. Automatically set by constructor.

[char] Reason

Reason is a character string indicating the reason for the log off from either the Client or the Server.

[unsigned int8] DoNotReconnect

When DoNotReconnect is set to a 1, this indicates to the other side that a reconnect to the opposite side should not occur automatically.

HEARTBEAT [s_Heartbeat structure] Server >> Client and Client >> Server

Both the Client and the Server need to send to the other side a heartbeat at the interval specified by the HeartbeatIntervalInSeconds member in the LOGON_REQUEST.

There are no required member fields to set in this message. The purpose of the HEARTBEAT message is so that the Client or the Server can determine whether the other side is still connected.

It is recommended that if there is a loss of HEARTBEAT messages from the other side, for twice the amount of the HeartbeatIntervalInSeconds time that it is safe to assume that the other side is no longer present and the network socket should be then gracefully closed.

The Server may choose to send a heartbeat message every second to the Client. In this particular case, it is recommended the Client use a minimum time of about 5 to 10 seconds without a heartbeat to determine the loss of the connection rather than the standard of twice the amount of the heartbeat time interval.

Field Name Field Description
[unsigned int16] Size

The standard message size field. Automatically set by constructor.

[unsigned int16] Type

The standard message type field. Automatically set by constructor.

[unsigned int32] NumDroppedMessages (Optional)

The server can optionally set this to indicate the number of messages that were not sent through to the Client because of a buffer overflow on the server side because the Client was not processing the data fast enough or some other network issue.

The Server should only drop high-frequency market data messages. In no case should a server ever drop trading related messages.

[t_DateTime] CurrentDateTime (Optional)

This Date-Time value can be optionally set by the Client/Server when sending this message.


*Last modified Friday, 12th August, 2016.