Ну и что даст туннелирование UDP поверх UDP?


Этот вариант идеально решает проблему. Но реализация очень геморройная и это в любом случае самопал со всеми вытекающими.


Как видно из темы все же решение есть. Софта подходящего нет, тут вы правы, значит нужно создавать.


Скорость? Скорость отправки пакетов? Зачем её снижать? При чем тут тогда вмешательство в протокол? Что такое "Ускоренный Трафик" и как потери влияют на "ускорение трафика"? Ускорители трафика, это те которые твикают настройки tcp\ip стека в винде?

Чудеса бывают = ) В них просто нужно верить!
А потери измерял все тем же старым добрым дедовским методом ICMP echo!

Это сообщение отредактировал(а) SwordOfDeath - 9.2.2011, 17:09

Значит, по отношению к UDP-трафику эти 5% - не более чем цена на рис, причём в прошлом году. Неужели нельзя было UDP-пинг пустить?

Говорите убедительно... Только что-то я сообразить не могу... Каким образом мне пустить UDP пинг если к серверу у меня доступа нет?

SwordOfDeath, а в Вашем конкретном случае он вообще нахрен не нужен. Сами же говорите:

Вот наскребите пакетов тыщ с 10, и посчитайте, какой процент не добрёл.

Добавлено через 1 минуту и 38 секунд
А вообще UDP-пингеров разной степени хреновости - аки грязи.

Да, по протоколу у них там ID пакета есть... На основе него посчитал потери.... Большие пакеты теряются на много чаще маленьких. В среднем ~5%... По времени суток ночью ~1-3% вечернее время ~10%

А для UDP пинга нужен UDP echo service.

Это сообщение отредактировал(а) SwordOfDeath - 9.2.2011, 18:11

Ну среднее имеет смысл брать только если размеры пакетов распределены почти равномерно, или если разница небольшая. Так что смотря что шлёт сервис - может, там 90% посылок небольшие кадры по сотне байт...


Необязательно... лишь бы кто-то принимал там по UDP на каком-нить порту и не брезговал что-то слать в ответ, пусть и wrong request. Хотя если трасса длинная и ветвистая, туда может идти не так, как оттуда...

Добавлено @ 18:13
SwordOfDeath, нет, а всё-таки - не пробовали найти промежуточный узел такой, чтобы ни к Вам, ни к серверу целевому не терялось? т.е. фактически построить "свой" маршрут доставки пакетов...

Проблема есть и на локальном уровне (мой провайдер) и где-то в магистрали... Потому что поменял 3 провайдеров трасы разные, а результат отличается не значительно. Причем проблемные хосты сменяют друг-друга =\ Вообще странная ситуация........ 

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

PS. Разница в размерах пакета во время основного цикла программы незначительная. Размер ~1000. На маленьких пакетах ~100(в начальный период инициализации) дроп ~1% 

Это сообщение отредактировал(а) SwordOfDeath - 9.2.2011, 18:29

Иногда возможно. Иногда нет. Я знаю реальные случаи, когда людям удавалось это сделать. Найдя такое место, они арендовали там небольшой серверюшко, поднимали на нём свой socks5-прокси, и пускали трафик через него. И основной проблемой было только нужный трафик запустить туда, а всё остальное гнать напрямую - под Виндами это оказалось слегка затруднительным... 


Ну если это неразрешимая "проблема последней мили" - то задача нерешаема в принципе.

Да соксификаторы не всегда справляются.


Немогу сказать точно в каких пропорциях но проблема имеет накопительный характер. Тоесть сначала мой провайдер отожрал 1% потом еще где-то кто-то схалтурил (как у нас везде).. в итоге чтобы получить канал без потерь нужно VPS где-то в европе, а между этим VPS и мной, двух или трехкратную избыточность делать.

Подконтрольный мне корпоративный сервер который в "локальном" дата-центре имеет более качественный конект... но полностью проблему не решает и прогой все еще пользоваться очень сложно.

Это сообщение отредактировал(а) SwordOfDeath - 9.2.2011, 18:49

SwordOfDeath, а сведения о том, что это за целевой сервер/сервис - большая тайна?

Akina, = ) Ну что же это еще может быть? Секс-видео-чат... Я тут как на иголках когда она сиськи показывает, а у меня все за секунду проскакивает   

Небыло ни единого разрыва!

Да что угодно... например торговая площадка...

= ) Ну про сиськи я пошутил, а сам сервис не то чтобы секретный, просто не хочу об этом рассказывать.

Итак я определился по поводу архитектуры:
У себя дома ставлю роутер с линуксом(DIR-320), а на нем поднимаю туннель при помощи модифицированного VTun(достаточно не сложные изменения в generic/udp_proto.c). Арендую сервер у которого нет потерь на нужный мне сервис и настраиваю аналогичный тунель.

На DIR-320 настраиваю нужный мне роутинг портов и дело в шляпе. =)
За сем откланяюсь бояре.

SwordOfDeath, не обязательно именно тут его использовать. Оно вообще существует и в некоторых ситуациях даёт преимущество. Конкретно в этой только практически можно будет понять, будет лучше с TCP или с UDP.



Тут оговорился, под "скоростью" имел ввиду "задежку".
А ускорители это те, которые его всяко разно сжимают/кэшируют и т.п. riverbad или cisco waas, например.


Не может геморройный в создании самопал (ещё и нестабильный, стало быть) идеально решать проблему 

UDP поверх UDP будет ничем не лучше UDP самого... А TCP как известно совсем другая опера... К чему этот разговор?


Ну тогда VTun тоже ускоритель... Да и кеширование тут не применимо.


В теории может... И ведь не обязательно самопал, а вдруг кто-то уже решил эту проблему до меня, и такой софт существует? Опенсорс сейчас модно...
VTun очень близок к тому что мне нужно, а его доработка требует внесения изменений только в 2 функции в файле кторый я указал выше....

Я не могу понять к чему ваших 2 поста... Вы ничего не предложили...