プロトコル開発ガイドライン

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）それが起こると、セッション解放または
2を開始する）レイヤ1は、接続確立手順すぐ
を終了するために、レイヤ0を指示する必要がありますするイベント6を待つべき。

正しい方法はありますか？

（1）私たちは私たちがエラーのためにセッションを終了しようとしていることを知っているにもかかわらず、我々はEVENT6が入る前に、他のイベントを処理する必要がある、となりますと問題。

Answer 1

私はのファンですfail fastデザイン。あなたが続けることができないことを知るとすぐに、相手に知らせて、終了してください。

何らかの理由で他の側が終了メッセージを受け取ったことを確認する必要がある場合、私はUNABLE_TO_COMPLYメッセージの要求に応答するか、イベントを完全に破棄することをお勧めします。問題は半開状態になることができるということです。

すでにフェイルメッセージを送信した後で、相手側が他の要求からの応答を待っている状況を処理する方法の1つは、優先キューを使用することです。要求を受信した順に処理するのではなく、受信したメッセージがすぐに処理されることを示すことができます。より高い優先度のメッセージがキューの先頭に挿入されるので、実際に処理できないことがわかっている他の要求によってquit_on_failureイベントがブロックされません。

私は一般に、時間ベースのウォッチドッグも嫌いです（開発者が選択した時間がすべての状況で決して適切ではないためです）。しかし、この種のプロトコルでは、しばしば反対側が応答しない最悪のシナリオを定義する必要がありますfailメッセージに追加してください。このような状況では、構成可能なタイムアウトが通常はクリーンアップの唯一の方法です。タイムアウトは、常に最初の決断ではなく、最後の手段であるべきです。

Answer 2

受信側からの肯定応答なしで、一方向（レイヤーを介して）に4つのメッセージが連続していますか？ TCPのSYN-ACK/RSTパケットのような確認メッセージをクライアントに送信させると、問題のシナリオが自動的に処理され、他のエラーモード（クライアントまたはネットワークに障害が発生した場合）に役立ちます。

Answer 3

プロトコルに適切なタイムアウトがあり、何らかの（非）確認応答メッセージを追加する必要があります。次に、保留中のセッションをキャンセルするためのレイヤー1の要求は、リモートセッションからの次のメッセージへのナックによって、またはクライアントのリモートセッションからの応答とリモートセッションのタイミングにまったく応答できない非活動のために外に出る。

以前のポスターでは、タイムアウト処理なしで完全なプロトコルを使用することはできません。これは、基本的なトランスポートエラーを捕捉するのに適しているためです。 「プロトコルの終了」を通知する方法としてタイムアウトに頼るかどうかは、設計上の決定です。私は通常、両端にタイムリーにプロトコルを試して終了させるために、プロトコルでナックを送信したりキャンセルしたりしようとします。しかしタイムアウトも必要です。

Answer 4

1）それは私見

発生するイベント6を待ち、セッション解放を開始すべき、あなたは今までに終了要求にクライアントをブロックするべきではありません。システムがシャットダウンしているため、アプリケーションを終了する必要があるかもしれません。実際にはそれをやり遂げることはできません。管理者は電源スイッチを最低レベルで制御しています。この現実を受け入れないと、プロトコルに基づいて構築された製品は迷惑になるという評判を得るでしょう。

2）レイヤ1は、接続確立手順

はいを​​終了するために、レイヤ0を指示するべきです。

私はその層1はまた、それはステップ2の後に任意の時間のように、それが終了するために「巻き戻し」のいくつかの学位を取ることになりますちょうどステップ4

後、ステップ1が完了した後、いつでもキャンセルする必要はありませんことに気づきます。

ローカルエンティティとリモートエンティティは、それらの間にネットワーク遅延を持ち、任意の時点で状態が何であるかについて異なる認識を持つことがあります。たとえばローカルではステップ2を完了している可能性がありますが、リモートエンティティはステップ5と完了したと信じています。メッセージが順不同で到着する可能性がある場合（UDPなど）、さらに多くの可能性が生じます。

「終了」は、程度の差はあれ、成功しない場合があります。ステップ2を送信してから終了しても、リモートエンティティから返信されない場合はどうなりますか？

上位レベルのクライアントで追加の要件が課される場合があります。たとえば、手順2の後と異なる手順5の後で取り消していますか？手順3と5は、リモートエンティティでの永続的な変更（データベースコミットなど）を表していますか？より高いレベルのクライアントは、終了要求が処理されるまでに実際にどのくらい進んだのかを知る必要がありますか？

考えられるすべての組み合わせを試して、ユーザーの靴に身を置いてください。ここのユーザーは、自分のユーザーのために「うまくいく」ようにプロトコルを構築しようとするエンジニアかもしれません。あなたがそれをした後、特にメッセージを巻き戻す過程で、途中で各メッセージが失われたり遅れたりするとどうなるかを考えてください。

次に、リモートエンティティの観点から考えてみましょう。彼の管理者は、時には彼を動かすことができる必要があり、すべての州からの接続も効率的に終了する方法が必要です。

Answer 5

待機中にどのような利点がありますか教えてください。あなたはすでにそのアプローチに問題があることを指摘しています。すでにオプション2が実際には最良の方法であることをすでに発見したように思います。正しさは単なる意見ですが、私はオプション2と言います。

レイヤー1は接続プロセスを終了するように指示する必要があります。この手順では、レイヤ0にもはやイベントの受信には関心がないことを指示する必要があります。レイヤ1は切断状態で継続することができます。

私にとっては、最も簡単で分かりやすいことであり、最も問題の少ないものです。すでに述べたように、レイヤー1でこれ以上の状態を処理する必要はありません。なぜなら、すでに接続を閉じたときに他のメッセージは期待されないからです。