c - ネットワークのクラッシュとその結果としてのソケットの状態

Question

ソケットが動作しているネットワークがクラ​​ッシュしたときに、ソケットの状態がどのようになるかを知りたいです。私の問題は、このネットワークの崩壊をシミュレートすると、select()すべてのソケットを制御する関数が、理論的には設定してはならないソケットを返すことです。オペレーティング システムが書き込みと読み取りの両方でクラッシュしたソケットを設定する可能性はありますか?

Answer 1

最初に心に留めておくべきことは、通常、コンピュータは「ネットワーク クラッシュ」自体がいつ発生するかを認識していないということです。コンピュータが認識できるのは、ネットワークからパケットを受信して​​いるかどうかだけです。(一部のコンピュータは、ローカル イーサネット ポートの電気信号がなくなったかどうかも認識している場合がありますが、ローカル イーサネット ケーブルの信号に影響を与えることなく、ネットワークのより離れた部分がダウンする可能性があるため、その情報はたまにしか役に立ちません。 ）。

実際には、あなたのコンピューターと (通信相手のコンピューター) の間のネットワークが機能しなくなった場合、次のような影響が見られます。

(1) 送信した UDP パケットは、トレースなしで破棄され、通常はエラー表示もありません。もちろん、リモート ピアから UDP パケットを受信することもありません。

(2) お使いのコンピュータとリモート ピア間の TCP 接続のデータ トラフィックは、すぐに停止します。OS がリモート ピアからの応答を受信せずに一定のタイムアウト期間 (通常は数分) が経過すると、オペレーティング システムは「あきらめ」、TCP 接続を閉じたものとしてマークします。その時点で、リモート ピアが意図的に接続を閉じた場合と同じ動作が表示されます。そして、実際にソケットで recv() または read() を実行しようとすると、EOF が返されます (つまり、ブロックしているソケットで recv() を実行すると 0 が返されます。ブロックしていないソケットで recv() を実行すると、- が返されます)。 1)。(タイムアウトが完了する前にネットワークが回復すると、ソケットの TCP トラフィックが再開されます。

Answer 2

あなたの説明は不明確ですが、select() が関連するソケットで EOS を通知している可能性があります。これは、ネットワークの「クラッシュ」を表すのではなく、ピアによる整然とした終了を表している可能性があります。