cTrader FIX API【コミュニケーション・モデル】

概要
FIXセッションプロトコル
cTrader FIXプロトコルメッセージのカテゴリー
1. システム（アドミン）メッセージ
2. アプリケーションメッセージ
FIXメッセージの構造
FIXメッセージのフォーマット
1. タグ{tag}
2. バリュー{value}
メッセージの例

概要

FIX API は、セッションベースの通信を使用します。

セッションとは、通信を開始する当事者である Initiator（クライアント）と、 Initiator からの接続要求を受け取る当事者である Acceptor（Server）の二者間の通信と定義されます。

サーバーはログオンメッセージを使用して、クライアントリクエストを検証します。

FIXセッションプロトコル

各セッションは、クライアントと cTrader エンティティ間の双方向メッセージを維持します。セッションは複数の物理的接続を含むことができます。セッションは、シーケンス番号を使用して維持されます。

1つのセッション内のすべての新しいメッセージは、1(1)から始まる一意のシーケンス番号を受け取ります。両当事者は、秩序ある通信を維持するためにシーケンス番号に依存します。欠落したメッセージは、両者間の合意によって再送される。

典型的なセッションの流れ

クライアントがLOGONメッセージでセッションを開始
サーバーとアプリケーション・メッセージを交換
LOGOUTメッセージで終了

cTrader FIXプロトコルメッセージのカテゴリー

FIXプロトコルで定義されているように、cTrader FIXサーバーは、システムとアプリケーションの2つの異なるデータレベルを使用しています。

これは、必要なワークフローをサポートするために必要なメッセージの最小セットです。ビジネスニーズとFIX標準などが変遷するにつれて変更される可能性があります。

システム（アドミン）メッセージ

ハートビート (クライアント↔cTrader) – 2者間の通信リンクをチェックするために使用されます。
テスト要求 (クライアント ↔ cTrader) – 通信リンクの健全性をテストするために使用されます。
ログオン (クライアント → cTrader) – クライアント認証メッセージです。
ログアウト (クライアント → cTrader) – 通常のセッション終了を意味します。
再送要求 (クライアント ↔ cTrader) – 特定のアプリケーションメッセージの再送要求です。
拒否 (クライアント↔cTrader) – セッションレベルの検証失敗を意味します。
シーケンスリセット(クライアント↔cTrader) – 通信問題が発生した場合、メッセージの欠落を回復するか、欠落したメッセージを無視するようにシーケンスをリセットします。

アプリケーションメッセージ

マーケットデータリクエスト (クライアント → cTrader) – マーケットデータの一般的なリクエストです。
Market Data Incremental Refresh (クライアント ← cTrader) – マーケットデータリクエストメッセージへの応答です。
新規注文単一 (クライアント → cTrader) – 執行のためにブローカーに電子的に注文を送信するために使用されます。
約定報告（クライアント←cTrader） – FIXクライアントに注文状況（約定確認、約定、未約定変更など）を送信するために使用されます。
Business Message Reject (クライアント ← cTrader) – セッション以外の理由でFIXクライアントのリクエストを拒否するために使用します。

FIXメッセージの構造

このセクションでは、FIX API メッセージの構成方法について説明します。またこのセクションでは、FIX メッセージの形式について説明し、FIX タグと値のペアの概念を理解するのに役立ちます。

各メッセージには 3 つの部分が必要です：

ヘッダー：各管理またはアプリケーション・メッセージの前には、標準的なヘッダーが付きます。ヘッダは、メッセージ・タイプ、FIX バージョン、メッセージ長、宛先、シーケンス番号、発信元、および時刻を識別します。
ボディ：メッセージ・ボディの内容は、ヘッダで定義されたメッセージ・タイプによって指定されます。
フッター：各メッセージ、管理者、アプリケーションは、標準的なフッターで終了します。フッターはメッセージを分離するために使われ、CheckSum <10>値の3桁の文字表現を含む。

FIXメッセージのフォーマット

FIXメッセージはフィールドの集まりです。

各フィールドはタグと値のペアで、次のようにフォーマットされます：

{tag}={Value}となります。例えば、54=2 は注文タイプ = 売りを意味します。

タグ{tag}

FIXは定義済みのタグを使用します。
各タグは特定のフィールドを表します。
各タグには定義済みの番号が割り当てられます。
cTrader FIX仕様は、フィールドと対応するタグ番号のリストを提供します。

バリュー{value}

バリューは、それに割り当てられたタグの値を表します。
バリューには、以下のデータ型のうち1つしか指定できません：整数、浮動小数点、文字、時刻、日付、データ、文字列

cTrader FIX API 内のすべてのメッセージは「8=FIX.x.y」で始まり、x.y は FIX プロトコルのバージョンです。すべてのメッセージの最後には、”10=xyz” というフィールドがあり、xyz はチェックサムと呼ばれるメッセージ内のすべてのバイナリ値の合計を表します。

チェックサムは、受信者がメッセージのどれかが欠落しているかどうかを知ることができるようにすることで、送信上の問題、特にパケット・ロスを特定するのに役立ちます。

シンボル(55)タグが cTrader/cServer への FIX メッセージで使用されている場合、FIX シンボル ID を指定する必要があります。この値はブローカーによって異なる場合があります。そのブローカーの cTrader アプリケーションのシンボル情報ウィンドウで、FIX シンボル ID フィールドを見つけることができます。

メッセージの例

8=FIX.4.4|9=126|35=A|34=1|49=theBroker.12345|57=TRADE|50=any_string|52=20170117-08:03:04|56=CSERVER|98=0|108=30|553=12345|554=passw0rd!|10=131|

タグ #	タグ名	バリュー	定義
8	BeginString	4.4	FIX Version
9	BodyLength	102	Message Body Length is 102 characters
35	MsgType	A	Message Type is Logon
34	MsgSeqNum	1	Message Sequence number is 1
49	SenderCompI	D	broker.1047 ID of the trading party, where “broker” is the unique BrokerUID provided by cTrader and “1047” is the numeric identifier of trading account
57	TargetSubID	TRADE	Additional session qualifier. Possible values are: “QUOTE”,”TRADE”.
50	SenderSubID	QUOTE	Assigned value used to identify specific message originator.
52	SendingTime	20131129- 15:40:10.276	Time of message transmission is November 29th, 2013 (YYYYMMDD) at 15:40:10 and 276 milliseconds
56	TargetCompID	CSERVER	Message target is CSERVER. It is the only valid value within cTrader FIX API
98	EncryptMethod	0	Currently, only valid value is “0” (zero)= NONE_OTHER (encryption is not used)
108	HeartBtInt	30	Heartbeat interval in seconds. Value is set in the ‘config.properties’ file (client side) as SERVER.POLLING.INTERVAL’. 30 seconds is default interval value. If HeartBtInt is set to 0, no heart beat message is required.
553	Username	1047	The numeric User ID
554	Password	MyPassword1	User password
10	Checksum	0	The way to calculate the checksum is as follows: summing every byte of the message up to but not including the checksum field itself, then transforming it into a modulo 256 number prefixed with “0” to receive 3-digit number