丟失消息的檢測

2019-11-04 10:55:54

字體：大中小

來源：轉載

供稿：網友

　　關于檢測由于通信子系統的問題造成的消息丟失，我又三個建議。第一個可能是它們中功能最強而且最輕易實現的，因為沒有新的概念而又能重發知道丟失的消息。

第一個方案：

主機在發送一個消息后，保存一個消息的拷貝，直到：
*返回一個RFNM，這說明一些正常，然后處理下一個消息。
*返回一個INCOMPLETETRANSMISSION，這種情況下重發消息（這可能是一個循環，因此要設置一個重復發送一個消息的最大次數）。
*返回DESTINATIONDEAD，這說明目的主機關機，要求在進一步通信之前必須交換reset命令。
*其它返回表明在網絡中或者本地接口報文處理器（IMP）發生錯誤，這時至少要記錄錯誤，關閉對話。
按照以上步驟，可以防止消息的丟失。

第二個方案：

在主機發送消息時，消息號被包含消息中在主機對主機的頭區域中，而且消息按順序發送（這跟目前網絡中的除了有優先級的消息除外的情況一樣，因此這個建議要求主機發送任何東西時沒有優先級區分），然后接收主機把接收到的消息號跟上次收到的消息號進行比較，這樣可以發現消息的丟失。
當交換reset命令時，這對主機間的序號設為0。
每次發送一個消息時，把當前發送消息號添到消息頭的指定區域，然后把當前發送消息號＋1（對N取模，假設N=256）。
每收到一個消息，就把這個消息號跟目前的接收消息號相比較：
假如接收的消息是希望接收的，那么該消息可以接受，然后目前的接收消息號＋1（對N取模）。
假如接收的消息不是希望接收的，那說明消息丟失。
當檢測到消息丟失需要干什么并不明顯，但是至少要記錄下來，并且匯報給網絡控制中心。消息的丟失對于交互會話可能不大重要，但是對于文件傳輸卻是致命的。因此建議假如消息沒有恢復就治理對話。

第三個方案：

可以要求主機與主機之間進行應答。這個應答方案可以用與接口報文處理器之間的應答相類似的方式實現。由于這要大幅修改目前的協議，要制定出一種合理的應答策略還需要進一步的研究，因此在這里我不對它進行具體說明。
上面三個建議中，第一個是最實用，也是最輕易實現的。這幾個方案互相沒有沖突，可以同時實現并使用。

上一篇：RC5,RC5-CBC,RC5-CBC-PAD和RC5-CTS算法

下一篇：網絡圖形