Что умеет SIGNAL

Система — это две независимые части: бэкенд и клиент. Они общаются только через REST API. Это не монолит — если упадёт API, лаунчер сохранит последний закэшированный конфиг и продолжит показывать серверы (без истории и без онлайна реального времени).

┌─────────────────────┐       HTTPS / REST       ┌──────────────────────────────┐
│  Avalonia Launcher  │ ◄────────────────────►   │      CDN + WAAP (edge)       │
│    (.NET 10, Win)   │   (TLS termination,      │   DDoS / Bot Management      │
└─────────────────────┘    кэш статики)          └──────────────────────────────┘
                                                            │
                                                            │ origin-pull HTTP, whitelist IP
                                                            ▼
                                          ┌──────────────────────────────────────┐
                                          │       nginx → Node.js cluster        │
                                          │   signal-api + signal-music сервисы  │
                                          └──────────────────────────────────────┘
                                                            │
                                                            │ UDP A2S (централизованный опрос)
                                                            ▼
                                          ┌──────────────────────────────────────┐
                                          │          DayZ серверы                │
                                          │         (любые IP:порт)              │
                                          └──────────────────────────────────────┘
                                                            │ read / write
                                                            ▼
                                          ┌──────────────────────────────────────┐
                                          │  локальные SQLite (WAL) + JSON-конфиг │
                                          │   аккаунты / история / отзывы / музыка│
                                          └──────────────────────────────────────┘

Node.js однопоточный, но на VPS несколько ядер. Бэкенд работает в cluster-режиме: master поднимает воркеров, каждый — полноценный Express-сервер. Под общим nginx живут два сервиса: основной API (signal-api) и музыкальный модуль (signal-music) — у каждого свои воркеры, чтобы тяжёлые операции одного не блокировали другой. При падении воркера master автоматически поднимает новый — zero downtime при любом краше.

Последовательность при первом запуске и при каждом последующем:

• Проверка обновления — лаунчер сравнивает свою версию с launcher_version из конфига. Если есть новее — показывает уведомление, скачивает инсталлятор по updateUrl.
• Загрузка конфига — GET /api/launcher-config возвращает весь список серверов, premium-проекты и настройки. Кэшируется локально на случай офлайна.
• Получение онлайна — лаунчер запрашивает актуальный кэш онлайна через GET /api/servers/global. Данные уже готовы — кластер обновляет их в фоне каждые 10 минут, без нагрузки на клиента.
• Восстановление сессии — если в хранилище есть JWT-токен, лаунчер делает GET /api/auth/me и проверяет его валидность. Если токен протух — просит залогиниться снова.

Это не случайность. У каждой базы свой паттерн нагрузки: пользовательская база читается при каждом логине, история — пишется пачками каждые 10 минут и редко читается, отзывы — случайные записи и частые чтения. Если держать всё в одной базе, WAL-журнал будет общим — пачки INSERT в историю будут блокировать чтение пользователей. Разделение устраняет это.

В системе два типа привилегированных пользователей. Ключевой момент: у них разные JWT-секреты и разные middleware для проверки. Это сделано намеренно — токен admin'а физически не пройдёт через middleware владельца и наоборот. Никакой логики "если есть role=admin, то пропустить везде" — нет.

Steam авторизация сделана через Passport.js + Steam OpenID. Важно: она используется только чтобы привязать отзыв к реальному Steam-аккаунту. Войти в личный кабинет через Steam нельзя — это другая система.

После коллбэка сессия содержит req.user.id (Steam ID64) и req.user.displayName. При следующем POST /api/reviews этот Steam ID привязывается к отзыву. Steam ID публичен сам по себе — мы не получаем ничего, что пользователь не мог бы узнать самостоятельно.

Лаунчер хранит JWT в защищённом локальном хранилище. При каждом запуске проверяет токен через GET /api/auth/me. Если сервер вернул 401 — токен инвалидирован, показывает экран логина. Refresh-токенов нет — по истечении срока — повторный логин. Это сделано намеренно: меньше сложности, меньше векторов атаки.

