Segment@tion fault

2021-11-19 02:20:53 Если вы думаете что пинг пол-секунды и 300 килобит - это в наше время редкость и ужас-ужас, то спешу обрадавать - это еще хорошо.

Сегодня имел честь иметь ssh-сессию далеко за полярный круг, где-то там, где уже из Канады в Гренланию пешком вброд ходят.

Пинг - секунда. Скорости - мой модем на 33600 лучше работал. Завершает картину внутресетевой полуглобальный корпоративный RIP, который от такого сходит с ума и держит системы под перманентным ддосом. Открыть/Комментировать

2021-11-17 01:53:58 История рождения PSRT.

Один наш крупный клиент поставил несколько точек в местах весьма отдаленных, где интернеты по 300 килобит, с пингом в пол-секунды и дропом в 30-40%. Огромные пейлоады телеметрии, собираемые с PLC, достигали 1-2 мегабайта (это в msgpack) и естественно ничего быстро не передавалось. Было принято логичное решение - врубить клиенту компрессию и пусть радуется. Телеметрия вообще обычно хорошо компрессируется, ибо в основном состоит из одинаковых названий полей, групп и похожих ID датчиков/тэгов/регистров/устройств, а самих данных не так уж и много. Тот же MessagePack или CBOR легко сжимается еще в 20-30 раз gzip-ом на normal compression.

Тем не менее, компрессия не помогала, было решено плюнуть в ту сторону и копать в другую - оптимизировать Pub/Sub протокол и сервер. Так родился PSRT, потом его сертифицировали в ICANN и получили порт в IANA, потом был релизнут PubSubRT server и клиент получил скорость в 3-4 раза выше, чем имел с MQTT. Но счастлив всё равно не был и пришел к нам с просьбой "оптимизируйте еще что-то".

Мы начали копать в сторону совсем странных решений и протоколов 40-летней давности, которые привыкли работать на нестабильных каналах, чтобы передавать через них основную часть данных, а по PubSub уже доливать какой-то минимум. Наконец получив доступ по ssh в приватное облако на продакшн (это огромная корпорация, где доступ апрувят неделю), я обратил внимание, что данные собственно передаются в разы быстрее, чем по MQTT, и даже быстрее чем по PSRT, что невозможно, сокет - он везде сокет.

Тогда я решил внимательно посмотреть на компрессию. Посмотрел и всё понял - конечно же она не работала... И не работала по простой причине - телеметрия у нас перед отправкой шифруется AES256. И в функции отправки почему-то стояло compress(encrypt(payload)). Что в принципе бесполезно, ибо шифрованные данные компрессии не поддаются.

Вот так случайная ошибка в порядке вызова encrypt-compress родила новый Pub/Sub протокол. Там, наверху, умеют пошутить. Открыть/Комментировать

2021-11-16 22:59:36 Наши инсталляции Открыть/Комментировать

2021-11-14 18:54:06 Открыть/Комментировать

2021-11-12 23:51:52 Этого сразу в дурку, без собеседования Открыть/Комментировать

2021-11-12 19:37:27 ​​И первый публичный анонс нашего pub/sub-сервера. Сервер - PubSubRT, протокол - PSRT (IESG approved, port 2873)

В чем особенности сервера:

1) Минимально простая конфигурация. На производительность влияет только один параметр - data queue. Чем он меньше - тем меньше latency, но клиент может дольше ждать перед отправкой сообщения

2) Работает максимально быстро, даже с большими пейлоадами. И да, latency на хорошей сети редко поднимается выше 0,5 ms (для мелких пейлоадов - в пределах 30-40 микросекунд)

3) Это не "черный ящик". максимальный мониторинг всего, что происходит внутри

4) Жесткое слежение за latency, warnings в логи, как только превышается допустимый параметр

5) Никаких "таблиц подписки" - только b-trees. Клиенты могут задать миллионы подписок на разные топики, но если сообщения не ходят сразу в миллион клиентов бродкастом - сервер этого не замечает.

Latency между паблишером и конкретным подписчиком мы считаем, как время с момента получения от паблишера первого байта OP_PUBLISH и до ухода последнего байта в дата-сокет подписчика

В чем особенности протокола. Основная особенность одна - мы использовали два сокета (на один порт) и отказались от карусели OP-ACK. Аргумент против один: это усложняет написание надежного клиента, впрочем клиенты на Rust и Python уже вполне надежные. Теперь аргументы в пользу:

