В форуме нашел, что send() может вернуть число отличное от количества посылаемого, таким образом его нужно вызвать еще раз. А это не вызовет дублирующихся данных на приемнике (recv())?
Проблема такая: send() отправляет несколько фрагментов данных, ну пусть по 15кБ ровно и завершающий пусть 7кБ. Функция возвращает точно отправленное количество данных. А вот на другой стороне recv() получает все полные фрагменты по 15 и далеко не полный последний (из 7 — всего 6кБ). То есть, часть данных получается просто не дошла. Правда ли не дошла? recv() возвращает другое число, чем отсылалось через send().
Можно отправлять один(!) большой фрагмент (пусть 100кБ), но на recv() он опять будет не полный (70кБ). Это почему так?

протокол TCP, дополнительных свойств не утсанавливалось (через setsockopt()).
Спасибо.

Здравствуйте, EWhite, Вы писали:

А если еще раз вызвать на приемнике recv() пока все данные не дойдут.

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

Здравствуйте, EWhite, Вы писали:

EW> В форуме нашел, что send() может вернуть число отличное от количества посылаемого, таким образом его нужно вызвать еще раз. А это не вызовет дублирующихся данных на приемнике (recv())?
EW> Проблема такая: send() отправляет несколько фрагментов данных, ну пусть по 15кБ ровно и завершающий пусть 7кБ. Функция возвращает точно отправленное количество данных. А вот на другой стороне recv() получает все полные фрагменты по 15 и далеко не полный последний (из 7 — всего 6кБ). То есть, часть данных получается просто не дошла. Правда ли не дошла? recv() возвращает другое число, чем отсылалось через send().
EW>Можно отправлять один(!) большой фрагмент (пусть 100кБ), но на recv() он опять будет не полный (70кБ). Это почему так?

EW>протокол TCP, дополнительных свойств не утсанавливалось (через setsockopt()).
EW>Спасибо.


send() возвращает отличное от посылаемого число байт очень редко ( почти никогда ), т.к. она просто корирует данные из буфера, в какой-то буфер ОС

recv() не всегда читает ровно столько сколько послал send(). При посылке больше какой-то константы ( не помню точно — 1500байт что-ли) эти данные отправляются в несколько пакетов. Если некоторые пакеты опаздали, то соединение пошлет запрос на повтор. И если ты в это время чиаешь то тебе отдадут тоько последние прочитанные данные, так что если читать точное число байт пиши свою функцию

Здравствуйте, Vlost, Вы писали:
V>send() возвращает отличное от посылаемого число байт очень редко ( почти никогда ), т.к. она просто корирует данные из буфера, в какой-то буфер ОС

А как тогда понять отправлены (и получены!) ли они на самом деле? Буфер ОС это не есть получатель, до буфера дорога близкая... Я-то думал если send() вернул N, то все ОК...

Вот! Согласный.

Пока пробую по-разному. Кста, через дополнительное считывание recv() не прокатило. Все равно не до конца.
Мож кто сталкивался с подобной проблемой тоже... как решалось?

Или кто знает, как отправить большой кусок данных?

Здравствуйте, EWhite, Вы писали:

EW>Вот! Согласный.

EW>Пока пробую по-разному. Кста, через дополнительное считывание recv() не прокатило. Все равно не до конца.
EW>Мож кто сталкивался с подобной проблемой тоже... как решалось?

EW>Или кто знает, как отправить большой кусок данных?

Посмотри пример: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/using_sspi_with_a_windows_sockets_client.asp

функции: ReceiveMsg(ReceiveBytes) SendMsg(SendBytes)

Здравствуйте, EWhite, Вы писали:

EW>Вот! Согласный.

EW>Пока пробую по-разному. Кста, через дополнительное считывание recv() не прокатило. Все равно не до конца.
EW>Мож кто сталкивался с подобной проблемой тоже... как решалось?

EW>Или кто знает, как отправить большой кусок данных?

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

Здравствуйте, DOOM, Вы писали:

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

Именно так.