Весь A2S-опрос вынесен на централизованный Node.js кластер — и это не случайность. Во-первых, защита от DDoS: если бы каждый клиент сам слал UDP-пакеты, любой сервер мог бы оказаться под распределённым флудом от тысяч лаунчеров одновременно. Во-вторых, обход клиентских файрволов: многие провайдеры режут исходящий UDP-спам — пользователь просто не получил бы онлайн. Лаунчер избавлен от этих проблем: он запрашивает готовый кэш по HTTPS REST и получает данные всегда, независимо от настроек сети.

Steam Web API для этих задач не подходит — rate limit в несколько тысяч запросов в сутки при 50+ серверах с обновлением каждые минуты физически невозможен. Плюс задержка данных 1–5 минут делает его бесполезным для отображения живого онлайна.

A2S (Source Engine Query Protocol) — UDP-протокол, который поддерживает любой Source-движок, включая DayZ. Кластер отправляет запрос на query-порт сервера (игровой порт + 1, это стандарт Source Engine), получает ответ за <50ms и парсит бинарный ответ по спецификации протокола. Сервер может ответить challenge — это стандартная анти-спуф защита протокола, кластер обрабатывает её автоматически.

Если за 5 секунд ответа нет — сервер считается оффлайн. Весь цикл по всем серверам идёт параллельно через Promise.allSettled, что означает: падение одного сервера не задерживает опрос остальных.

Используется гибридная модель. Список активных модов сервера приходит с бэкенда в составе конфига — кластер извлекает его из A2S-ответа (DayZ кладёт Workshop ID модов в поле keywords/gametype, это официальное поведение игры). Локальная валидация кэша и путей идёт строго через нативный steam_api64.dll по интерфейсу SteamUGC — именно он отвечает за проверку установленных Workshop-предметов без лишних запросов к Steam Web API.

Каждый воркер держит несколько объектов в памяти — чтобы не лезть в файл или базу на каждый запрос:

let configCache           = null;  // конфиг серверов — читается с диска при первом запросе
let adminsConfig          = null;  // конфиг администраторов
let globalServerListCache = [];    // последний A2S-результат по всем серверам
let modUpdateCache        = {};    // { 'ip:port': { mods: [], ts: Date } }
let premiumModsCache      = {};    // то же для premium-серверов

globalServerListCache — это последний известный статус всех серверов (онлайн, слоты). Лаунчер получает его вместе с конфигом в одном ответе. Обновляется фоновым циклом — лаунчер никогда не ждёт свежего A2S от сервера, он всегда получает последний закэшированный результат.

• Берёт полный список серверов из configCache
• Параллельно опрашивает все серверы по UDP через Promise.allSettled
• Обновляет globalServerListCache актуальными данными
• Пишет снепшот в историю пачечным INSERT — одна транзакция на все серверы
• Если Super Premium сервер был онлайн → стал оффлайн → стреляет в Discord webhook

История не чистится автоматически — это намеренно. Старые данные (старше 90 дней) просто не показываются на графике, но хранятся. Можно добавить VACUUM по расписанию если база вырастет до неприемлемого размера.

Прямых рекуррентных списаний с карты нет. Владелец пополняет внутренний баланс (число в рублях в пользовательской БД), затем сам активирует или продлевает подписку — средства списываются с баланса. Плюсы этой модели:

• Не нужна согласованность платёжных систем на рекуррентные списания
• Возврат = просто увеличить баланс, не нужна операция возврата у провайдера
• Пользователь сам контролирует когда платит — нет неожиданных списаний
• Одна модель работает для всех способов оплаты (Robokassa, Альфа-эквайринг, ручная корректировка)

const PLAN_PRICES = {
  basic: 2000,  // ₽/мес
  super: 5000,  // ₽/мес
};
const EXTRA_SERVER_PRICE = 500; // ₽/мес за каждый сервер сверх первого

function calcPrice(plan, days, serverCount = 1) {
  const base    = PLAN_PRICES[plan] * days / 30;
  const extra   = Math.max(0, serverCount - 1) * EXTRA_SERVER_PRICE * days / 30;
  return Math.round(base + extra);
}

