>Карта составляется на основании чего?
Карта пропускной способности очень простая. в конкреной точке (широта/долгота) измеряется качество сигнала оператора сотовой связи и текущие показтели Rx/Tx для каждого тунеля
>Удалось ли в результате суммировать пропускную способность?
Это основная задача которую решали. Да, удалось.
>Что используется для улучшения приема? Направленные антенны?
Направленные антенны бесполезны на движущемся транспорте.
> Почему вы не воспользовались готовыми решениями, например, mptcp ....?
MPTCP идентифицирует несколько маршрутов за счет наличия у компьютера нескольких адресов. Комбинации этих адресов позволяет сформировать дополнительные маршруты.
Это значит, что на терминирующем сервере, должно быть сотни внешних IP адресов
>… или mlvpn
аналогично
Главное, почему пришлось писать свое решение, и это обозначено в статье, необходимость упреждающего мониторинга каналов ПД оператора сотовой связи и последующей тонкой развесовки каналов.
Нам не удалось найти готовое решение, которое это умеет.
Классический пример: BGP с двумя провайдерами… Вы можете выбрать через какого провайдера отправить пакет, но через какого он вернётся
В нашем случае все гораздо проще. Ответ пишется в тот-же туннель всегда.
Чтобы один сервер агрегации мог обслуживать множество транспортных устройств, каждый туннель на сервере биндится на свой порт.
Для того чтобы маршрутизация работала правильно, есть небольшая хитрость.
Сначала пакеты идущие на определенный порт маркируются средствами iptables
далее уже средствами ip route формируется таблица маршрутизации в зависимости от меток
Автор vtrunkd очень подробно описывает этот момент
смотрите сразу шаг 2
Существующие системы определяют качество канала искусственно нагружая его. В нашем случае это неприемлемо, поскольку отнимает значительную полосу пропускания.
Мы опираемся на первичные признаки качества канала — это метрики оператора сотовой связи и вторичные признаки — локальные метрики туннеля.
Пропускную способностью каждого тоннеля конечно же измеряем, но на основе реально передаваемых данных, без искусственной нагрузки.
Это хороший вопрос.
Решается эта задача достаточно просто.
Демон-агрегатор, который обслуживает передачу трафика по разным туннелям, работает следующим образом.
1. Каждый тоннель обслуживается собственным потоком. Чтение и запись идут последовательно — это основы IP сетей.
2. Соединение части пакетов пришедших по разным туннелям, идут в другом потоке, в который они попадают через промежуточный буфер.
Отвечая на ваш вопрос, программист не заботится о том кто отвечает и кто посылает. он просто последовательно читает и пишет в поток.
Накладные расходы составляют дополнительные 2 байта для каждого пакета, поскольку в каждый пересылаемый пакет включается информация об его очередности и принадлежности к туннелю
Если интересно, могу написать про это большую отдельную статью. Какое железо было выбрано, как оно было смонтировано, какие сложности и проблемы удалось решить, а какие не удалось. Если этот пост наберет хотя-бы два десятка плюсов — сделаю отдельную статью.
Поскольку это заказная разработка, мы серьезно ограничены NDA и детали публиковать не имеем никакой возможности. Если заметили, даже не привели название заказчика. Логика алгоритма достаточно проста, но потребовалось почти полтора года экспериментов, чтобы опытным путем выстроить правильную модель принятия решения.
Главной задачей было суммирование емкости доступных каналов и при этом избежать потери пакетов.
Потерю пакетов удалось свести к минимуму только за счет упреждающих решений. В результате самое простое решение оказалось самым надежным. Устройство составляет карту покрытия сотовиков на пути следования. При приближении транспорта к зоне отсутствия или неуверенного приема, идет упреждающее переключение на более стабильные каналы.
Чем больше ездим — тем точнее карта покрытия. В нашем случае все маршруты статичны и меняются очень редко.
Локального демона, который бы динамически дёргал метрики для route'ов в зависимости от загруженности tx queue у сетевого адаптера (или туннеля) — мне кажется, было бы достаточно
Накопление очереди, и вообще любые локальные метрики интерфейсов — это уже последствия. В нашем случае, если будем смотреть только на них, то словим системные проблемы потери пакетов, ведь если очередь начала расти — со связью что-то не так.
Поэтому, первичными метриками являются показатели качества связи самого оператора, а локальные метрики используются только как обратная связь от автоматической развесовки каналов.
Кто из вас, минусующих автора диванных аналитиков, написал свое хоть немного что-то близкое по сложности?
Человек решил свою задачу так как ему нравится. Поделился с вами своим внутренним миром и получил «а зачем», «а есть же». Чуть ли не «ты дурак, делал то что уже есть»
Семён (@ababo) жму руку. От какой суммы рассматриваешь предложения о работе?
Состав, силуэт, бренд, пол, желаемая цена и кучу всего просто невозможно узнать по фотографии.
Глобальная база всего на свете, с которой можно сравнивать распознанный образец, отчасти решит эту задачу, но и то не полностью.
На этом ролике обозначен подход при котором можно делать очень и очень релевантный поиск www.youtube.com/watch?v=4AyzV9bJ3OE
До последнего думал что сервис digup.me это ваша же разработка. Оказалось нет.
Карта пропускной способности очень простая. в конкреной точке (широта/долгота) измеряется качество сигнала оператора сотовой связи и текущие показтели Rx/Tx для каждого тунеля
>Удалось ли в результате суммировать пропускную способность?
Это основная задача которую решали. Да, удалось.
>Что используется для улучшения приема? Направленные антенны?
Направленные антенны бесполезны на движущемся транспорте.
MPTCP идентифицирует несколько маршрутов за счет наличия у компьютера нескольких адресов. Комбинации этих адресов позволяет сформировать дополнительные маршруты.
Это значит, что на терминирующем сервере, должно быть сотни внешних IP адресов
>… или mlvpn
аналогично
Главное, почему пришлось писать свое решение, и это обозначено в статье, необходимость упреждающего мониторинга каналов ПД оператора сотовой связи и последующей тонкой развесовки каналов.
Нам не удалось найти готовое решение, которое это умеет.
В нашем случае все гораздо проще. Ответ пишется в тот-же туннель всегда.
Чтобы один сервер агрегации мог обслуживать множество транспортных устройств, каждый туннель на сервере биндится на свой порт.
Для того чтобы маршрутизация работала правильно, есть небольшая хитрость.
Сначала пакеты идущие на определенный порт маркируются средствами iptables
далее уже средствами ip route формируется таблица маршрутизации в зависимости от меток
Автор vtrunkd очень подробно описывает этот момент
смотрите сразу шаг 2
Мы опираемся на первичные признаки качества канала — это метрики оператора сотовой связи и вторичные признаки — локальные метрики туннеля.
Пропускную способностью каждого тоннеля конечно же измеряем, но на основе реально передаваемых данных, без искусственной нагрузки.
Решается эта задача достаточно просто.
Демон-агрегатор, который обслуживает передачу трафика по разным туннелям, работает следующим образом.
1. Каждый тоннель обслуживается собственным потоком. Чтение и запись идут последовательно — это основы IP сетей.
2. Соединение части пакетов пришедших по разным туннелям, идут в другом потоке, в который они попадают через промежуточный буфер.
Отвечая на ваш вопрос, программист не заботится о том кто отвечает и кто посылает. он просто последовательно читает и пишет в поток.
2. Пакетов
Имелось в виду плюсы к комментарию, а не статье.
Главной задачей было суммирование емкости доступных каналов и при этом избежать потери пакетов.
Потерю пакетов удалось свести к минимуму только за счет упреждающих решений. В результате самое простое решение оказалось самым надежным. Устройство составляет карту покрытия сотовиков на пути следования. При приближении транспорта к зоне отсутствия или неуверенного приема, идет упреждающее переключение на более стабильные каналы.
Чем больше ездим — тем точнее карта покрытия. В нашем случае все маршруты статичны и меняются очень редко.
Накопление очереди, и вообще любые локальные метрики интерфейсов — это уже последствия. В нашем случае, если будем смотреть только на них, то словим системные проблемы потери пакетов, ведь если очередь начала расти — со связью что-то не так.
Поэтому, первичными метриками являются показатели качества связи самого оператора, а локальные метрики используются только как обратная связь от автоматической развесовки каналов.
Человек решил свою задачу так как ему нравится. Поделился с вами своим внутренним миром и получил «а зачем», «а есть же». Чуть ли не «ты дурак, делал то что уже есть»
Семён (@ababo) жму руку. От какой суммы рассматриваешь предложения о работе?
Глобальная база всего на свете, с которой можно сравнивать распознанный образец, отчасти решит эту задачу, но и то не полностью.
На этом ролике обозначен подход при котором можно делать очень и очень релевантный поиск
www.youtube.com/watch?v=4AyzV9bJ3OE
До последнего думал что сервис digup.me это ваша же разработка. Оказалось нет.
Действительно, искать слова и искать свойства сущности — это вообще разные подходы.
К сожалению почти все магазины, в том числе и гуру ритейла, имеют в основе своего поискового движка — механизм поиска слов.
Быстрый пример
Вот как ищет движок поиска слов
gifts.wikimart.ru/theme/?query=%D0%BC%D1%83%D0%B6%D1%81%D0%BA%D0%B0%D1%8F%20%D0%BF%D1%80%D0%B8%D1%82%D0%B0%D0%BB%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F%20%D0%B7%D0%B5%D0%BB%D0%B5%D0%BD%D0%B0%D1%8F%20%D1%80%D1%83%D0%B1%D0%B0%D1%88%D0%BA%D0%B0
Хотел быстро привести пример того как ищет движок поиска свойств сущности. Пришлось изрядно погуглить но нашел
mm24.com/ap5r
Но есть вопрос. Почему то яндекс.маркет не умеет искать так goo.gl/KluCgH
но при этом
умеет искать так goo.gl/M3ozLb
И что мешает искать вот так goo.gl/ruDTPv
Но есть вопрос. Почему то яндекс.маркет не умеет искать так
но
умеет искать так
А какие-то малоизвестные сервисы взрывают мозг