В прошлом посте про историю RackGrid была одна фраза, за которой прячутся месяцы работы: «полностью переработал бэкенд и логику опроса». Разворачиваю её в серию из семи частей — по одной технической проблеме в каждой. Со стороны задача выглядит просто: устройства подключены к сети, они отвечают на запросы, остаётся собрать ответы и вывести на экран. Начну с допущения, которое рассыпается первым: будто у майнеров есть общий язык. На одной площадке обычно стоят машины разных вендоров, и общаются они по-разному: Antminer — cgminer-протокол поверх голого TCP на порту 4028. Читаешь ответ до закрытия сокета. Whatsminer — тот же порт 4028, но свой протокол, и он шифрованный. Сначала запрашиваешь у устройства токен и соль, считаешь ключ через md5_crypt и SHA-256, шифруешь команду AES-256 в режиме ECB, кодируешь в base64 — и только потом отправляешь. PetBit / ElphaPex — HTTP. Vnish — тоже HTTP, но со своей схемой полей. Плюс у каждого свои единицы хешрейта, свои имена полей и своё представление о том, что считать ошибкой. Решение — реестр провайдеров: каждый класс умеет ровно одно, get_stats(address), и возвращает нормализованный результат. Добавить пятого вендора — это новый класс и одна строчка в реестре, без правок в мониторинге, планировщике и API. Но главное решение не в этом, а в одной детали: Тип провайдера определяется один раз и сохраняется в базе. При первом обнаружении идёт перебор в порядке «от самого быстрого к самому медленному». Дальше устройство опрашивается только своим, уже известным протоколом. Разница между «перебирать 4 протокола на 1000 устройств каждый цикл» и «спросить один» — это разница между системой, которая работает, и системой, которая всегда занята. В следующей части — самое болезненное: почему главный тормоз промышленного мониторинга не медленная сеть, а выключенное устройство. 👉 Живое демо: https://danildanil86660.github.io/RackGridLiveDemo