2

シナリオ:
クライアントとサーバーの間に接続が確立されます。クライアント側の接続が閉じられ、クライアントが破棄されます。サーバー側では、閉じられた接続の一部が検出されますが、一部は検出されません。したがって、ダングリング ポインターのようなソケット記述子があります。これらを選択すると、不正なファイル記述子エラーが返されますが、無効な fd を見つけることはできません。

質問: 上記のシナリオで、クライアント接続が存在しない場合、これらをどのように処理すればよいですか。これらBAD FILE DESCRIPTORsを呼び出すことrecv()はできますか?

4

2 に答える 2

1

さまざまな状況を台無しにしたと思います。

クライアント側で接続が閉じられていて、サーバー側のソケットで select() を呼び出すと、FD_READ がトリガーされ、recv() がゼロを返すと、サーバー側でソケットを閉じることができます。

接続が失われ、サーバーが FIN シグナルを受信しない場合は、TCP ハーフオープン状況を検出するために、クライアントとサーバー間のハートビートと、各サーバー側ソケットのタイマーが必要です。

「不正なファイル記述子」エラーは、既に閉じられているソケットで API を呼び出した場合にのみ発生します。

于 2012-10-11T13:55:59.633 に答える
1

の署名select()は次のとおりです。

int select(int nfds, fd_set *restrict readfds,
           fd_set *restrict writefds, fd_set *restrict errorfds,
           struct timeval *restrict timeout);

errorfdsセットは、次のようなエラー状態を生成した記述子のリストを提供しませんEBADFか?

recv()または、不正なファイル記述子を持つファイル記述子を取る他の関数を呼び出すことができます。呼び出された関数からエラーが返される可能性がありEBADFます (検出する前に別のエラー状態を検出しない限りEBADF)。

于 2012-10-11T11:45:31.590 に答える