2014-01-31 2 views
0

Я недавно работал с winsock api, и я обнаружил, что когда я увеличиваю размер буфера отправителя и заполняю неиспользуемые байты нулем, приемник также добавляет эти нули в конец файла. Если буфер приложения я использую больше, скажем, 3072, файл, который я получаю на другом конце, кажется, поврежден и кажется очевидным из-за добавления нулей. Но он отлично работал с буфером 2048, 1024, и в этих случаях к отправке добавлялись нули. как получилось, что он испорчен, а не другой?Winsock TCP application buffer

ответ

1

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

Таким образом, байты не были «неиспользуемыми» вообще. Вы их отправили. Вы использовали неправильный счет в вызове функции отправки.

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

Исправить.

Но он отлично работал с буфером 2048, 1024, и в этих случаях к отправке добавлялись нули. почему один из них испорчен, а не другой?

Поскольку у вас есть ошибка в вашем коде, которая была выставлена ​​только большим размером буфера. Вероятно, файл, который вы отправили, был кратным 2048 байт, поэтому ошибка в конце файла не была обнаружена.

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

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