edge-triggered epollを使用し、epollによってトリガーされたREADイベントからデータを読み取るために毎回recv（）を複数回呼び出す必要がないかどうかを理解しようとしています。
epollのマニュアルページには、edge-triggered epollの場合はbytes_read < bytes_requestedの場合はソケットの読み取りを中止できることが示されています。これは、ソケットバッファが明らかに使い果たされ、epoll_waitに戻る可能性があるためです。https://man7.org/linux/man-pages/man7/epoll.7.html
ストリーム指向ファイル（パイプ、FIFO、ストリームソケットなど）の場合、読み取り/書き込みI / Oスペース消費は、ターゲットファイル記述子で読み書きされたデータ量を確認することによって検出することもできます。たとえば、読み取るデータの特定の量を要求して read(2) を呼び出し、read(2) が少ないバイト数を返す場合、ファイル記述子の読み取り I/O スペースをすべて使用したことを確認できます。
しかし、これがソケットを閉じる問題をどのように解決するのか理解していません。
サーバーがクライアントに128バイトを送信し、すぐにソケットを閉じるとします。クライアントはepoll_waitで遅くなり、エッジトリガEPOLLINイベントからデータイベントとクローズイベントを受け取ります。 128バイトを4kバッファに読み込む場合、ソケットが閉じていることを確認するためにreadを再度呼び出さないようにするにはどうすればよいですか？マンページによると、要求されたバイト数より少ないバイトを読み取ると、読み取りを再度呼び出す必要はありません。しかし、これはソケットが閉じる可能性をどのように説明しますか？
読み込みを再度呼び出さない場合は、閉じるイベントを見逃す可能性があります。今、読み込みを呼び出す必要があるようです。少なくともET EPOLLINイベントを2回受け取るたびに…ここに何か抜けたような感じがします。