Буфер 256 байтов сокета C++

Когда вы звоните , читайте ( или получает ) из буфера для чтения из сокета, возвращается целочисленное значение, которое указывает количество прочитанных байтов. Вы должны только взять это из буфера. Остальное не имеет значения:

int count = read(...);
// buffer[0 .. count - 1] contains the appropriate data.

Алгоритм Нейгла обычно включен по умолчанию. Это объединит несколько маленьких пакетов в один. Выключение алгоритма Nagle позволит немедленно отправлять небольшие пакеты.

Существуют буферы для хранения данных, пока вы не будете готовы их отправить. Размер буфера отправки равен 256. До тех пор, пока через буфер не будет передано 256 символов, ваши данные не будут отправляться на другую сторону. Это можно исправить, вызвав метод очистки в буфере, когда вы будете готовы к отправке.

Для ясности, вы буферизуете изнутри, тогда ОС (или библиотека) снова буферизуется, когда вы вызываете send () и передаете некоторые данные.

Если вы уточните, с какой библиотекой вы пользуетесь, и, возможно, включите фрагмент кода, мы, вероятно, сможем найти подходящую функцию очистки буфера, чтобы отправить вас в путь.

В качестве альтернативы, если вы находитесь в * nix, просто отключите алгоритм Nagle, чтобы ОС не буферизировала ваши маленькие пакеты. Или, когда вы настраиваете свой сокет, обязательно используйте опцию TCP_NODELAY

Предполагая, что это сокет SOCK_STREAM, важно помнить, что базовый протокол TCP не поддерживает никаких границы сегмента. То есть, когда вы вызываете send () несколько раз, все отправленные вами данные очень легко могут быть возвращены одним вызовом recv () на другом конце. Или данные, отправленные в одном вызове send (), могут быть возвращены в нескольких recv () на другом конце, например, если некоторые пакеты были задержаны из-за перегрузки сети. Это имеет основополагающее значение для дизайна TCP, и ваше приложение должно быть разработано соответствующим образом.

Также, как отметил Мехрдад, вызов recv () возвращает количество байтов, которые были прочитаны по проводам. Все, что находится после этой точки в буфере, является мусором, и данные не заканчиваются нулем.

Сокет SOCK_DGRAM использует UDP внизу, который полностью ориентирован на пакеты, в отличие от потоковой, как TCP. Однако UDP не гарантирует надежность (U обозначает ненадежный), поэтому вам придется самостоятельно обрабатывать потерянные, дублированные, неупорядоченные и т. Д. Пакеты. Это намного сложнее, чем потоковый ввод-вывод.

Программирование на сокете утомительно, подвержено ошибкам и не переносимо. Начните использовать библиотеки, такие как Boost или ACE , которые защищают вас от API низкого уровня C и предоставляют независимые от платформы абстракции.