- В Pub/Sub пуши от сервера приходят только когда вы получаете сообщение. поэтому пусть себе и ходят по выделенному сокету данных

- По сокету управления все операции - атомарные. Карусель OP-ACK на клиенте тоже не нужна, что намного облегчает логику

- Благодаря двум сокетам, сервер может посылать ACK на операции контроля прямо в то время, пока клиент по второму сокету скачивает большой пейлоад

- Внезапно, но есть куча клиентов, которые просто отправляют данные и ни на что не подписываются. В PSRT данные на сервер можно пушить хоть UDP-фреймами, с ACK или без

- Нет retains. На высоконагруженных Pub/Sub от них всё равно рано или поздно отказываются, потому что это обычно операции с диском

- Очень жесткий контроль таймаутов. Дохлый клиент будет с сервера немедленно выброшен. Дохлый сервер будет немедленно переподключен клиентом

- Максимально простой запуск TLS

- Репликация и HA из коробки. В сервере мы ее пока не открывали, но в будущем думаю да. Протокол репликации открыт

- Логическая совместимость с MQTT - те же топики, те же маски

Все это уже работает в продакшне у клиентов. Реальное ускорение с пейлдоадами >10kb на медленных каналах (нестабильный 1Mbit) - в 5-10 раз быстрее, чем MQTT. Наша EVA ICS уже получила поддержку PSRT в дополнение к MQTT, релиз выйдет примерно через месяц.

https://github.com/alttch/psrt Открыть/Комментировать

2021-11-12 05:35:29 Как уже говорил, я много лет занимаюсь, люблю и иногда воюю с MQTT. И было бы странно, если бы мы не сделали свой Pub/Sub сервер, но поскольку задачи у нас иногда очень специфические, а в MQTT много лишнего, и наоборот, того что нужно - нету - то и протокол. О pub/sub сервере и протоколе будет чуть позже, а пока небольшое HOWTO зарегистрировать свой настоящий протокол и порт в IANA.

Поскольку у нас клиенты в основном кровавый ынтырпрайз, решили идти официальным путем. Для регистрации протокола вам не нужен RFC draft, хотя это и плюс.

Процесс регистрации следующий:

- Вы выбираете пустой порт и заполняете форму на сайте IANA. Если вам всё равно какой порт дадут, или порт не нужен - номер не даёте

- Описываете протокол в анкете, чем подробнее - тем лучше. Идеально иметь ссылки на спецификации и примеры использования.

- IANA не занимается рассмотрением протоколов, они только присваивают вам номер. Рассмотрение протоколов идет в IESG (Internet Engineering Steering Group, совет экспертов при ICANN)

Что будет требовать IESG:

- практически нереально получить аппрув протокола без TLS или другого шифрования

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

- четкое описание, почему вы решили сделать свой протокол, чем он лучше других, идеально - рабочую версию (клиент/сервер). причем это реально очень подробно читают и смотрят

- если вы запросили fixed port(s) - IESG очень сильно будет вас допрашивать, почему они вам нужны. тут я ступил/не знал - нужно было сделать простенький discovery, пришлось импровизировать и уговаривать.

- допрос IESG в целом очень подробный, и защита может занять несколько недель.

Но у меня получилось. Теперь 2873 TCP/UDP официально за PSRT (PubSub Realtime Telemetry Protocol). Во всех справочниках и на всех системах.

С чем нашу лавку и поздравляю. Открыть/Комментировать

2021-11-10 01:07:39 ​​Дополненная реальность на службе электриков и прочих сантехников.

Есть у меня дорогая термокамера от Seek, но ей как ни странно довольно сложно пользоваться - в 320х240, да еще и в IR, любой знакомый электрощиток выглядит загадочным.

Но счастье есть - в телефоны стали ставить "дешевые" (150-200$) термокамеры с разрешением до 100х50 точек, при этом AR-софт снимает всё основной, а с термической добавляет только инфу по температуре. Логика есть - если провод нагрет, то достаточно снять с него пару точек, да и соседние тоже будут нагреты плюс-минус автобус.

Не смотря на меньшую точность - такой камерой намного приятнее работать. При таком подходе, при желании даже видно текст на документах. Открыть/Комментировать

2021-11-07 18:48:10 Лучший мануал по установке Android Studio. Из Gentoo Открыть/Комментировать

2021-11-06 05:38:41 А ну, и чтобы совсем смешно было - у Хорватии, например, национальный CRL есть, но не работает. А у Италии его вообще нет. Открыть/Комментировать