Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Сети";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];

Вниз

Странное поведение неблокирующего 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


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


 
Rouse_ ©   (2004-07-23 10:37) [6]

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

ЗЫ: ХР SP1 D7


 
Анонимщик ©   (2004-07-23 12:56) [7]

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


 
Анонимщик ©   (2004-07-23 13:10) [8]

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



Страницы: 1 вся ветка

Форум: "Сети";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.46 MB
Время: 0.036 c
14-1095225731
Ozone
2004-09-15 09:22
2004.10.03
Интересная задачка


4-1093438611
Xobbit
2004-08-25 16:56
2004.10.03
Запуск "Выполнить"


4-1092083186
B4rr4cuda
2004-08-10 00:26
2004.10.03
BitMap пункты в TPopUpMenu, а точнее их прорисовка...


14-1094724754
DiamondShark
2004-09-09 14:12
2004.10.03
Тест клиента


1-1095631694
snl73
2004-09-20 02:08
2004.10.03
Програмное переключение раскладки





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский