我學習修復會話層和具有約會話級拒絕一些混亂。FIX會話級拒絕
在亂碼或無效的情況下（校驗，bodylength錯誤，需要標籤失蹤...等）會議將是什麼正確的恢復措施期間收到的消息？我正在考慮以下三項：
另一件事是：拒絕始終跟着LOGOUT和DISCONNECTION？
在此先感謝。
一般來說，一個無效的消息的正確響應僅僅是會話級拒絕（消息類型3），其包括它指的是在標籤＃45（RefSeqNum）的消息的序列號。其餘是可選的。包括儘可能多的信息通常會幫助那些處理這個問題的人。沒有這些信息可能會使診斷問題更困難，並導致大量客戶請求和電話。
忽視的消息是不是一個好主意。發送註銷並不是一個好主意 - 它不清楚爲什麼對方連接要求會話結束。
是否發送以下內容的拒絕是完全取決於你註銷。有些系統是這樣做的，有些則沒有。這並不重要，因爲註銷是無用的。
您會發現，如果發生導致錯誤（如消息中沒有鍵字段）或正在生成無效校驗和的錯誤 - 可能會導致應用程序寫入不正確，在這種情況下應該降低立即修復。另一種可能性是系統故障（即由於電離輻射造成的誤差），在這種情況下，錯誤的處理是不可能的。
這些情況時的開發和測試（認證）時期是常見的，幾乎從來沒有在生產中看到。在測試/分期/開發環境中，交流只會儘可能詳細地拒絕信息。這會暗示開發者有什麼不對，他們會糾正代碼並再次嘗試。
在生產中，發生這樣的事情是不可接受的，如果支持部門需要參與，則需要參與。在偶發錯誤的情況下，交換隻會發送拒絕。但是你可以想象一個有故障的客戶端可能會開始發送數百萬（或更多）畸形的消息。這很容易使連接到它的所有客戶端的FIX網關變慢，甚至導致拒絕服務。這是不可接受的，交換採用不同的技術來防止它。有些人會不斷監測情況並禁止壞客戶（例如使用防火牆），如果他們發現可疑的錯誤率很高，那麼他們會打電話給客戶告知他們情況。其他交換會拒絕一些消息，然後在客戶端沒有修復錯誤時發送註銷，最後 - 自動阻止訪問。在極端情況下，客戶可能會被拒絕進一步訪問，直到再次通過認證，併爲不便之處收取費用。但是，這當然超出了FIX協議的範圍。
此外，我一直在寫金融應用程序已有十年了，現在我在美國的所有交易所都有這個公司，還有很多世界各地的主要交易所。幸運的是，其中許多不使用FIX。但從使用FIX的列表中，我從未見過符合FIX協議的單一列表。決不。所以你最好的選擇是遵循你所連接的交換規則（他們絕不會向你發送壞消息，或者如果他們這樣做 - 你將不得不打電話給他們，向他們發送拒絕將是毫無意義的），或者如果你正在編寫服務器部分 - 做你的客戶期望從你的最合理的事情。
希望它有幫助。祝你好運！