grifin.ru Опубликовано 16 марта, 2017 · Жалоба Есть задача (пока теоретическая) сделать надежный интернет канал из двух-трех ненадежных. Причем основные технологии фалловера не устраивают, т.к. имеют ненулевое время переключения (даже с BFD). есть какие-либо технологии, позволяющие не потерять ни одного UDP пакета ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 16 марта, 2017 · Жалоба Есть задача (пока теоретическая) сделать надежный интернет канал из двух-трех ненадежных. Причем основные технологии фалловера не устраивают, т.к. имеют ненулевое время переключения (даже с BFD). есть какие-либо технологии, позволяющие не потерять ни одного UDP пакета ? А что вы такое гоняете, что даже потеря udp так критична, еcли не секрет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h3ll1 Опубликовано 16 марта, 2017 · Жалоба Wiki: UDP protocol has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network: there is no guarantee of delivery, ordering, or duplicate protection. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 16 марта, 2017 · Жалоба Причем основные технологии фалловера не устраивают, т.к. имеют ненулевое время переключения (даже с BFD). есть какие-либо технологии, позволяющие не потерять ни одного UDP пакета ? имеется в виду "не терять пакетов при переключении между каналами" или "работать без потерь на линках с потерями"? впрочем, сходу кажется, что первое без второго маловероятно. сделать-то несложно - любой vpn в tcp (например openvpn) поверх мультилинка, тут вот недавно советовали mlppp+l2tp но вы уверены, что оно вам нужно? вместо потерь пакетов будут тормоза Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
grifin.ru Опубликовано 16 марта, 2017 · Жалоба А что вы такое гоняете, что даже потеря udp так критична, еcли не секрет? SLA, если коротко имеется в виду "не терять пакетов при переключении между каналами" или "работать без потерь на линках с потерями"? впрочем, сходу кажется, что первое без второго маловероятно. свести к минимум потери пакетов. Путь я вижу один - клонировать пакет и слать его сразу по обеим каналам (при наличии двух каналов) и по 2 из 3, когда появится третий. мультилинк, кмк это балансировка, а не избыточность. а где советовали ? Дайте почитаю, тоже интересно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 16 марта, 2017 (изменено) · Жалоба да, я имел в виду пробросить канал с резервированием/защитой от потерь до какого-то сервера с более надёжным интернетом. Путь я вижу один - клонировать пакет и слать его сразу по обеим каналам (при наличии двух каналов) и по 2 из 3, когда появится третий. звучит бредово, далеко не все любят дублирования пакетов. Изменено 16 марта, 2017 пользователем edo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 16 марта, 2017 · Жалоба Есть задача (пока теоретическая) сделать надежный интернет канал из двух-трех ненадежных. Причем основные технологии фалловера не устраивают, т.к. имеют ненулевое время переключения (даже с BFD). есть какие-либо технологии, позволяющие не потерять ни одного UDP пакета ? Чисто теоретически: Что значит ненадежный? В нем регулярные потери? Или он то работает, то нет? Сколько вам надо времени, чтоб понять, что канал из надежного стал ненадежным? Какие численные показатели вы готовы предъявить к понятию надежности? Не потерять ни одного пакета за какой период? За 10 лет или за 5 минут? И при каком потоке данных? Если уж теоретизировать, то надо это делать от души, по настоящему!!! Даже в незагруженной локалке со 10G оптикой нельзя получить 100%, мы живем в реальном мире. В целом, да, если на канал ставить какое-то специальное оборудование или софт, которые дополнительно энкапсулирует пакеты, посылает несколькими версиями и потоками, на другой стороне собирает, и передает дальше уже в единственной копии - можно сильно повысить надежность. Но достоверно такого софта не знаю. Я помню, было решение от Riverbed, которые эффективно обращаться с трафиком на далеких WAN линках, но вот умели ли железяки решать ваши задачи - не знаю... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 16 марта, 2017 · Жалоба звучит бредово, далеко не все любят дублирования пакетов. так работает резервирование в SDH так работает mofrr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 марта, 2017 · Жалоба Проприетарные подобные штуки видел, чаще всего для передачи multicast-tv. Но нужно понимать, что так или иначе подобная система внесёт задержку Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
veng Опубликовано 17 марта, 2017 · Жалоба Есть задача (пока теоретическая) сделать надежный интернет канал из двух-трех ненадежных. Причем основные технологии фалловера не устраивают, т.к. имеют ненулевое время переключения (даже с BFD). есть какие-либо технологии, позволяющие не потерять ни одного UDP пакета ? Ну если теоретически, можно посмотреть на передачу по SCTP Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
grifin.ru Опубликовано 17 марта, 2017 · Жалоба Есть задача (пока теоретическая) сделать надежный интернет канал из двух-трех ненадежных. Причем основные технологии фалловера не устраивают, т.к. имеют ненулевое время переключения (даже с BFD). есть какие-либо технологии, позволяющие не потерять ни одного UDP пакета ? Ну если теоретически, можно посмотреть на передачу по SCTP Прочитал. Интересный протокол. А как практически реализовать ? Инкапсулировать TCP/UDP в него ? Как ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
veng Опубликовано 17 марта, 2017 (изменено) · Жалоба А как практически реализовать ? Инкапсулировать TCP/UDP в него ? Как ? Я думаю это уже вопрос к сетевым программистам. С т.з. сетевика - это еще один транспортный протокол, только и всего. Если раньше софт отправлял/получал данные выбирая либо UDP либо TCP протокол, то теперь появилась возможность выбрать SCTP протокол. В *BSD системах этот протокол доступен из коробки, в Windows вроде как ставиться драйвер. Протокол доступен также в OSX, а вот насчет linux не знаю, но думаю тоже есть. Это все интересно если писать свое приложение, заморачиваясь надежностью передачи, чтобы "ни один пакет не потерялся". Но если задача чисто теоретически... вот. Как вариант - поставить отдельный шлюз TCP/UDP <-> SCTP и обеспечить чтобы между хостом и шлюзом гарантированно ничего не терялось (например разместить их рядом) по TCP/UDP и все правильно настроить. Изменено 17 марта, 2017 пользователем veng Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 17 марта, 2017 · Жалоба Путь я вижу один - клонировать пакет и слать его сразу по обеим каналам (при наличии двух каналов) и по 2 из 3, когда появится третий. как с packet reordering бороться будете, при разных RTT маршрутов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 17 марта, 2017 · Жалоба Я думаю это уже вопрос к сетевым программистам. С т.з. сетевика - это еще один транспортный протокол, только и всего. Если раньше софт отправлял/получал данные выбирая либо UDP либо TCP протокол, то теперь появилась возможность выбрать SCTP протокол как я понимаю, речь идёт об обычном "доступе в интернет" для клиента, как вы заставите его перейти на sctp?!? как с packet reordering бороться будете, при разных RTT маршрутов? тут надо начинать с того, что пакеты в разные каналы должны уходить с разными src ip. на этом всё и заканчивается. я говорю - идея бредовая. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
grifin.ru Опубликовано 17 марта, 2017 · Жалоба Как вариант - поставить отдельный шлюз TCP/UDP <-> SCTP и обеспечить чтобы между хостом и шлюзом гарантированно ничего не терялось (например разместить их рядом) по TCP/UDP и все правильно настроить. Именно это и интересует. Практический пример такого шлюза существует ? Желательно не на тазике, а на cisco/mikrotk/juniper как с packet reordering бороться будете, при разных RTT маршрутов? Можете считать это частью моего вопроса ) тут надо начинать с того, что пакеты в разные каналы должны уходить с разными src ip. на этом всё и заканчивается. я говорю - идея бредовая. И что ? Они потом могут все собраться там, где интернет надежный, и там уже между собой все порешать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 17 марта, 2017 · Жалоба И что ? Они потом могут все собраться там, где интернет надежный, и там уже между собой все порешать. Так на это время нужно. Допустим первый пакет пришел через 10мс, второй через 1000мс, но пришел. Каким образом считать потерян ли пакет, или нет? Получается надо ждать определенное время, и после его истечения брать пакет из буфера и выдавать дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 17 марта, 2017 · Жалоба Есть задача (пока теоретическая) сделать надежный интернет канал из двух-трех ненадежных. Причем основные технологии фалловера не устраивают, т.к. имеют ненулевое время переключения (даже с BFD). есть какие-либо технологии, позволяющие не потерять ни одного UDP пакета ? Даже на производстве в АСУТП таким на уровне TCP|IP "не заморачиваются". А поверь те там потеря пакета может стоить Лярды причем евро... Для надежности Время сходимости кольца/маршрута стремятся сократить до минимума, а проверка- перезапрос пакета идет на более высоком уровне... http://www.cta.ru/cms/f/443112.pdf Почитайте... Может что то почерпнете :) Но для ваших целей это все равно что пушкой по морю чтобы оно не штормило... И что ? Они потом могут все собраться там, где интернет надежный, и там уже между собой все порешать. Так на это время нужно. Допустим первый пакет пришел через 10мс, второй через 1000мс, но пришел. Каким образом считать потерян ли пакет, или нет? Получается надо ждать определенное время, и после его истечения брать пакет из буфера и выдавать дальше. Ты лучше человеку дай ссылку как на микротике настроить такое резервирование сделать... А так, Пакет имеет Порядковый номер, пришел по одному каналу Пакет с номером 1024, в базе недавних пакетов(пускай хранится 2 секунды) такого номера нету, значит сразу же передать дальше... Если через время пришел пакет по другому каналу с номером 1024, и в базе он выше обозначился- значит можно его отбрасывать :)... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 17 марта, 2017 · Жалоба И что ? Они потом могут все собраться там, где интернет надежный, и там уже между собой все порешать. то есть всё-таки задача "поднять vpn с резервированием линков/перепосылкой потерянных пакетов до узла с нормальным интернетом" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
grifin.ru Опубликовано 17 марта, 2017 · Жалоба Так на это время нужно. Допустим первый пакет пришел через 10мс, второй через 1000мс, но пришел. Каким образом считать потерян ли пакет, или нет? Получается надо ждать определенное время, и после его истечения брать пакет из буфера и выдавать дальше. Как только пришел первый -уже плевать придет второй или нет. Ждать ничего не нужно. Придет - дропнем, не придет - хер с ним. то есть всё-таки задача "поднять vpn с резервированием линков/перепосылкой потерянных пакетов до узла с нормальным интернетом" Можно и так сказать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 17 марта, 2017 · Жалоба И что ? Они потом могут все собраться там, где интернет надежный, и там уже между собой все порешать. то есть всё-таки задача "поднять vpn с резервированием линков/перепосылкой потерянных пакетов до узла с нормальным интернетом" Скажем так, он не знает как это будет выглядить, но он точно знает: Если получится натянуть сервис "Гарантия что каждый пакет достигнет цели то с этого можно и денюшку снять..." Все темы которые я видел это попытка сделать эксклюзивное для сетей Юристов/нотариусов, повысить шифрованность, надежность, безопасность... Просто он заморачивается до мелочей... По факту его клиенты даже не оценят что каждый пакет дойдет до точки. Да и не как не проверят... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 17 марта, 2017 · Жалоба Как только пришел первый -уже плевать придет второй или нет. Ждать ничего не нужно. Придет - дропнем, не придет - хер с ним. пришел первый, пришел третий. второй на первом линке потерялся. сколько ждать второго по второму линку?... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
grifin.ru Опубликовано 17 марта, 2017 · Жалоба пришел первый, пришел третий. второй на первом линке потерялся. сколько ждать второго по второму линку?... До тех пор пока не придет с номер >2 по обоим линкам Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 17 марта, 2017 · Жалоба пришел первый, пришел третий. второй на первом линке потерялся. сколько ждать второго по второму линку?... До тех пор пока не придет с номер >2 по обоим линкам А если в итоге он не пришел? Знаете что такое задержка пакета? Вы вообще изучали протокол TCP? Вот когда изучите и поймете что не совсем нужно переживать и заморачиваться такими мелочами... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h3ll1 Опубликовано 17 марта, 2017 · Жалоба Все МЕТРО комутаторы имеют sub-ms ринг протоколы передачи, что будет вам понадобиться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
grifin.ru Опубликовано 17 марта, 2017 · Жалоба zoro Читайте внимательно и думайте. Если вообще не пришел пакет >2, это значит канал лег. Т.к. >2 это и 3 и 4 и 100500 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
