私は修正セッション層を研究していて、セッションレベルの拒否について混乱しています。
セッション中に文字化けまたは無効な（チェックサムのエラー、本体の長さ、必要なタグの欠落など）受信メッセージが表示された場合、正しい回復方法は何ですか？私は次の3つについて考えています：
もう1つは、REJECTの後に必ずLOGOUTとDISCONNECTIONが続くということです。
前もって感謝します。
一般的に言えば、無効なメッセージに対する正しい応答は、タグ # 45 (RefSeqNum) で参照されるメッセージのシーケンス番号を含むセッション レベルの拒否 (メッセージ タイプ 3) です。残りはオプションです。できるだけ多くの情報を含めることは、一般に、問題に対処している人々に役立ちます。その情報がないと、問題の診断が難しくなり、多くの顧客からの要求や電話が発生する可能性があります。
メッセージを無視することは決して良い考えではありません。ログアウトを送信するだけでも、決して良い考えではありません。相手側の接続がセッションの終了を要求している理由が明確ではありません。
拒否後にログアウトを送信するかどうかは、完全にあなた次第です。それを行うシステムもあれば、そうでないシステムもあります。ログアウトは役に立たないので、それは本当に問題ではありません。
メッセージにキー フィールドがない、または無効なチェックサムが生成されているなどのエラーにつながる何かが発生した場合は、アプリケーションが正しく記述されていない可能性があり、その場合はすぐに停止して修正する必要があります。もう 1 つの可能性は、システム障害 (つまり、電離放射線によるエラー ☺) です。この場合、エラーを適切に処理することはできません。
これらの状況は、開発およびテスト (認定) 期間中に一般的であり、本番環境ではほとんど見られません。テスト/ステージング/開発環境では、交換はできるだけ詳細なメッセージを単純に拒否します。これにより、開発者は何が問題なのかを知ることができ、コードを修正して再試行します。
本番環境では、そのようなことが起こることは受け入れられず、サポート部門が関与する必要があります。まれにエラーが発生した場合、取引所は単純に拒否を送信します。しかし、誤動作しているクライアントが数百万 (またはそれ以上) の不正なメッセージを送信し始める可能性があることは想像に難くありません。これにより、FIX ゲートウェイに接続されているすべてのクライアントの速度が低下したり、サービス拒否が発生したりする可能性があります。これは受け入れられず、取引所はそれを防ぐためにさまざまな手法を採用しています。状況を常に監視し、悪質なクライアントを (たとえば、ファイアウォールを使用して) 禁止している人々がいて、途方もなく高いエラー率を検出した場合は、クライアントに電話して状況を知らせます。他の交換では、いくつかのメッセージを拒否し、クライアントがエラーを修正していない場合はログアウトを送信します。最後に – アクセスを自動的にブロックします。極端な場合、クライアントは認証に再び合格するまでそれ以上のアクセスを拒否され、不便さに対して罰金を科される場合があります。しかし、もちろん、それは FIX プロトコルの範囲を超えています。
また、私は金融アプリケーションを約 10 年間書いてきました。現在私が所属している会社は、米国のすべての取引所、および世界中の多くの主要な取引所に存在しています。幸いなことに、それらの多くは FIX を使用していません。しかし、FIX を使用しているもののリストから、FIX プロトコルに準拠しているものを 1 つも見たことがありません。一度もない。したがって、あなたの最善の策は、あなたが接続している交換ルールに従うことです (そして、彼らはあなたに悪いメッセージを送ることは決してありません.サーバー部分を作成している場合は、クライアントが期待する最も論理的なことを行います。
それが役に立てば幸い。幸運を！