私はソケットプログラムをC++で書いています。このプログラムは、一連のクラスタマシン上で実行されます。TCP障害を処理するための適切なメカニズムは何ですか？
私はちょうどソケットプログラミングに入り、ちょうど送受信の仕方を学びました。私は、プログラムの長時間実行中に、一部のTCP接続が失われる可能性があると思います。その場合、サーバーとクライアントをスムーズに再接続する必要があります。
これを達成するためのよく知られた基本的なメカニズム（またはアルゴリズム？プロトコル）があるのだろうかと思います。私は、セマンティクスの異なる多くのソケットエラーコードが多数あることがわかりました。
私が学ぶことができる参照コードはどれも提案できますか？
ありがとう、
これは複雑ではありません。同じ番号のための2つの名前が実際にある
select()/poll()/epoll()の後に記載されています。他はすべて接続に致命的なものであり、それを閉じる原因になります。
実際の特定のエラーコードは無関係です。アクティブなソケット接続がある場合、失敗した読み取りまたは書き込みは、接続がなくなったことを示します。おそらくエラーコードはあなたにいくつかの説明を与えていますが、今は少し遅れています。ソケットは消えています。これ以上はありません。それは存在しなくなった。それは元のソケットです。エラーコードを使用してカラフルな説明を出すことはできますが、それは少しの慰め以上のものではありません。特定の理由が何であったとしても、あなたのソケットは消えてしまい、それに対処しなければなりません。
ノンブロッキングソケットを使用している場合、特定の戻りコードとerrnoの値がありますが、ソケットはまだ問題ないが、何かを読み書きする準備ができていないこと、具体的にチェックする必要があることハンドル。これは唯一の例外です。
また、EINTR通常はは、必ずしもソケットが実際に壊れているわけではありません。そのためにチェックする別の例外かもしれません。
壊れたソケットがあれば、唯一の一般的な設計原理は、ビジネスの最初の注文としてclose()でなければならないということです。ファイル記述子はまったく役に立たない。それ以降は、次に何をするかはあなた次第です。このような状況では、石にエッチングされたルールはありません。通常、アプリケーションは何らかの形でエラーをログに記録したり、別の接続を試みたりします。何をすべきかを理解することは、一般にあなた次第です。
ソケットプログラミングの「よく知られている基本的なメカニズム」については、明示的なタイムアウトです。ネットワークエラーと障害は、基本となるオペレーティングシステムによって常に検出されるとは限りません。ネットワーキングの問題が発生すると、すぐには検出できないことがあります。プロトコルスタックが壊れたソケットを宣言するまでには数分かかることがあり、エラーが表示されます。
特定のアプリケーションをコーディングしていて、ある一定の時間枠内で何かを読み書きする必要があることがわかっている場合、共通の設計パターンは明示的なタイムアウトをコード化することです。タイムアウトが期限切れになると、ソケットが壊れていると想定します。明示的なエラー表示がない場合でも、close()です。それから、次の手順に進みます。
読み取りまたは書き込みは、EAGAIN/EWOULDBLOCKまたはEINTRで失敗する可能性があります。*は、「接続がなくなった」ことを示します。また、読み取りタイムアウトが設定されている場合は、EAGAIN/EWOULDBLOCKをブロックモードで取得できます。 – EJP
TCP接続が失敗すると、通常は致命的な状態になります。 TCP接続の失敗を処理する「標準的な」方法は、単に接続を閉じて再接続を試みることです。 –