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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.