2013-03-16 3 views
1

Я реализую небольшое приложение, использующее UDP (в C). Сервер отправляет клиенту данные из заданного файла в кусках заданной суммы (например, 100 байт/звонок). Клиент загружает файл и сохраняет его где-то. Уловкой является то, что клиент может получить параметр, указывающий, сколько байтов для чтения/вызова.
Моя проблема в том, что сервер отправляет 100 байт/вызов, а клиент настроен на чтение только 15 байт/вызов. Остальные 85 байт теряются, поскольку сообщение удаляется из очереди UDP.UDP - Чтение данных из очереди в кусках

Есть ли способ прочитать эти сообщения в кусках, не удаляя их из очереди до тех пор, пока они не будут полностью прочитаны?

+0

Измените свой протокол клиентского сервера, чтобы избежать путаницы друг с другом – Vorsprung

+0

Это было бы здорово, но я не создал протокол. Я должен сделать это маленькое приложение, которое для моего курса компьютерных сетей и протокол был дан. –

+0

ОК, позвольте мне сказать другим способом. «когда сервер отправляет 100 байт/вызов, а клиент настроен на чтение только 15 байт/вызов« вы должны контролировать один конец или другой. Просто не устанавливайте клиент и сервер для чтения неправильного количества байтов! – Vorsprung

ответ

2

UDP не разрешает чтение каналов, как TCP. Чтение UDP-сообщения - это операция «все или ничего», вы либо полностью читаете все сообщение, либо ничего вообще не видите. Между ними нет. Из-за этого протоколы на основе UDP либо используют сообщения фиксированного размера, либо требуют, чтобы обе стороны динамически согласовывали размеры сообщений (например, TrivialFTP).

Нет причин для того, чтобы UDP-протокол требовал отправки размера байта для каждого сообщения. Размер сообщения сам по себе неявно определяет размер данных внутри сообщения.

Если вы действительно должны определить размер сообщения перед фактическим чтением сообщения, вы можете попробовать позвонить recvfrom() с флагом MSG_PEEK и предоставить ему большой буфер для копирования данных (не менее 64 КБ, что сообщение UDP никогда не будет превышать , если вы не используете Jumbograms IPv6, но это отдельная проблема). На выходе будет отображаться фактический размер сообщения, которое все еще находится в очереди. Однако, если вы идете по этому маршруту, вы можете просто сбросить флаг MSG_PEEK и всегда читать с использованием буферов 64K, поэтому нет возможности удалить данные из-за недостаточного размера буфера.

+0

Спасибо за ваш ответ. Это тот же вывод, который я получил, исследуя проблему. +1 за хорошее объяснение. –

0

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

Смежные вопросы