私はソケットプログラミングの初心者です。「control-c」を使用してソケットを閉じるのは悪い習慣であることは知っていますが、「control-c」を使用して送信プロセスを閉じた後、受信ピアのソケットが無限に受信し続けるのはなぜですか? ? 「control-c」を押してプロセスを終了した後、送信ピアのソケットを閉じるべきではありませんか? ありがとう！
2 に答える
2
「control-c」を使用してソケットを閉じるのは悪い習慣だと知っています
これにより、ソケットだけでなく、プロセス全体が閉じられます。
「control-c」を使用して送信プロセスを閉じた後、受信ピアのソケットが「」を無限に受信し続けるのはなぜですか?
推測では、質問に投稿する必要があるコードを表示せずに可能なすべてのことですが、呼び出すときにエラーとストリームの終わりを無視していますrecv().
「control-c」を押してプロセスを終了した後、送信ピアのソケットを閉じるべきではありませんか?
です。すべてのリソースを含め、プロセス全体が「クローズ」されています。
受信ソケットに関しては、閉じる必要がある条件を検出して閉じるのはあなた次第です。
于 2015-04-20T00:23:54.107 に答える
0
コードは与えられていませんが、何が起こっているのかについての知識に基づいた推測は次のとおりです。
- 送信と受信の 2 つの別個のコードが実行されています。
- CTL+C を使用して送信ソケットを強制終了すると、データを転送中になります。
- 受信ソケットが停止することを期待していますが、そうではありません。
問題は、「送信終了」合意の 1 つかもしれません。CTL+C を押したときに送信側のコードが EOF (End-of-File) (またはアボートまたは終了) を発した場合、受信側のソケットはそれを認識して受信を終了する必要があります。ただし、CTL + C を押した瞬間に送信コードが何をしているのかについては述べていません。
受信ソケットは、さらにデータを待っているだけかもしれません。受信コードに関しては、転送が行われたときに通知される予定であり、詳細情報を辛抱強く待っています。
私よりもはるかに優れたソケット プログラマが周りにいますが、そのレベルに達したら、転送プロトコルの詳細に注意を払う必要があると言っても過言ではありません。CTL+C がサーバー (送信) コードを終了するだけの場合、クライアントは、実際の終了があるのか、送信に予期しない遅延があるのか 、サーバー プロセスに頭がおかしくなったのか、一度送信を再開するのかわかりません。片付ける。
実際の値を前後に監視する手段がある場合は、データ転送の「通常の」終了時と CTL+C 終了時に何が起こるかを調べてください。これは、望ましくない動作に焦点を合わせるのに役立つ場合があります。
于 2015-04-20T00:21:17.987 に答える