カスタム ネットワーク プロトコルでの無限のタイムアウトまたは「フェイルファスト」?

Question

カスタム ネットワーク プロトコルを検討してください。このカスタム プロトコルを使用すると、中央の .NET ベースのワークステーションから LAN 経由でロボット周辺機器を制御できます。(それが重要な場合、ロボットはチップ生産環境でファブの移動に忙しくなります)。

• 会話には 2 つの当事者しかいません:.NETステーションとロボット周辺ボード
• ロボット側はリクエストを受信し、応答を送信することしかできません。
• .NET 側はリクエストを開始し、レスポンスを受信することしかできません。
• リクエストごとに常に 1 つのレスポンスが存在する必要があります
• 結果として生じるリクエストは、応答を待たずに次々と即座に続くことができますが、同時に処理されるリクエストの固定制限 (たとえば 5) を超えることはありません。

私は友人（デザインの所有者であり、私は傍観者としてそのことについて話し合いました）とすべての素晴らしい詳細やアイデアについて徹底的に話し合いました。議論の終わりに、タイムアウトを逃したことについては強い意見の相違がありました。私の友人の主張は、両方の側のソフトウェアは無期限に待機すべきであるというものです。私の主張は、タイムアウトはどのネットワーク プロトコルでも常に必要であるということでした。私たちはまったく同意できませんでした。

私の推論の 1 つは、障害が発生した場合は、いかなるコストを払ってでも「迅速にフェイル」する必要があるということです。いずれにしても、すでに障害が発生している場合、回復コストは障害に関する情報を受け取るのに費やされる時間に比例して増大し続けるからです。LAN 上で 1 分経ったら、待つのをやめてアラームを鳴らすべきだとします。

しかし、彼の主張は、回復には障害の修復 (この場合はネットワーク接続の回復) が正確に含まれるべきであり、ネットワークが失われて修復されたことを理解するのに何時間もかかったとしても、ソフトウェアはただ透過的に実行し続けるべきである、というものでした。 LANケーブルを接続し直してから。

この議論が行われるまで、私は時代を超越したプロトコルについて真剣に考えたことはありませんでした。

どちらの議論が正しいでしょうか?「早く失敗する」か「決して失敗しない」か?

編集：障害の例は通信の損失で、通常は TCP 層によって検出されます。この部分についても議論されました。TCP 層がエラーを返した場合、上位のカスタム プロトコル層は送信を再試行し、それについては議論がありません。質問は：どれくらいの期間、下位レベルが試行し続けることを許可しますか?

受け入れられた回答を編集します:答えは 2 つの選択肢よりも複雑です。」最も一般的なアプローチは、実際の送信試行が失敗し、接続が長時間失われていることを確実に確認するまで、決して接続を放棄しないことです。接続が長期間失われていることを計算するにはハートビートを使用しますが、切断経過時間はこの確認のみに使用し、即時のアラームには使用しません。".

例：Telnet セッションを行っているときは、端末を永久に起動し続けることができますが、Enter キーを押す間に、下位レベルのルーチンによって検出可能な障害が発生したかどうかはわかりません。

Answer 1

「高速失敗」を好む方法ですが、あなたが発見したように、これは非常に優先的です。

私が使用しているシスコの機器は非常によく似ています-要求を送信すると、応答します。 （Over telnet。）問題は、ネットワークに障害が発生したときです。TCP接続を失います。ただし、どちらの側もデータ送信が試行されるまでその接続を閉じません。また、シスコ側はめったにそれを行わないため、決して閉じません。さらに悪いことに、一度に接続できるのは1つだけなので、ネットワーク障害が発生すると、ロックアウトされます。 （これらはリセットできますが、面倒です。）

今、ネットワーク接続をテストするには、何らかの「ping」が必要です。「まだそこにいますか？」 -AIMやIRCなど、多くのプロトコルがこれを行います。ただし、これらのpingは、送信頻度に応じて帯域幅を消費します。

では、エラー検出は帯域幅のコストに見合うだけですか？ pingの大きさは本当に必要ですか？ ＆oct; 50オクテット/ pingに到達できるはずで、10秒、30秒、1 mごとに1回などのようにpingを実行できると思います。そのような価値があると思います。問題があることを早く知るほど、良い結果が得られます。ソフトウェア自体がこれらのpingを使用して接続が失われたことを自動的に確認し、連絡先を自動的に再確立できる場合、「コンピューター、自分自身を癒す」の行に沿って素晴らしいことであり、オペレーターの手間が少なくなります。

TCP / IPを使用している場合、自動的にこれを行うことができます-TCPキープアライブを参照してください。または、AIM＆amp;として、アプリケーションのプロトコル内で実行できます。 IRCが行います。

Answer 2

シナリオでは...

• コントローラーがリクエストを送信しました
• ロボットはリクエストを受信して​​いません
• ネットワーク障害

...リクエストは送信されましたが、紛失してしまい、決して到着しません。

したがって、ネットワークが復元されると、コントローラーはリクエストを再送信する必要があります。コントローラーは応答を永遠に待つことはできません。