Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

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

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

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

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

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

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

Анонимщик (2004-07-23 13:10:00) [1]
Поспешил наврать, пока не верьте.

Анонимщик (2004-07-23 12:56:00) [2]
У меня регулярно наблюдаются ситуации, когда SendBuf возвращает положительное значение, меньше размера переданного буфера. Даже в случаях
SendBuf(myInt, SizeOf(myInt))
Win2000

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

ЗЫ: ХР SP1 D7

Григорьев Антон (2004-07-23 10:29:00) [4]

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

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

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

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

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

Rouse_ (2004-07-22 20:55:00) [5]
> А где документировано поведение TCP/IP WSP?
RFC, номер к сожалению не помню...

Rouse_ (2004-07-22 20:53:00) [6]
> 1. Если буфер пуст, в буфер кладутся данные размером до примерно 30 мегабайт независимо от значения опции SO_SNDBUF. При больших размерах передаваемых данных возникает ошибка WSAENOBUFS.

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

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

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

Григорьев Антон (2004-07-22 18:48:00) [7]
Интерес, конечно, в основном теоретический. Просто поэкспериментировал после нашего предыдущего разговора на эту тему, вот и стало интересно.

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

Digitman (2004-07-22 17:15:00) [8]
а тебе нужно об этом знать ? в подробностях ?

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »