Ada_Ru форум

Обсуждение языка Ада

/net/ Дублирование пакетов и/или линков

Оставить новое сообщение

Сообщения

teplouhov
/net/ Дублирование пакетов и/или линков
2006-02-20 03:41:00

Hello.

 

Народ, а что есть готового для написания подобной штуки?

(совсем готового что-то не нашел - есть впринципе openVpn, там

вроде есть криптуха и zip, но ничего на тему повышения надежности

я че-то на нашел... Или не по глазам было? ;) )

 

В общем задача такая - надо чтобы связь работала надежно и без

потерь пакетов(теоретически гарантированную доставку пакетов

в интернете никто и не обещал, только вот 99% хлама, почему-то

называемого современным программным обеспечением, вообще в таких

условиях работать отказываются :/ ).

Потери в общем-то обычное дело, причем провайдерам еще и фиг

докажешь чего...

(на дешевизну валить не надо - РОЛ и Ко около млрд баксов стоят

http://www.goldentelecom.ru/investor.asp

http://quotes.nasdaq.com/asp/summaryquote.asp?symbol=GLDN&selected=GLDN

Пришлось посыпать логами несколько мес когда уже 40% потерь было пока

вообще признались что проблемы есть, а подглюкивало дак и вообще

несколько лет похоже - неделю как маленько получше стало,

не знаю надолго ли, а то уже и забыл что такое e-mail по pop3 :/ :(

Так что можно считать фичей :) С провайдеров по-мельче как-то

и спрашивать не удобно, им бы на текущие расходы хватало,

не то что ремонт ;) )

 

В общем я так понимаю надо изобретать что-то на тему какого-то

туннельного протокола или VPN, ну и к этому модулю уже прикручивать

дупилку пакетов с обратной связью для гарантированной доставки,

ну и несколько резервных линков(с разными режимами дублирования

и приоритета выбора линии в зависимости от цены траффика и тп)...

(кстати, другие варианты есть?)

 

В общем интересно как бы это по-проще сделать(самый кардинальный

способ борьбы с глюками - чем меньше кода, тем меньше глюков,

да и возни меньше ;) )...

Вроде бы кучка готового мяса и заготовок должна быть(aws?

Что еще есть?)?

Прикручивать я так понимаю проще к FreeBSD?

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

примочек - на firstVds.ru VDS от 5$/мес всего, под линуксом

миниум что нашел 20-30$/меc)

 

Vladimir

PS Ну что, кто-нить еще будет защищать этих насекомых? ;)

Основной протокол в инете(TCP) вообще не способен работать

даже при 40% потерь уже(это чудо считает потери перегрузкой

канала и бесконечно уменьшает скорость, так что все просто висит;

между прочим, при 40% потерь еще более половины полосы канала

возможно впринципе, меня бы и 1/10 впринципе устроила),

короче говоря эти пионерские поделки за 30 лет не кому

было ни разу протестировать даже, а ведь десятки G$ на софт

истрачено...

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

teplouhov@... wrote:

 

В общем задача такая - надо чтобы связь работала надежно и без

потерь пакетов(теоретически гарантированную доставку пакетов

в интернете никто и не обещал, только вот 99% хлама, почему-то

называемого современным программным обеспечением, вообще в таких условиях работать отказываются :/ ).

Можно посоветовать только воевать с провайдером. Никакой другой сбособ не поможет.

 

 

В общем интересно как бы это по-проще сделать(самый кардинальный способ борьбы с глюками - чем меньше кода, тем меньше глюков,

да и возни меньше ;) )...

И чем меньше кода - тем лучше - тоже не пожходит.

 

Вроде бы кучка готового мяса и заготовок должна быть(aws?

Что еще есть?)?

В PolyORB есть возможность работать на наскольких альтернативных

адресах. Но это частное решение и в борьбе с потерями пакетов не поможет.

PS Ну что, кто-нить еще будет защищать этих насекомых? ;)

Основной протокол в инете(TCP) вообще не способен работать

даже при 40% потерь уже(это чудо считает потери перегрузкой

канала и бесконечно уменьшает скорость, так что все просто висит; между прочим, при 40% потерь еще более половины полосы канала

возможно впринципе, меня бы и 1/10 впринципе устроила),

короче говоря эти пионерские поделки за 30 лет не кому

было ни разу протестировать даже, а ведь десятки G$ на софт

истрачено...

Теория связи - вещь тонкая. И указанна задача кикак в рамках современной науки не решается.

On Mon, 20 Feb 2006 07:07:31 +0300, Vadim Godunko <vgodunko@...> wrote:

 

teplouhov@... wrote:

 

В общем задача такая - надо чтобы связь работала надежно и без

