Странное поведение неблокирующего TCP-сокета

← →
Григорьев Антон © (2004-07-22 17:06) [0]

В справке написано, что функция send возвращает число реально отправленный байт (т.е. реально положенных в исходящий буфер сокета). Так вот, кто-нибудь когда-нибудь видел, чтобы эта функция для неблокирующего TCP-сокета возвращала положительное значение, меньшее размера переданного ей буфера? У меня получается, что при работе с удалённым компьютером она всегда либо целиком кладёт в буфер то, что ей передано, либо возвращает ошибку. Мои эксперименты выявили следующую закономерность:

1. Если буфер пуст, в буфер кладутся данные размером до примерно 30 мегабайт независимо от значения опции SO_SNDBUF. При больших размерах передаваемых данных возникает ошибка WSAENOBUFS.

2. Если на момент вызова send данные в буфере сокета уже есть, но размер этих данных хотя бы на один байт меньше, чем SO_SNDBUF, можно положить ещё данные размером как минимум 10 мегабайт.

3. Если на момент вызова send в буфере сокета лежит SO_SNDBUF или больше байт, возникает ошибка WSAEWOULDBLOCK.

На обоих компьютерах, участвовавших в эксперименте, стоит Windows 2000 Advanced Server. Пробовал устанавливать разные размеры буфера, в т.ч. и не кратные 4096 - сделанные выводы остаются в силе.

Вот меня и заинтересовал вопрос: а вообще бывают ли случаи, когда функция send кладёт в буфер только часть переданных данных?

← →
Digitman © (2004-07-22 17:15) [1]

а тебе нужно об этом знать ? в подробностях ?

те результаты, которые тебе возвращяет текущий WinSock Provider (WSP), полностбю документированы, и нет повода задумываться над тем, что он там творит у себя внутри

← →
Григорьев Антон © (2004-07-22 18:48) [2]

Интерес, конечно, в основном теоретический. Просто поэкспериментировал после нашего предыдущего разговора на эту тему, вот и стало интересно.

А где документировано поведение TCP/IP WSP? В MSDN"е я это найти не смог.

← →
Rouse_ © (2004-07-22 20:53) [3]

> 1. Если буфер пуст, в буфер кладутся данные размером до примерно 30 мегабайт независимо от значения опции SO_SNDBUF. При больших размерах передаваемых данных возникает ошибка WSAENOBUFS.

2. Если на момент вызова send данные в буфере сокета уже есть, но размер этих данных хотя бы на один байт меньше, чем SO_SNDBUF, можно положить ещё данные размером как минимум 10 мегабайт.

1. Не эксперементировал по поводу неблокирующего именно, но в асинхронном укладывал туда спокойно в примерно 4 раза больше одним махом...

2. В том же асинхронном утверждение будет неверно так как сразу придет WSAEWOULDBLOCK

← →
Rouse_ © (2004-07-22 20:55) [4]

> А где документировано поведение TCP/IP WSP?
RFC, номер к сожалению не помню...

← →
Григорьев Антон © (2004-07-23 10:29) [5]

> Rouse_ © (22.07.04 20:53) [3]

> 1. Не эксперементировал по поводу неблокирующего именно,
> но в асинхронном укладывал туда спокойно в примерно 4 раза
> больше одним махом...

Думаю, это сильно зависит от количества свободных ресурсов. У меня точное число менялось от запуска к запуску, поэтому я и написал "около".

> 2. В том же асинхронном утверждение будет неверно так как
> сразу придет WSAEWOULDBLOCK

А вот это интересно. Обязательно проверю.

> [5] Григорьев Антон © (23.07.04 10:29)
Если у тебя не вернется WSAEWOULDBLOCK - выложи код которым проверял, я у себя им же проверю...

ЗЫ: ХР SP1 D7

У меня регулярно наблюдаются ситуации, когда SendBuf возвращает положительное значение, меньше размера переданного буфера. Даже в случаях
SendBuf(myInt, SizeOf(myInt))
Win2000

Поспешил наврать, пока не верьте.

Странное поведение неблокирующего TCP-сокета Найти похожие ветки