Привет,

Проблема такая: Есть приложение которое общается с сервером по UDP. Но у меня потеря пакетов порядка 5% и приложение юзать практически невозможно.
 Доступа к серверу не имею. Поменял 3 провайдера и все та же беда.

Идея: Арендовать сервер и пустить трафик через туннель. Поверх TCP, RUDP или возможно какого-то другого протокола "без потерь" но не обязательно в той же последовательности и не обязательно с установкой соединения и без шифрования. Такой себе UDP "без потерь". Идельный на мой взгляд был бы протокол который просто отправляет по 2 пакета и если один из них потерялся то второй дойдет, а если этого будет недостаточно то можно и 3 пакета отправлять. Что-то вроде мультиплексора\демультиплексора.

Подскажите как лучше всего это сделать.

PS. Клиент Windows 7.

Это сообщение отредактировал(а) SwordOfDeath - 6.2.2011, 14:45

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

Возьмите утилиту iperf и проверьте связь по tcp и udp между вами и сервером.

То что вы начали придумывать уже давно существует - vpn или openvpn. Не надо покупать сервер, можно купить туннель.

Добавлено через 2 минуты и 10 секунд
В соседней теме предлагали вот это: http://russianproxy.ru/vpn

Вы видать вопроса то не поняли. VPN я предложил еще в первом посте. И сервис на который вы мне дали ссылочку в соседней ветке предложил тоже я.
И програмка которую вы мне предложили подразумевает наличие доступа к серверу, которого у меня нет.

Попробую описать более понятно:
Сервер забугорный и не зря выбрал UDP в качестве транспорта.  Там нужна минимальная задержка. И у европейцев и америкосов с этим проблем нет. А у нас беда.
Итак задача стоит приблизительно так: Получить UDP без потерь и не сильно увеличить задержку. Тот протокол который они используют поверх UDP сильно чувствительный, сволочь.
Таким образом по моему мнению идельным вариантом будет мультиплексор\демультиплексор на всей протяженности сети с потерями.
Я также рассматривал варианты поверх TCP но при потерях значительно возрастает задержка  и для её решения мне нужно найти максимально приближенный ко мне хост у которого нет потерь на нужный мне сервер. Задача не простая, я уже пару попробовал.

PS. У сервиса много тысяч в онлайне и не испытывают никаких проблем. Трассировка показывает каждый раз что-то новое и проблемный хост неопределим.

Возможно у кого-то мысли появятся... Может кто-то решал подобную проблему.


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

Каков бюджет мероприятия? поместится ли туда аренда минимального виртуального сервера на площадке, с которой до целевого сервера нет потерь?
С него будете общаться с целевым сервером, а получать картинку хоть по вульгарному RDP, которому потери по барабану....

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

Бюджет потащит все что потребуется. Задача проблему решить!

Вот только к чему тут RDP и картинки, я о таком не говорил = )

Не проблема взять VDS на нем поднять OpenVPN. Это очень даже интересное решение. НО! Есть одна проблема, TCP при потере пакетов делает ретрансляцию, а все остальные пакеты стоят в очереди и ждут пока прийдет потеря! А это мало того что 3хPing так еще при повторной потере это убийство всего риалтайма. Чего я и хочу избежать.
Вот и интересно есть ли какое-то решение этой проблеме... например в виде протокола RUDP или SCTP. А вдруг кто-то что-то гениальное посоветует. Или самому мультиплесор\демультиплексор написать вот только как на него туннелирование натянуть. Что-то наподобие http://vtun.sourceforge.net/

Если сам можешь написать - так какие проблемы? пишешь мультиплексор (вдали) и демультиплексор (у себя). Они устанавливают между собой 2 (3, 4, сколько надо) UDP-канала, на разных портах. Мультиплексор общается с целевым UDP-сервером. Получив датаграмму, он дополняет её порядковым номером и по всем установленным каналам с небольшой паузой (скажем 10 мс) отправляет её демультиплексору. Демультиплексор получает, что добрело (при, скажем, 3 каналах и 5% потерь вероятность, что все три потеряются, можешь сам посчитать - получится мало), первый из пришедших отдаёт целевому приложению, остальные дропает. И то же в обратном направлении. А целевое приложение соответственно работает не с удалённым адресом, а с локалхостом. И не нужно никакого туннелирования.

Добавлено через 2 минуты и 54 секунды
Можно даже на собирающей стороне сделать минимальную коррекцию ошибок - скажем, отдавать пакет не сразу, а собирать всё, что пришло в течение, например, 100 мс с момента первого из параллельно посланных пакетов, и сверять.

Есть небольшие проблемы с таким решением.
Нужно как-то перехватывать траффик нужного мне приложения(не фиксированый порт а port range). А это API hook или покупка роутера на который можно установить линукс(DIR-320 например) или виртуалка с линуксом. 
Тунель должен быть двунаправленный, а это означает мультиплексор\демультиплексор на обеих концах. 
Ну и последнее, и самое важное, серверов много, а значит нужно что-то вроде NAT.
Если все это с нуля там проявятся проблемы с MTU: Если исходный пакет забит под завязку то его прийдется разбивать чтобы что-то своё вставить.
Чересчур это геморно и результат предсказать сложно. Можно продолбатся месяц и не получить нужного результата. Вот и интересуюсь готовыми решениями. Так сказать "продакшн левел".

