3路消息傳遞可靠的IPC協議有哪些問題？

Question

在這裏，在這個頁的末尾。最後一段， 他們提到了這個協議中出現的一些問題。 我無法理解這些問題。 ？例如， 。他說。 「如果請求處理時間很長」 我無法理解此聲明。客戶處理需要很長時間的請求在哪裏？或在服務器上？ 或者我無法理解時鐘（時間）在哪裏？它在客戶端還是服務器端？因爲這裏提到了2點結束。 「如果在這段時間內沒有收到答覆，則客戶端機器的內核會重新發送請求消息。」

Answer 1

考慮一下：

• 客戶端發送消息。如果它沒有收到來自服務器的回覆 - 例如 - 1分鐘，它將再次發送消息。
• 當服務器收到一條消息時，它僅在已經生成了對客戶端發送的消息的完整響應之後才發送回覆。

不假設您作爲客戶端向服務器發送消息。服務器收到您的消息，並開始處理它。在這個時候，你，客戶端，不知道服務器是否收到了消息。假設您向服務器發送複雜的任務，需要1分5秒來完成。 1分鐘後（忽略傳輸時間），服務器仍在忙於您的工作，但您作爲客戶端不知道任何此類信息並再次發送消息。

現在，根據實際協議的實現，也有一些潛在的問題：

• ，通過再次發送消息，可以增加一些序列數，因此無法接收回復這是可能的之後的原始消息。
• 服務器可能無法確定到達的消息是第一條消息還是必須再次發送的消息。因此，它可能已經完成了它的工作，導致不必要的處理，或者在最壞的情況下導致（業務）邏輯錯誤。

此外，通過發送消息和答覆可能不需要多次，您增加傳輸的總數據量，而不會從中獲得任何東西。

要「解決」這個問題，您可以在客戶端再次發送消息之前增加等待時間。這將在服務器上長時間運行的任務中「解決」問題，但是也會因爲你在等待更長的時間甚至發送新消息而在消息實際上丟失了的情況下受到傷害。

這裏的「真正」解決方案是讓服務器在收到來自客戶端的消息後立即確認，就像「我收到您的消息，我會很快發送回覆！」甚至在開始實際處理消息之前。