カスタムネットワークプロトコルを検討してください。このカスタムプロトコルを使用して、中央の.NETベースのワークステーションからLAN経由でロボット周辺機器を制御できます。（重要な場合、ロボットはチップ生産環境でファブを移動するのに忙しいです）。
- 会話の相手は、.NETステーションとロボット周辺機器の2つだけです。
- ロボット側はリクエストの受信と応答の送信のみが可能です
- .NET側は、要求を開始して応答を受信することしかできません
- リクエストごとに常に1つの応答が必要です
- 結果として生じるリクエストは、応答を待たずに次々に続くことができますが、同時に処理されるリクエストの固定制限（たとえば、5）を超えることはありません。
素敵なディテールやアイデアについて、友人（デザインを所有しているので、傍観者として話し合った）と徹底的に話し合った。議論の終わりに、タイムアウトの欠落について強い意見の不一致がありました。私の友人の主張は、両側のソフトウェアは無期限に待つべきだというものです。私の主張は、タイムアウトはどのネットワークプロトコルでも常に必要であるというものでした。私たちは単に同意することはできませんでした。
私の理由の1つは、障害が発生した場合は、どのようなコストでも「迅速に失敗」する必要があるということです。障害がすでに発生している場合、回復のコストは、障害に関する情報を受け取るために費やした時間に比例して増加し続けるためです。LANで1分後、待つのをやめて、アラームを鳴らしてください。
しかし、彼の主張は、回復には失敗したものの正確な修復（この場合はネットワーク接続の回復）が含まれるべきであり、ネットワークが失われて修正されたことを理解するのに何時間もかかる場合でも、ソフトウェアはただちに透過的に実行し続けるべきであるというものでしたLANケーブルを再接続した後。
この議論が行われるまで、私は時代を超越したプロトコルについて真剣に考えることはありませんでした。
議論のどちら側が正しいですか？「速く失敗する」または「決して失敗しない」？
編集：失敗の例は通信の喪失であり、通常はTCP層によって検出されます。この部分も議論されました。TCP層がエラーを返す場合、上位のカスタムプロトコル層は送信を再試行し、それについての引数はありません。問題は、下位レベルが試行を継続できるようにする期間はどれくらいかということです。
受け入れられた回答の編集：回答は2つの選択肢よりも複雑です：「最も一般的なアプローチは、実際の送信の試みが失敗し、接続が長い間失われたことを確実に確認するまで接続を放棄することはありません。接続が長い間失われたことを計算するには、ハートビートを使用しますが、即時アラームではなく、この確認のみの損失の年齢」。
例：Telnetセッションを使用している場合、端末を永久に稼働させ続けることができ、Enterキーを押す間に、下位レベルのルーチンで検出可能な障害があったかどうかはわかりません。