協議開發指南

Question

我們有如下設計，我想獲得意見或協議指導 下面的錯誤情況。

Layer1             
---------------             
| ^^           
| (1) |(4) |(6) 
v  | |           Remote entity 
----------------          --------------- 

    Layer0-----------------(2)------------------------------->Layer0 
    Layer0<----------------(3)--------------------------------Layer0 
    Layer0<----------------(5)--------------------------------Layer0 


1. New session request to remote entity. 
2. Establish link + data(session request) 
3. Link Establishment ongoing 
4. Link Establishment pending 
5. Link Established + data (session accepted) 
6. session accepted. 

如果層1決定它不需要步驟4和6之間即遠程實體服務事件4被接收和事件6是尚未收到由於一些錯誤。

1）它應該等待事件6發生併發起會話釋放或
2）Layer1的應指示0層立即終止連接建立過程
。

哪一種方法是正確的？

與（1）將是，即使我們知道，我們將終止，因爲一個錯誤的會議上，我們需要處理其他事件event6進來之前的問題。

Answer 1

我的粉絲fail fast設計。只要你知道你不能繼續，你應該通知對方，然後退出。

如果由於某種原因您需要驗證另一方是否已收到您的退出消息，我更願意回覆請求或者發送UNABLE_TO_COMPLY消息，或者完全丟棄這些事件。問題是你可以進入半開放狀態。

在發送失敗消息之後，處理另一方卡住等待來自其他請求的響應的情況的一種方法是使用優先級隊列。不要按收到的順序處理請求，而是可以指示某些消息被立即處理，而不管它們何時收到。優先級更高的消息被插入到隊列的前端，因此quit_on_failure事件不會被其他請求阻塞，您知道其他請求無法真正處理。

我通常也不喜歡基於時間的看門狗（因爲開發人員選擇的時間長度對於所有情況都是不正確的），但是對於這些類型的協議，您經常必須定義最壞情況，其中對方從不響應到您的fail消息。在這些情況下，可配置的超時通常是清理的唯一方法。超時應始終是最後一招，絕不是第一次。

Answer 2

在接收端沒有任何確認的情況下，一個方向（通過圖層）在一行中是否有4條消息？ 使客戶端發送確認消息（如TCP中的SYN-ACK/RST數據包）將自動處理相關場景，並幫助處理其他錯誤模式（客戶端或網絡出現故障時）。

Answer 3

您應該在協議中添加某種（非）確認消息以及適當的超時。然後，第1層取消掛起會話的請求可以通過對來自遠程會話的下一條消息進行解析來實現，或者僅僅是客戶端根本無法響應來自遠程會話和遠程會話定時的響應由於不活動而退出。

正如前面的海報正確指出的那樣，如果沒有超時處理，您就無法擁有完整的協議，因爲這是捕捉底層傳輸故障的好方法。無論你選擇僅僅依靠超時作爲表示「終止協議」的方式，都是一個設計決定。我通常會嘗試在協議中發送一個nack或取消協議，以便至少嘗試並在兩端及時完成協議。但是你也需要超時。

Answer 4

1）它應該等待事件6發生併發起會話釋放

恕我直言，你不應該永遠阻止客戶端上的終止請求。可能是應用程序需要關閉，因爲系統正在關閉。無論如何，你無法做到這一點，管理員將電源開關控制在最低級別。不接受這一現實將會獲得建立在您的協議之上的產品因爲討厭而聞名。

2）Layer1的應指示0層終止連接建立過程

是。

我注意到，第1層可能還需要第1步後取消任何時候，不要只是一步後4

它看起來像第2步之後的任何時間，它可能需要某種程度的「平倉」的終止。

本地和遠程實體之間存在網絡延遲，並且可能對任何給定時間的狀態事件都有不同的看法。例如在本地，您可能已完成第2步，而遠程實體認爲他已完成第5步。如果消息可能無序到達（例如UDP），則可能會出現更多可能性。

'終止'可能會或可能不會在不同程度上成功。如果您發送第2步，然後終止，但從未從遠程實體回聽，會發生什麼？

高級客戶可能會施加額外的要求。例如，在步驟5之後取消與步驟2之後的取消？第3步和第5步是否表示遠程實體的持久修改（如數據庫提交）？更高級別的客戶在處理終止請求之前是否需要知道事情的進展情況？

研究出所有可能的組合，並做出讓自己處於用戶眼中的良好決策。這裏的用戶可能是一位試圖建立在協議上的工程師，以使其爲自己的用戶「正常工作」。在完成之後，請考慮當每條消息在路上丟失或延遲時會發生什麼情況，特別是在放捲過程中。

然後從遠程實體的角度考慮它。他的管理員有時需要關閉他的電源，因此需要一種有效地終止來自每個狀態的連接的方法。

Answer 5

你能告訴我等待有什麼好處嗎？你已經指出，這種方法存在問題，這聽起來像你已經發現，選項2實際上是最好的方式。正確性只是一個意見問題，但我會說選項2.

第1層應該指示層0結束連接過程。該過程還應該指示第0層，它不再有興趣接收事件。第1層可以在斷開狀態下繼續運行。

對我來說，這是最簡單和最明顯的事情要做，最少的問題。正如你已經說過的，你不需要在第1層處理更多的狀態，因爲當你已經關閉連接時，你不會期望那些其他的消息。