Приёмный буфер сокета UDP

[Source]

1.Вот тест, который показывает, что приёмный буфер сокета UDP может принять всего 8Кб данных. Отчего сей буфер столь мал?

2. Как можно определить число отброшенных пакетов из-за заполненного буфера приёма?

[tyomitch]

UDP-пакеты не дробятся, и поэтому ограничены в размере самым узким местом сети от источника к приёмнику.
Т.е. даже гарантии, что 8Кб пройдут, у тебя нет.

Если нужна гарантия, юзай TCP.

[Source]

а какое м.б. самое узкое место в сети (байт)? Правильно ли я сделал обработку ошибки в примере?

[tyomitch]

0 байт. Могут вообще пакеты не доходить.

[Source]

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

[iGrok]

Зависит от твоей сети. Не от типа сети, не от построения. От конкретно ТВОЕЙ сети, и ее текущей загруженности.

[tyomitch]

1. Чесслово, тебе это не нужно. Потому что я не представляю ни одной задачи, где это могло быть нужно.
В MS не дураки сидят, они до тебя весь стек TCP/IP так написали, что буфера сами заполняются как нужно.

2. Угу, похоже что могут дробиться. Но всё равно роутеры по дороге имеют право не дробить, а выкидывать непролезшие пакеты, так что какая разница?

(Также выгуглилось http://lists.apple.com/archives/darwin- ... 00069.html , можешь поглядеть)

[Source]

1. Почему не надо? Если мне будет идти огромное кол-во данных, разве пакеты не будут убиваться, когда 8Кб буфера будет заполнено?

2. не знаю, чё там написано на аглицком языке, но я сам видел, как в моём примере сокет не принимает более 8Кб в буфер.

[tyomitch]

1. Почему не надо? Если мне будет идти огромное кол-во данных, разве пакеты не будут убиваться, когда 8Кб буфера будет заполнено?

Если к тебе будет идти огромное кол-во данных по UDP, то ты всё равно никак не можешь повлиять на то, какая их часть до тебя дойдёт, так что нет смысла и пытаться.

Если к тебе будет идти огромное кол-во данных по TCP, то тебе придёт всё.

[Source]

да я не имею ввиду потерю данных где-то в сети, я имею ввиду потерю при попытке записи в заполненный буфер моего сокета!

[tyomitch]

А в чём разница?

[Source]

разница в том, что я могу обрабатывать данные прямо в Data_Arrival сокета или же сначала быстро вытягивать их в память, а потом обрабатывать. Но, т.к. механизм сего действия надо хорошо продумать, а потом реализовать, к тому же это обойдётся программе доп. затратами на работу, лучше было бы, если бы приёмный буфер сокета был намного больше. В конце концов, свободны мегабайты памяти, а буфер сокета всего 8Кб!

[tyomitch]

Блин. Давай в четвёртый раз напишу?
Если тебе пофиг, что пакеты могу теряться, тогда тебе не важно, какого размера буфер. Обрабатывай в _DataArrival
Если тебе не пофиг, что пакеты могу теряться, тогда тебе не подходит UDP.

[Source]

мне пофиг, что пакеты могут теряться в сети, но не пофиг, что они будут теряться у меня прямо на компе из-за малого размера буфера, т.к. здесь будет теряться их намного больше,чем в сети.

[GSerg]

Если ты допускаешь потерю хотя бы одного пакета, какая разница, сколько всего их пропадёт?

[Source]

чем больше пропадает, тем больше надо слать вновь, тем больше загрузка сети. Что тут неясного?

[keks-n]

Если это важно, то не надо использовать UDP.

[Source]

я понял, что никто не знает, как увеличить приёмный буфер контрола Winsock и не может ответить на вопросы первого поста. Единственное полезное, что я узнал от Тёмыча, что в узком месте сети физически может не пройти пакет 8Кб, это ж какой старой должна быть сеть? Ну и на том спасибо.

[Хакер]

Source
Перечитай ответ iGrok-а.

[keks-n]

Source
Ты видимо не желаешь слышать то, что тебе говорят. Приёмный буфер - константа, а UDP для больших объёмов данных не приспособлен - только короткие сообщения, которые могут вообще не дойти. Поскольку гарантии прихода данных нет, то не имеет смысла его изменять - хоть гигабайт поставь, всё равно будет вероятность переполнения.

[Dmitriy2003]

Странный подход, у Вас, товарисчи программеры, почему-то в других контролах такого типа возможность задать размер буфера присутвует и не огранничивается размеров 8 кб как у мс, боллее того на апишном уровне также можно реализовать эту нехитрую фишку, немогу сказать что она действительно часто необходима, но такие ситуации бываю, прогресс ведь на месте не стоит, а разработчики винсок контрола поступили мне кажется в этой ситуации не очень хоросцо!, но не я им судья однако! а вот собственно почему 8 кб ? это что типа - золотая середина такая что - ли или есть более конкретная мотивация ?

[Source]

я уж тоже подумываю об апишках, но только я ещё не знаю, как там делается обработчик вроде Data_Arrival, наверное, через сообщения окну. И какой размер буфера там можно устанавливать? Вроде там тоже есть ограничения. Придётся рыться в инете.

[Source]

а чего, метод Send работает в фоновом режиме, что на цикле отправки ошибка вылазит?

[keks-n]

Да, там используется WSASend с заданной lpComplectionRoutine. + у контрола есть свойство, которое выдаёт системный описатель сокета - мучайте его апишками, сколько душе угодно.

P. S. Программирование сокетов на чистом API - нетривиальная задача, особенно на VB.

[Source]

а почему ошибка выходит только 1 раз, должна выпадать на каждый 9-й шаг, когда отправляющий буфер сокета заполнен 8Кб и данные ещё не успели передаться?

[Source]

ладно, раз никто не хочет отвечать, будем считать что сокету стало не интересно, и он гордо перешёл в некий блокирующий режим

[ANDLL]

Заметьте - иногда людям проще придумать какую нибудь свою огромную теорию, чем попробовать понять, что же до них хотят донести другие.

[Source]

хорошо, я замечу. Как вернуть сокет в неблокирующий режим?

[keks-n]

Сначала определись с понятием неблокирующий/блокирующий режим. Обычно это связывают а асинхронностью/синхронностью обращений к сокету.

[Source]

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