私はしばらくの間、ポーリング TCP デーモンに取り組んできました。最近、ノンブロッキング ソケットが send() または recv() 中に EWOULDBLOCK エラーをスローすることがあるという記事を読みました。私の理解では、recv() が EWOULDBLOCK をスローする場合、これは (通常) 受け取るものが何もないことを意味します。しかし、私がはっきりしていないのは、どのような状況で send() が EWOULDBLOCK をスローするのか、そしてそのようなイベントを処理するための適切な手順は何でしょうか?
send() が EWOULDBLOCK をスローした場合、デーモンは単純にそのイベントから次のイベントに移動する必要がありますか? epoll のようなポーリング インターフェイスを使用すると、記述子が書き込み可能になったときに新しいイベントが発生しますか?
私がはっきりしていないのは、どのような状況で send() が EWOULDBLOCK をスローするかということです
送信バッファー (通常は OS によって保持されますが、TCP/IP スタックのどこかにある) がいっぱいで、相手がバッファーから送信されたビットをまだ確認していない場合 (したがって、スタックは保持する必要があります)再送信が必要な場合に備えて、バッファ内のすべて)。
そのようなイベントを処理するための適切な手順は何ですか?
何らかの方法で、相手側が送信されたパケットの一部を確認するまで待機する必要があります。これにより、TCP/IP スタックがさらに「送信」するためのスペースを解放できるようになります。古典的なselectものとより現代的なものepoll(および他の OS ではkqueue&c) は、そのような待機を実行するためのスマートな方法を提供します (何かを読み取るために待機するか、何かを書き込むために待機するか、または「2 つのうちどちらが先に発生するか」)。そうです、watched-descriptor の準備が整ったこと (読み取りまたは書き込みのいずれか) は、epollイベントの典型的な理由です!