FIX v4.2 の仕様を確認しましたが、セッションの途中で TCP 接続が失われた場合にどのような動作が予想されるかが明確ではありません。
より具体的には、現在のシーケンス番号が 100 であり、この時点で TCP 接続が失われ、いずれかの側がセッションを再開しようとすると、メッセージ番号 100 を再送信するか、ログオンで新しいセッションを開始するとします。
FIX セッションを説明する際に、仕様では、1 つのセッションには 1 つのログオンと 1 つのログアウトがありますが、複数の物理接続にまたがる可能性があると述べています。これにより、TCP 接続が失われた場合、再開プロセスはログオン メッセージで開始されるべきではないと思いますが、私はそれについて肯定的ではありません。
前もって感謝します！
トランスポート レイヤーが TCP/IP の場合、セッション イニシエーターは次のことを期待します。
ログオン メッセージで使用するシーケンス番号は、セッションの種類と、FIX セッション アクセプタとの合意内容によって異なります (詳細については、仕様を参照してください)。価格が古くなる市場データ フィードなど、ロット メッセージを再生しても意味がないセッションでは、シーケンス番号 1 のログオン メッセージを送信し、タグ 141=Y を設定するのが理にかなっています (シーケンス番号をリセットするため)。メッセージの再生が必要になる可能性がある注文セッションの場合、セッションの開始者は通常、最後に送信されたメッセージよりも 1 大きいシーケンス番号でログオンする必要があります (そして、FIX セッション アクセプタから、最後のメッセージよりも 1 大きいシーケンス番号でログオン応答を期待する必要があります)。メッセージを受け取りました）。
本当にメッセージの再生が必要でない限り、ログオンのたびにシーケンス番号をリセットする方がクリーンで簡単です。これは明らかに、これに対する FIX セッション アクセプター (FIX サーバー) のサポートに依存します。STP フィードのようなものについては、これがはるかに信頼性が高く、FIX セッション リプレイの脆弱性に依存するよりも、アプリケーション プロトコルがアプリケーション レベルのリプレイ機能を提供する方が一般的に優れていることがわかりました。
FIX プロトコルは、トランスポート プロトコルに関連するものを定義していません。公式 Web サイトには、このプロトコルまたはそのプロトコルの上にどのように実装できるかを示唆するだけのドキュメントがいくつかありましたが、示唆しているだけです。
したがって、TCP/IP 切断の場合に予想される動作は、実装によって異なります。たとえば、TCP/IP の切断をまったく気にしないシステムを持つことができます。その場合、それらの詳細は無関係になります。その場合、予期される動作は、接続が再確立された後も受信メッセージを送信し続け、失われたメッセージがあればその「回復」に進むことでした。しかし、実際には、そのようなシステムは見たことがありません。
実際には、すべてのシステムが TCP/IP の切断をセッションの暗黙の喪失として扱い、クライアントが再接続時にログオンを送信することを期待します。
ログイン時には、2 つのオプションがあります。再接続セッションで次の発信シーケンス番号を送信するか、サーバーにシーケンスをリセットするように (1 に) 要求するかです。最初のケースでは、サーバー側は、シーケンスが予想以上の場合はログオン確認を送信するか、受信したシーケンス番号が予想よりも小さい場合はセッションを閉じる (または拒否する) 場合があります。さらに、シーケンスが予想よりも大きかった場合、サーバーは再送信を発行します。クライアント セッションはサーバーのシーケンスも監視し、ギャップが検出された場合は再送信を要求する必要があります (受信したシーケンスが予想よりも大きい)。2 番目のケースでは、サーバーがシーケンス リセットをサポートしている場合、イン シーケンスとアウト シーケンスの両方が 1 にリセットされ、メッセージは回復されません。
あなたの場合、シーケンス番号100のメッセージを送信した後に接続が失われた場合、クライアントは再接続してシーケンス101でログオンを送信し、そこから続行する必要があります。または、シーケンスを接続してリセットします。この場合、一部のメッセージが失われる可能性があります。
また、接続する会場の詳細を確認することを忘れないでください。FIX プロトコルでまったく指定されていない、または FIX プロトコルに反するものでさえも、非常に奇妙な詳細が存在する可能性があります。たとえば、ICE (実際、一般的に最も脳死状態の取引所の 1 つ) は、この点で最も愚かな取引所の 1 つです。最初の 15 秒以内の再接続は許可されず、クライアントが 30 秒間接続できない場合、フェールオーバー サーバーに切り替える必要があります。フェイルオーバーが発生すると、シーケンス番号をそのまま維持できなくなり、クライアントはシーケンス番号をリセットするしかありません。
物事が少し明確になることを願っています。幸運を！