Платёжный провайдер присылает webhook при успешном платеже. Сервер:

• Проверяет HMAC-подпись запроса — без этого любой мог бы сфейкать пополнение
• Проверяет что платёж с таким ID ещё не обработан (идемпотентность)
• Добавляет сумму к балансу владельца в БД
• Логирует транзакцию с временной меткой и ID платежа

Пользователь запускает не сам лаунчер, а отдельную лёгкую программу-апдейтер — это единственная и неизменная точка входа. Апдейтер проверяет наличие новой версии, при необходимости докачивает её и затем запускает лаунчер. Разделение даёт два эффекта: обновление происходит до старта основного приложения (не нужно перезапускаться «на лету»), и стабильная точка входа со временем накапливает доверие в механизмах репутации ОС.

Лаунчер собирается под Windows как single-file .exe с обфускацией коммерческим инструментом класса code-protector. Это означает:

• Имена классов, методов и полей в скомпилированной сборке переименованы в случайные последовательности — декомпилятор показывает кашу, не читабельную бизнес-логику.
• Строковые константы (URL, идентификаторы, маркеры) зашифрованы и расшифровываются только в рантайме перед использованием.
• Поток управления (control flow) переплетён — статический анализ путей выполнения сильно затруднён.
• Проверки целостности — модификация защищённой сборки обнаруживается, и подменённый код отказывается выполняться.

Цель защиты — не сделать reverse engineering невозможным (это недостижимо), а сделать его экономически нецелесообразным. Раскрутить хорошо обфусцированный .NET-бинарь до уровня «понять архитектуру и достать ключи» — это часы-дни ручной работы специалиста, а не пара минут в dnSpy.

Каждый лаунчер при первом запуске генерирует UUID (device_id) и хранит его локально. Этот ID отправляется с каждым отзывом. Сервер проверяет: если device_id уже оставил отзыв на этот сервер — дубль отклоняется. Одно устройство = один голос.

Привязка к Steam-аккаунту (Steam ID64) добавляет второй, более сильный слой проверки поверх device_id. Оба механизма работают параллельно, плюс серверная модерация и баны. Точное распределение весов между сигналами намеренно не публикуется.

На эндпоинтах логина и регистрации стоит rate limiter по IP. Это стандартная защита от брутфорса — после N попыток за окно времени IP получает 429. bcrypt с cost 12 добавляет ещё один барьер: даже при пропуске rate limit'а каждая проверка занимает ~250ms.

На публичных эндпоинтах (конфиг, отзывы) rate limiting мягче — защита от парсеров, не от пользователей.

Загрузка через multer с ограничениями: только изображения по MIME-типу, ограничение размера. Файлы сохраняются в директорию /uploads/ с рандомным именем — имя оригинального файла игнорируется, чтобы не было path traversal. Старый файл удаляется при загрузке нового.

• Не модифицирует и не читает файлы DayZ или Steam
• Не вмешивается в анти-чит (BattlEye и VAC работают независимо)
• Не хранит пароль Steam — авторизация через официальный OpenID, пароль до нас не доходит
• Не собирает данные об установленных программах или системе
• Не делает запросы в фоне когда лаунчер закрыт

S1 — это комплексный профиль системных твиков, который применяется в момент запуска игры и полностью откатывается при выходе. Все изменения идут через официальные Windows API — никакой правки игровых файлов, никакого вмешательства в анти-чит.

Пока DayZ запущен, лаунчер уходит на второй план и отдаёт ресурсы игре:

Плазма — это процедурно-анимированный фон на базе SkSL-шейдера. Несколько слоёв синус-волн с разными частотами, фазами и скоростями складываются в органичное плавное движение. Цветовая схема и скорость — настраиваемые параметры в разделе Style.

Рендерится на GPU через Avalonia Skia backend, анимация идёт в составе кадрового цикла Avalonia. Нагрузка на CPU минимальна; для слабых машин и работы от батареи плазму можно полностью отключить (см. ниже).

В режиме энергосбережения (опция в настройках) плазма отключается полностью и фон становится статичным — для слабых машин или ноутбука на батарее.