PS Немного Wireshark'ом поглядел, у них в пакетах есть маркер(уникальный id пакета) так что мне свою нумерацию делать не придется. Это + но еще много нерешенных проблем.


Это сообщение отредактировал(а) SwordOfDeath - 7.2.2011, 22:50

Если в Windows 7 есть возможность  Port Range Routing(Не путать с Port Forward) то вопрос скажем так решен и я начну делать свой протокол.
Возможно написать NDIS драйвер это тоже вариант. Или спомощью WinPCap что-то получится в этом плане... незнаю... =\

Вся эта задумка очень смахивает на прокси с мултиплексором\демультиплексором.

Это сообщение отредактировал(а) SwordOfDeath - 7.2.2011, 23:14

Чем дальше в лес, тем толще партизаны. (с)
 
Даёшь тебе вариант, и сразу всплывает ещё "парочка мелочей"... в общем мне лично эта чехарда надоела - пока не будет полнейшая ясность ВО ВСЁМ, я не участвую. Пусть кто-нить другой в угадайки играет.

Какие угадайки? О чем вы... Задачу я сразу описал... Может быть вам она показалась не полной так спрашивайте что вам не понятно.
А если уж не знаете чем помочь так не знаете. И выдумывать ничего не нужно.

Для тех кому реально не понять суть вопроса вот нарисую: 


PS: Моё упущение я в первом посте не указал что сервер не один... В этом небыло злого умысла... Но "парочка мелочей" это вы перегибаете. 

Это сообщение отредактировал(а) SwordOfDeath - 8.2.2011, 03:51

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

Ну теперь начинаем пальцы розгибать.

Критичность времени отклика выплывает из самого протокола UDP и это само собой разумеется.

Обязательность исполнения клиентской части на конечном компьютере тоже само собой подразумевается, интересно каков процент людей использующих RDP ради какой-то программы которая может выполнятся локально. Это изврат коих еще поискать, тем более риалтайм приложение. Какой же риалтайм с RDP?

Да и плюс ко всему идея которую я предложил в первом посте подразумевает тунель. А не ретранслятор который вы предложили. Была бы задача ретранслировать я бы и сам справился. Это тривиально.............

Одно название темы прочитать достаточно чтобы понять о чем я говорю... Естественно это для тех кто понимает разницу в UDP и TCP

Это сообщение отредактировал(а) SwordOfDeath - 8.2.2011, 13:36

То есть терминальные решения ты считаешь извратом... 


Ну так ставьте вдали (open)VPN-сервер, и устанавливайте с ним канал, и туннелируйте в него UDP-трафик. Только что Вы от этого намерены выиграть? неужели не очевидно, что латание дыр от потерянных пакетов неминуемо приведёт к задержкам?

В конце концов, если бюджет неограничен, рассмотрите такой вариант - поиск 2-3-4-... промежуточных узлов, где можно арендовать минимальные серверы для построения собственной маршрутизирующей (socks-)прокси-сети, но такой, чтобы ни на одном из сегментов не было потерь.
Надеюсь, у вас эти 5% не на последнем километре?

Итак подсумирую варианты:

1) VPN: Быстро установить, легко настроить. Работают поверх TCP.
2) RDP: Быстро установить, легко настроить. Требуют серьезный поток передаваемой информации.
3) Туннелирование поверх собственного протокола: Идеальное решение. Геморно. Много не решенных проблем. Затратно по времени.
4) SOCKS5: При использовании соксификатора(API Hooking) можно получить готовое и простое решение. Работает поверх TCP.

Ищу решение качества VPN но на протоколе более схожем с UDP (RUDP, SCTP, самопальный итд)

ЗЫ. Терминальные решения организовываются в локальной(подконтрольной сети).

И UDP тоже. Сами же предложили OpenVPN.


Когнитивный диссонанс?

И сразу уточним пару моментов:
1. Чудес не бывает.
2. Если канал с потерями, то никакой софт и ухищрения не помогут. А если помогут, скорость вырастет очень заметно. Чтобы её хоть как-то снизить, нужно использовать всякие ускорители и т.п., но это потребует (очень часто) вмешательства внутрь ускоряемого протокола. Опять же, потери в канале буду влиять на ускоренный трафик ещё в большей степени.
3. Чудес не бывает. Потери - это всегда проблема. Кстати, чем вы намерили свои 5%?

Ну и что даст туннелирование 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 поста... Вы ничего не предложили...

Будет лучше. У нас же связь между узлами, через которые проходит туннель (туннели) подразумевается лучше прямой связи с сервером.



Я к тому, что это невозможно. Как решите, напишите, очень интересно.

Всем спасибо.
Я решение нашел. Когда реализую постараюсь написать статью об этом.