fix-protocol - FIXレイヤーを排除してパフォーマンスを向上

Question

それは理にかなっていますか？パフォーマンスの高い注文実行のために FIX レイヤーを排除する、速度と弾力性のために設計されたプロトコル?

Answer 1

FASTプロトコルは、FIXプロトコルの「より高速な」バージョンであることが意図されています。それが必要とする余分な処理の量は、それが「ネットワーク上」でのみより速いことを意味します、そしてそれで交換で箱を持っているそれらのためにあまり効果的ではありません。@dumbcoderは、いつものように、最適化とハイパワーマシンがレイテンシーを減らす最良の方法であることについて正しいです。FIXが本質的に遅くないことは、実装によって異なりますが、これも非常に重要です。セルサイドとHFTの実装は、ヘッジや投資家が使用する安価な実装よりもはるかに高速です。

Answer 2

取引所が市場メッセージを受信するために非固定プロトコルを採用すべきかどうかを尋ねていますか？いくつかはすでに代替手段を持っています（例えば、NASDAQのITCHとOUCH）。しかし、それらはFIXレイヤーを「排除」しません-それらは依然として同じ機能を提供し、異なる方法でそれを実行します。

FIXは実際にはそれほど遅い必要はありません-メッセージを（1つの大きな文字列ではなく）バイト配列として扱い、必要なものだけを正確に取得する場合（注文の受け入れ、塗りつぶしなどの場合、非常に遅くなる可能性があります）いくつかのタグ）、FIXは実際にはそれほど悪くはありません。

FIXの主なセールスポイントは、それが業界標準であるということです。取引所は独自のプロトコルを自由に開発でき、パフォーマンスを向上させることができますが、誰もが単一のプロトコルに書き込むことができるという事実は大きな問題です（常に最も効率的な方法で実装されているとは限りません）。

Answer 3

検討する必要のある別の角度は、プロトコル用に別個の通信チャネルがあるかどうか、または1つが他の上にラッパーとして実装されているかどうかです。FIXに取り組むことは、交換間でわずかな変更を加えるだけで実装が移植可能であり続けるという確かな利点です。