我查看了FIX v4.2規範，我不清楚在會話中間丟失TCP連接時它應該是什麼樣的預期行爲。TCP連接丟失時的預期行爲是什麼？
更具體地說，假設當前的序列號是100，並且此時TCP連接丟失，當任何一方試圖恢復會話時，它重新發送消息號碼100，或者通過登錄啓動新會話？
在描述FIX會話時，規範說一個會話有一個登錄和一個註銷，但可以跨越多個物理連接。這導致我認爲，當TCP連接丟失時，恢復過程不應該以登錄消息開始，但我對此不積極。
在此先感謝！
FIX協議沒有定義任何與傳輸協議相關的內容。官方網站上有一些文件只提出了如何在該協議或該協議的基礎上實施它，但只是建議。
因此，TCP/IP斷開情況下的預期行爲取決於實施。例如，有可能有一個系統根本不關心TCP/IP斷開連接，這會使這些細節無關緊要。在這種情況下，預期的行爲將是在連接重新建立後繼續發送接收消息，並且當然繼續「恢復」丟失的消息（如果有的話）。但事實上，我從來沒有見過這樣的系統。
實際上，所有系統都將TCP/IP斷開視爲會話的隱式丟失，並希望客戶端在重新連接時發送登錄。
登錄時，有兩個選項 - 重新連接會話可能會發送下一個出站序列號，或者它可能會要求服務器重置序列（至1）。在第一種情況下，如果序列大於或等於預期的值，服務器端可能會發送登錄確認，如果收到的序列號小於預期，則關閉（甚至拒絕）會話。此外，如果序列大於預期，服務器將發出重新傳輸。客戶端會話也會監視服務器的順序，並且如果檢測到間隙（接收順序比預期更大），則需要請求重新傳輸。在第二種情況下，如果服務器支持序列重置，則輸入和輸出序列都將重置爲1，並且不會恢復任何消息。
對於您的情況，如果在發送序列號爲100的消息後連接丟失，則客戶端必須重新連接併發送序列101的登錄，然後從該處繼續。或者，連接並重置序列，在這種情況下，某些消息可能會丟失。
此外，不要忘記檢查你連接到的場地的具體情況。可能有非常奇怪的細節，完全不是由FIX協議規定的，甚至是那些違背FIX協議的細節。例如，ICE（實際上是最常見的腦死亡交易所之一）是這方面最愚蠢的交易之一 - 它不允許在15秒內重新連接，如果客戶端無法連接30秒，他們應該切換到故障轉移服務器。如果發生故障轉移，它們無法保持序列號的完整性，並且客戶沒有選擇，只能重置序列號。
希望它讓事情變得更清晰一點。祝你好運！
如果傳輸層是TCP/IP，我希望本屆會議的引發劑到：
序列號在登錄消息上使用取決於會話的類型以及與FIX會話接受者達成一致的內容（請參閱規範以瞭解詳細信息）。對於重放任何批量消息沒有價值的會話，例如在價格過低的市場數據饋送中，發送序列號爲1的登錄消息並設置標籤141 = Y（重置序列號）是有意義的。對於可能需要重播消息的訂單會話，會話發起者通常應該使用比發送的最後一條消息大的序列號登錄（並期望來自FIX會話接受器的序列號大於最後1的登錄響應收到消息）。
除非您確實需要重播消息，否則每次登錄時都會重置序列號更清晰，更容易。這顯然取決於FIX會話接受器（FIX服務器）對此的支持。對於像STP提要這樣的東西，我發現這樣做要可靠得多，而且應用程序協議通常更適合提供應用程序級別的重播功能，而不是依賴於FIX會話重播的脆弱性。