各カウンターパーティが使用するFIXSPECを変更できるオープンソースのFIXシミュレーターはありますか？
たとえば、私はある端でいくつかのカスタムタグを使用してFIX 4.2を使用しているユーザーであり、いくつかのカスタムタグを使用してたとえばFIX4.4を使用して私と別のユーザーとのセッションをシミュレートしたいとします。
2 に答える
3
この回答はあなたの質問よりも少し広いですが、あなたの質問が基づいていると思われるいくつかの誤解の根源に到達することを目的としています.
2 つの相手方が同じ FIX バージョンを使用する必要があります。たとえば、4.2 のパーティは 4.4 のパーティと通信できません。
さらに、FIX バージョン間の自動変換、たとえば 4.4 メッセージを 4.2 に変換してから元に戻すことは実際には不可能です。4.4 には、4.2 にはない機能のフィールドがあります。
さらに、2 つの 4.4 エクスチェンジが特定のメッセージを同じように解釈するとは信じられません。2 つの交換は特定のフィールドをかなり異なる方法で使用する場合があり、たとえば ICE に送信される特定の 4.4 メッセージは、おそらく BARX に送信される同じメッセージとは異なる方法で解釈されます。ICE は異なるフィールドを必要とするか、それらのフィールドを異なる方法で処理するか、BARX が使用しない仕様にカスタム フィールドを追加します。その逆も同様です。 すべての商用 FIX インターフェイスは、他のすべてのベンダーとは異なる、カスタマイズされたメッセージ/フィールド ディクショナリを使用するというのが私の経験です。 彼らはお互いの相互運用性に関心がありません。
フィールドとメッセージの提案された辞書を持つトランスポート プロトコルとして FIX を考えるのが最善です。私は、デフォルトの辞書を変更せずに使用している取引相手と仕事をしたことがありません。
于 2013-03-01T14:57:19.763 に答える
0
FIXに慣れていない人のために、いくつかの説明が必要だと思いました. FIX ハブは、さまざまな FIX プロトコル間でシームレスに FIX メッセージを (簡単に) 変換および正規化できるため、FIX 4.0 のクライアントは問題なく FIX 4.2 の売り側に注文を送信できます。Grant が言及しているすべてのアプリケーション層の問題は、認証によって解決されます。FIX プロトコルは単なるガイドではありませんが、解釈の余地があることは間違いありません (これが、ライブ取引接続を有効にする前に認定する理由です)。プロトコルは単なる提案ではありませんが、他のプロトコルと同様に、両方の当事者がカスタマイズを知っている限りカスタマイズできます (したがって、基本的には FIX に基づく新しいプロトコルを使用することになります)。
その大部分はアプリケーション層であることに同意したため、2 つの当事者がビジネス レベルで情報をどのように解釈するかについて合意する必要があります。
間違いなく、より高いプロトコル バージョン (FIX 4.4 など) を使用して、それらをより低いプロトコル バージョン (FIX 4.0 など) に送信できます。情報の忠実度を失うか、4.0 メッセージで 4.4 タグを渡すことができます。これはすべて、FIX メッセージの正規化の一部であり、FIX ハブを使用する主な理由の 1 つです。
于 2013-06-21T11:38:51.703 に答える