Сколько читать из сокета при использовании select

Question

Я использую select() для прослушивания данных на нескольких сокетах. Когда я получу уведомление о наличии данных, сколько я должен read()?

• Я мог бы перебрать read() до тех пор, пока данных больше не будет, обработать данные и затем вернуться обратно в цикл выбора. Тем не менее, я могу себе представить, что сокет получает так много данных так быстро, что временно «истощает» другие сокеты. Тем более, что я думаю об использовании select также для межпотоковой связи (стиль передачи сообщений), я хотел бы сохранить низкую задержку. Это проблема в реальности?

• Альтернативой было бы всегда читать фиксированный размер байтов, а затем возвращаться в цикл. Недостаток здесь будет добавлен, когда в моем буфере будет больше данных, чем умещается.

Какая лучшая практика здесь?

Answer 1

Слишком распространенный подход здесь - это читать все, что ожидает на данном сокете, особенно если вы переходите к API-интерфейсам расширенного опроса для конкретной платформы, таким как kqueue(2) и epoll(7) Включение событий, инициируемых по фронту . Но вы, конечно, не должны! Отразите немного, связанный с этим сокетом, где-то, как только вы думаете, что получили достаточно данных (но не все), и сделайте больше recv(2) позже, скажем, в самом конце цикла проверки файлового дескриптора, без повторного вызова select(2).

Тогда вопрос слишком общий. Каковы твои цели? Низкая задержка? Высокая пропускная способность? Масштабируемость? На все нет однозначного ответа (ну, кроме 42 :)

Answer 2

Не уверен, как это реализовано на других платформах, но в Windows вызов ioctlsocket(FIONREAD) сообщает, сколько байтов можно прочитать за один вызов recv().К тому времени, когда вы на самом деле вызовете recv(), в очереди сокета может быть больше байтов.Однако при следующем вызове select() сокет все еще будет читаемым.