потерь пакетов(теоретически гарантированную доставку пакетов

в интернете никто и не обещал, только вот 99% хлама, почему-то

называемого современным программным обеспечением, вообще в таких

условиях работать отказываются :/ ).

Можно посоветовать только воевать с провайдером. Никакой другой сбособ

не поможет.

 

да бесполезно - там такие-же спецы около циски как и юзвери-"программисты"

около микрософта... :/

 

Тут не поленился как-то отрубить все лишнее и померить траффик - в общем

разница между счетчиком программы и счетчиком провайдера до 6 раз!

А дамп посмотреть в этих мелкософтовских недоделках вообще не чем... :/

(провайдера поставить дамп для отладки тоже не допросишься :/ )

Я вообще не понимаю на каком основании у них хватает наглости называть

эти творения(большинство дистров линукса кстати тоже касается) вообще

системой, если там даже элементарных системных утилит не предусмотрено...

Да и платить не понятно за что - в самой системе никто не работает,

почему спрашивается юзверь должен вообще за нее платить... Если она

нужна какой-то прикладной программе, вот пускай они там сами и рассчитываются

как хотят, не понятно почему юзверь должен покупать то что ему непосредственно

не нужно... В общем маразмов куча, но всем пофиг я смотрю...

 

 

 

В общем интересно как бы это по-проще сделать(самый кардинальный

способ борьбы с глюками - чем меньше кода, тем меньше глюков,

да и возни меньше ;) )...

И чем меньше кода - тем лучше - тоже не пожходит.

 

ну, тут как раз повезло - сложность сетевых модулей не большая ;)

 

Да и ко всем остальным глюкавым наворотам надо подходить со скальпелем,

и лечить глюки методом ампутации оных ;)

 

 

Вроде бы кучка готового мяса и заготовок должна быть(aws?

Что еще есть?)?

В PolyORB есть возможность работать на наскольких альтернативных

адресах. Но это частное решение и в борьбе с потерями пакетов не поможет.

 

PS Ну что, кто-нить еще будет защищать этих насекомых? ;)

Основной протокол в инете(TCP) вообще не способен работать

даже при 40% потерь уже(это чудо считает потери перегрузкой

канала и бесконечно уменьшает скорость, так что все просто висит;

между прочим, при 40% потерь еще более половины полосы канала

возможно впринципе, меня бы и 1/10 впринципе устроила),

короче говоря эти пионерские поделки за 30 лет не кому

было ни разу протестировать даже, а ведь десятки G$ на софт

истрачено...

Теория связи - вещь тонкая. И указанна задача кикак в рамках современной

науки не решается.

 

ну, тут-то как раз все просто.

Параметры канала(скорость, задержка) боле-мене известны, так что

настроить это не проблема.

Далее пакет если больше предела рвем, добавляем заголовок и пускаем

через туннель. (можно еще рвать на совсем мелкие если высокий уровень

ошибок в канале и потери из-за CRC, или применить ECC если канал "голый"

и пакеты выделяются программно)

На стороне передачи тупо дупилка, которая его по заданному

алгоритму(кольцевой буфер или таймаут) дупит пока не получит подтверждение

приема.

Впринципе номера идут подряд, так что на случай потери подтверждения

можно сделать компактный способ засунуть их 8-16 или все 32 шт в один

пакет - номер первого пакета, а дальше на каждый пакет по 1 биту...

В этом случае даже если часть пакетов подтверждения потеряется пофиг...

(в случае кольцевого буфера либо если таймаут в несколько раз больше

задержки на канале)

Ну и теперь что-то захотелось еще и дублирующие линки прикрутить,

чую что одной дупилки будет мало ;) Тоже впринципе не сложно,

добавить еще поле(и то нужно только для статистики) с номером канала и все...

(ну и правила/приоритеты выбора канала в настройках еще)

Ну и конечно самое главное статистику и контроль вести, а то ведь

все эти резервные штуки без системы контроля бесполезны - пока хоть один

линк работает сбой не заметишь, а когда отвалится последний будет уже

поздно ;) Можно тупо считать сколько раз и через что пакет был передан,

и сколько раз(точнее на сколько меньше :) ) его приняли...

 

 

Меня другое смущает - почему такой велосипед изобретать приходиться,

неужели всем пофиг было, вжись не поверю что на такие глюки никто

не напарывался...

 

Vladimir

PS Хуже всего что проблемы со связью не только у меня, но и на стороне

сервера бывают, а там уговорить что-то прикрутить гораздо сложнее... :/

Чую что еще немного и проще будет написать конкурирующую программу,

чем доказывать что простейшая статистика качества связи в программе

все-же нужна...

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти