Здравствуйте, ononim, Вы писали:
_>>маршрутизатор должен работать на уровне IP пакетов. O>Кроме обычных маршрутизаторов еще бывают IDS/IPS, NAT'ы иногда встречаются..
Это да, про них совсем забылось, но как-то с трудом верится, что бы по произвольному порту какое-нибудь IDS/IPS вообще напрягался, в случае с торрентами, например.
Хотя конечно не в курсе.
Здравствуйте, ononim, Вы писали:
O>То есть еще как может. Желающие найти потенциальные физиологические причины тому — могут покопаться в потрохах всех роутеров существующих в мире, но я бы просто добавил контроль на уровне приложенческого протокола — это проще.
Контролировать надо, спору нет, но вот так чтобы в первом же тесте, написанном и запущенном на скорую руку, такое полезло — простите, не верю. Вероятность очень мала.
>> Кроме обычных маршрутизаторов еще бывают IDS/IPS, NAT'ы иногда встречаются.. _>Это да, но тут речь о провайдерах "у которых всё колом встаёт". Разве _>есть такие провайдеры которые тот же NAT используют для клиентов?
В смысле бывают ли провайдеры, которые не раздают белые IP адреса налево и направо? да. по кр мере у нас в Беларуси
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
_>>Это да, но тут речь о провайдерах "у которых всё колом встаёт". Разве _>>есть такие провайдеры которые тот же NAT используют для клиентов? O>В смысле бывают ли провайдеры, которые не раздают белые IP адреса налево и направо? да. по кр мере у нас в Беларуси
А при чём тут "белость" IP адресов? Таблицы редиректов при UDP NAT — это никак не огромные структуры данных, скажем больше — они влезут в память обычной рабочей станции, если шлюз будет обслуживать весь IPv4 мир.
A_L>В связи с этим вопрос: где может быть баг и какая максимальная частота отправки сообщений для UDP?
Приемный буфер забивается, самые старые удаляются. В некоторых *nix один буфер 64К на систему.
Если приемник спит, а передатчик флудит — получается описанная картина.
Здравствуйте, Alex_Logvinenko, Вы писали:
A_L>Всем привет!
A_L>Написал приложение (клиент-сервер (C++/Linux(Ubuntu))), использую для асинхронности epoll и неблокирующие сокеты. Аналогичное приложение на Windows, только там WinSock2 и IOCP для асинхронности. В общем никогда не думал, что столкнусь с таким багом: мне сообщений приходит или больше, или меньше, чем я их отослал.
A_L>Теперь подробнее: есть модуль, который разбивает большие объемы данных на более мелкие (по 1000 байт) и отсылает их в цикле (сервер), этот же модуль (на клиенте) склеивает данные и предоставляет пользователю готовое сообщение (например при отсылке картинки). Модуль работает нормально, тестировал без сетевой части. A_L>Как только начал передавать данные по сети — появились баги.
A_L>Долго не мог понять в чем дело, потом написал тест для сокетов: 2 UDP сокета в цикле отсылают данные друг-другу, а при обработке принятия данных на конкретный сокет — сделал ранее 2 переменные (int), обнулил их и делаю инкремент определенной переменной. Например: отсылаю 1000 раз на каждый сокет по 1024 байта. Тест провален. В результате переменные не равны 1000, а они меньше (в epoll) и больше (в IOCP) этого значения.
A_L>При чем: если поставить после каждой отсылки delay или cout/printf — все работает без сбоев!
A_L>В связи с этим вопрос: где может быть баг и какая максимальная частота отправки сообщений для UDP?
A_L>Спасибо!
Тут уже отписались о твоём непонимании протокола UDP.
На мой взгляд, это бага твоего протокола передачи данных.
Я бы сделал протокол обмена по другому. Создал бы два канала 1 — TCP для управления, второй UDP, дя передачи данных. Делил бы файл на n равных частей причём каждую часть сделал бы кратным (UDP_MAX_PAYLOAD — 8 байт) (4 байта на id пакета и 4 байта на номер части. Это всё вкладывается в пакет за данными). По каналу управления будешь управлять сессией передачи данных, а по каналу данных будешь передавать сами данные. Алгоритм передачи прост. По TCP сообщаешь, id части, которую будешь передавать и после подтверждения о готовности, начинаешь слать данные. Разные части данных можно гнать в несколько потоков. На основе этой схемы можно так же реализовать QoS и уменьшать количество UDP пакетов в ед. времени при высокой частоте запросов на повторную отправку UDP пакета. Канал для управления сессии можно сделать так же на UDP, но при этом появятся проблемы иного рода. В общем, идея, я думаю, ясна.
Здравствуйте, Kernan, Вы писали:
K>На мой взгляд, это бага твоего протокола передачи данных.
А TCP зачем? Можно обойтись и одним UDP. К примеру, как делает TFTP...
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, Kernan, Вы писали:
K>>На мой взгляд, это бага твоего протокола передачи данных. N_C>А TCP зачем? Можно обойтись и одним UDP. К примеру, как делает TFTP...
Конечно. Но у тебя появятся проблемы с управлением сессией передачи данных. Например, если отвалится сеть, а клиент хочет дополучить данные, то придётся посылать запросы на досылку данных. Сколько таких запросов слать 10/20/100? В общем, получишь именно такие скользкие кейсы.
Здравствуйте, Kernan, Вы писали:
N_C>>А TCP зачем? Можно обойтись и одним UDP. К примеру, как делает TFTP... K>Конечно. Но у тебя появятся проблемы с управлением сессией передачи данных. Например, если отвалится сеть, а клиент хочет дополучить данные, то придётся посылать запросы на досылку данных. Сколько таких запросов слать 10/20/100? В общем, получишь именно такие скользкие кейсы.
Ну... Кхм, работать так-же, как и TCP. Раза три послать с интервалом в 30 секунд (или сколько там у него таймаут). Мне кажется это будет проще, чем использовать отдельное соединение TCP для каждого клиента.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, Kernan, Вы писали:
N_C>>>А TCP зачем? Можно обойтись и одним UDP. К примеру, как делает TFTP... K>>Конечно. Но у тебя появятся проблемы с управлением сессией передачи данных. Например, если отвалится сеть, а клиент хочет дополучить данные, то придётся посылать запросы на досылку данных. Сколько таких запросов слать 10/20/100? В общем, получишь именно такие скользкие кейсы. N_C>Ну... Кхм, работать так-же, как и TCP. Раза три послать с интервалом в 30 секунд (или сколько там у него таймаут). Мне кажется это будет проще, чем использовать отдельное соединение TCP для каждого клиента.
3 это мало. Скорее всего нужно будет заводить таймер с увеличивающимся интервалом, который как-то ограничен сверху и делать несколько ретрансмиттов на один управляющий UDP пакет. Просто это всё надо продумывать и реализовывать. По мне, так проще взять TCP и использовать его для начала.
Здравствуйте, Kernan, Вы писали:
K>3 это мало. Скорее всего нужно будет заводить таймер с увеличивающимся интервалом, который как-то ограничен сверху и делать несколько ретрансмиттов на один управляющий UDP пакет. Просто это всё надо продумывать и реализовывать. По мне, так проще взять TCP и использовать его для начала.
На мой взгляд смысла нет делать два канала — TCP и UDP... Если нужна надежность, сразу делать TCP и не маятся, если нужна скорость передачи и простота — UDP. С минимальными допилами UDP вполне можно использовать для относительно надежной передачи. В Вашем способе мы огребаем сложности и оверхеды TCP при том, что необходимо еще и синхронизировать каналы TCP и UDP. Что нам остается от UDP? При том, что скорость мы относительно не увеличиваем — нам же надо подтверждать все по TCP...
Здравствуйте, fddima, Вы писали:
F> А при чём тут "белость" IP адресов? Таблицы редиректов при UDP NAT — это никак не огромные структуры данных, скажем больше — они влезут в память обычной рабочей станции, если шлюз будет обслуживать весь IPv4 мир.
Ну как сказать. На каждый отправленный пакет нужно хранить как минимум пару отправитель-получатель, т.е. 12 байт, плюс метку времени, пусть 4 байта. Для всего «IPv4 мира» это почти 64 гигабайта.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, ononim, Вы писали:
O>для получения представления так сказать о типичном (хотя уже немного устаревшем) "крутом" железе: http://www.wellit.ru/model.php?id=1303
О, ну как-то не впечатляет. Я лично работал с оборудованием и покруче, и как-то уже и давно что-ли получается. Я уже и забыл — как это что-нибудь админить.
А вопрос про UDP остался открытым. Какие-то доводы есть. Каких-то нехватает. В целом всё понятно. Просто несовершенный мир.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
