Десктопний менеджер для керування до 500 headless-сесіями Cristalix.
Архітектура C7xBotManager. Спрощений огляд реальних модулів; без вигаданих скриншотів.
C7xBotManager — десктопний інструмент для керування багатьма полегшеними клієнтами Cristalix/Minecraft без запуску повноцінної гри для кожного акаунта. Програма відповідає за автентифікацію, стан сесій, проксі та автоматизацію через нативний менеджер і headless runtime на Java.
Я спроєктував архітектуру, реалізував інструменти керування й оптимізував мережеву частину та автоматизацію. На початковому етапі дослідження частини протоколу автентифікації допомагала інша людина. Продукт розповсюджувався з разовою оплатою серед приблизно десяти користувачів.
Найскладніше — не просто встановити з’єднання. Кожен акаунт має власний стан автентифікації, підключення, реалму, черги, проксі й задач автоматизації. Масова дія не повинна перетворювати це на одну глобальну блокувальну операцію.
У десктопному інтерфейсі можна вибрати окремі акаунти або групи й передати дію через локальне API.
Java runtime окремо відстежує життєвий цикл кожного акаунта. Стан підключення й автоматизації доступний для діагностики.
Спільний runtime на Netty/NIO обробляє пакети. У pipeline входять проксі, шифрування, формування пакетів і декодер протоколу.
Перевірки проксі, quarantine, failover та reconnect-політики обробляють збої без перезапуску всієї програми.
Система використовувалася з конфігураціями до 500 одночасних сесій. Це реальний масштаб використання, а не результат синтетичного бенчмарку.
Java-частина використовує спільний NIO runtime, а не окремий процес Minecraft для кожного акаунта. Під час створення сесії налаштовується Netty pipeline з підтримкою SOCKS/HTTP проксі, шифрування, формату пакетів і декодера.
Одна з конкретних проблем виникала на проксованих підключеннях: пріоритетні записи PacketLib могли блокувати event loop Netty, поки proxy pipeline ще встановлювався. Я переніс етап активації на окремий невеликий worker, залишивши запис у канал через механізми Netty.
Інтерфейс працює в нативному застосунку на Go з Win32 і WebView2. Він запускає Java backend і керує ним через локальне API, тому протокол та автоматизація не залежать від рендерингу вікна.
Також реалізував масові операції над акаунтами, логи, діагностику, зашифроване локальне сховище облікових записів та ізольовані профілі збірки й релізу. На Windows використовується нативне вікно й трей, на macOS/Linux — браузерний інтерфейс.
Підключення можуть працювати через HTTP або SOCKS проксі, з перевіркою їхнього стану та переключенням при відмові. Важливо, щоб несправний endpoint не впливав непомітно на інші сесії.
Поверх транспорту працюють перемикання реалмів, обробка черг, навігація та автоматизація данжів. Логіка використовує фактичний стан сервера, а не емуляцію візуальних натискань.
Програма мала приблизно десять платних користувачів і підтримувала конфігурації до 500 активних клієнтів. Я розвивав її і як мережевий runtime, і як десктопний інструмент.
Підтримка сумісності протоколу також стала частиною розробки: після змін зовнішнього сервісу потрібно адаптувати пакети, автентифікацію та переходи станів.