# RDP FIDO — что нового Клиент и шлюз обновляются вместе: клиент предлагает новую версию при запуске, шлюз обновляется из клиента после сессии, подтверждённой ключом (галочка «Автоматически обновлять шлюз на этой машине»). Скачать: [RdpFido-Setup.exe](https://accounts.new-imobile.com/updates/RdpFido-Setup.exe) (хост или клиент), [RdpFidoClient-Setup.msi](https://accounts.new-imobile.com/updates/RdpFidoClient-Setup.msi), [RdpFidoGate-Setup.msi](https://accounts.new-imobile.com/updates/RdpFidoGate-Setup.msi). English: [CHANGELOG.en.md](CHANGELOG.en.md). ## 1.22.0 — 28.09.2026 - **RDP FIDO Cloud в клиенте: подключение к шлюзу за NAT без пробросов.** Шлюз, привязанный к облаку, получает адрес вида `.g.<домен>` (порт 443) — его вводят как адрес сервера и шлюза, всё остальное как раньше: тот же ключ, тот же закреплённый отпечаток сертификата, та же проверка. Через облако шлюз вместо правила брандмауэра выдаёт билет туннеля на окно доступа, и клиент проводит RDP через хаб: слушатель на `127.0.0.1`, `mstsc` (на Linux — xfreerdp) подключается к нему, а байты идут к хабу в зашифрованных записях (ECDH + AES-256-GCM поверх TLS и NLA самого RDP). Хаб видит только адреса и объёмы. Туннель живёт, пока открыто окно RDP; слушатель держится всё время жизни билета и принимает до четырёх подключений тем же билетом — `mstsc` разрывает соединение и подключается заново после своих диалогов и при автопереподключении (хаб и шлюз считают использования, шлюз к тому же требует адрес, которому билет выдан). Шлюз сообщает в `auth/finish` отпечаток сертификата своего RDP-слушателя (`rdpCertSha256`, `rdpCertSha1`), и клиент перед запуском `mstsc` закрепляет его для `127.0.0.1` (`HKCU\…\Terminal Server Client\Servers\127.0.0.1\CertHash` — то, что пишет галочка «больше не спрашивать»): вопрос о подлинности не появляется, `authentication level` остаётся 2; Linux-клиент передаёт xfreerdp `/cert:fingerprint:sha256:…`. В статусе и на плитке — «через облако»; в диалоге сессии — подсказка про адрес и публичное имя шлюза при проверке. - Клиент называет свою версию в запросах к шлюзу (`clientVersion`); шлюз через облако отвечает понятным сообщением клиенту старше 1.22 (`client_too_old`) и когда его связь с облаком сейчас разорвана (`cloud_unavailable`). - Без облака (шлюз не привязан, ответ без `tunnel`) клиент работает ровно как 1.21. - **Облако как опция — сторона шлюза.** Шлюз можно привязать к хабу RDP FIDO Cloud (своему `rdpfido-cloud` или облаку Imobile): `RdpFidoGate.exe cloud link ХАБ КОД` (Linux: `rdpfido-gate cloud link`), `cloud unlink`, `cloud status`. Пока не привязан, шлюз не делает ни одного исходящего соединения и работает ровно как раньше. Привязанный держит одно соединение к хабу с переподключением (1 → 60 с) и принимает через него HTTPS клиентов в свой же слушатель, подставляя настоящий адрес клиента (страны, лимиты, привязка challenge к адресу — как обычно). RDP через облако открывается **не правилом брандмауэра, а билетом туннеля** на окно доступа (до четырёх подключений, только с адреса клиента): ответ `auth/finish` несёт `tunnel`, порт 3389 снаружи закрыт как и был. `/v1/hello` сообщает `cloud {linked, connected, publicHost, publicPort}`, реле хаба добавляются к своим в `stream/open`. Клиентам старше 1.22 через облако шлюз отвечает `client_too_old`; при отвалившемся соединении с хабом — `cloud_unavailable` (503). Состояние — в `cloud-state.json`. `RdpFidoGate.exe cloud selftest` гоняет протокол на встроенном макете хаба (Windows и Linux). - **Облако Imobile — закрытый сервис.** В 1.22.0 облачный режим работает с вашим собственным хабом `rdpfido-cloud` (self-hosted: бинарь, юнит и `install.sh` — в архиве `rdpfido-cloud-1.22.0-linux-x86_64.tar.gz` рядом с Linux-пакетами, описание — `README-cloud.ru.md`) или с облаком Imobile. Облако Imobile не открывается всем: шлюз к нему подключает Imobile по договорённости, а для знакомства наружу даётся демо-доступ для подключения (демо-машины через облако). Без привязки к хабу шлюз и клиент работают как раньше. - **Облако:** кабинет хаба `rdpfido-cloud` — организации, участники, роли, права «участник → шлюз» с условиями (дни, часы, страны, срок), подписанные манифесты прав для шлюзов, журнал, веб-интерфейс на `adminPort` и JSON-API; вход через учётную запись Imobile или свои логины (`rdpfido-cloud user`). См. `docs/CLOUD-CABINET.md`. - **Совместный доступ к потоку — сторона зрителя.** К одному сеансу FIDO Stream подключаются несколько участников, управляет один. Вьювер показывает, у кого управление (подсказка в углу при каждой смене), а пока оно не у вас — плашку «Только просмотр — Ctrl+Alt+R: запросить управление» и ничего не отправляет хосту; мышь над картинкой становится указкой, которую видят все (кружок с именем, свой цвет у каждого). Ведущему на запрос всплывает «<имя> просит управление: Передать (Enter) / Отклонить (Esc)», через 30 с без ответа — отказ. В меню сеанса: «Участники…», «Запросить управление», «Передать управление ▸ <имя>», «Вернуть управление хосту», «Пригласить…» (код регистрации для гостя с ролью «сможет вести» или «только смотреть», с адресом шлюза и сроком, кнопка «Копировать»). Оверлей (Ctrl+Alt+O) показывает `participants: N, control: <имя>`. На Linux то же клавишами: Ctrl+Alt+R, Ctrl+Alt+Shift+P/H/I, Enter/Esc; `rdpfido stream` печатает события участников. Со стороной 1.21 всё как раньше. - Клиент передаёт в `stream/open` `share: true` и `role: lead` и отдаёт вьюверу `participant`/`inviteToken` из ответа; от шлюза 1.21 их нет — и вьювер ведёт себя как прежде. - Для проверки без хоста 1.22: `RdpFidoViewer.exe … --demo-share` / `rdpfido-viewer … --demo-share` (или `RDPFIDO_VIEWER_DEMO_SHARE=1`) разыгрывают общий сеанс из трёх участников. - **Совместный доступ в FIDO Stream.** К одному экрану подключаются несколько участников (до 8, по умолчанию 4), управляет ровно один: первый подключившийся с правом «управлять» — ведущий, остальные смотрят, слушают и водят указкой; зритель просит управление, ведущий передаёт или отклоняет (без ответа за 30 с запрос гаснет); человек за хостом забирает управление сочетанием Ctrl+Alt+Shift+H, а `RdpFidoGate.exe stream control host|` назначает ведущего принудительно. Ввод, буфер обмена, файлы, микрофон и настройки качества принимаются только от ведущего — на хосте, а не в окне клиента. Кадр захватывается и кодируется один раз; у каждого участника свои ключи, порт и правило брандмауэра. Ведущий отключился — управление у хоста или у первого в очереди (`"streamLeaderLeft"`); вернувшийся ведущий получает его обратно. - **Приглашение на лету.** Ведущий создаёт код приглашения на 15 минут (`/v1/stream/invite`); гость регистрирует ключ этим кодом и получает роль «смотреть» или «управлять» и срок действия (по умолчанию 8 часов), после которого шлюз удаляет ключ сам. Роль есть и у обычных ключей: `key-role <номер|метка> lead|watch`, `keys` показывает её. - Шлюз: `"streamShared"`, `"streamMaxParticipants"`, `"streamLeaderLeft"`, `"inviteTtlSeconds"` в `gate.json`; `stream participants`; UDP-порты потока — базовый..базовый+7 (было +3). Ответ `stream/open` несёт `participant` и `inviteToken`. Сторона 1.21 работает как раньше. ## 1.21.0 — вошла в 1.22.0 (отдельно не выпускалась) - **Передача файлов в FIDO Stream, в обе стороны и между разными ОС.** Перетащите файлы или папки в окно потока — они окажутся на хосте в «Загрузки\RDP FIDO» (на Linux — `~/Загрузки/RDP FIDO`, по XDG). То же в меню сеанса: «Отправить файлы на хост…». Обратно: всё, что положить на хосте в `Загрузки\RDP FIDO\Outbox`, приезжает на ваш компьютер в ту же папку «RDP FIDO», а на хосте переезжает в `Outbox\Sent`. Windows↔Linux в любых сочетаниях: имена в UTF-8, пути с любыми разделителями, время изменения сохраняется, бит исполнения — на Linux. - **Передача не мешает работе.** Файлы идут третьим надёжным каналом потока, который отправляется только когда не ждут ни видео, ни звук, ни ввод, и со своим ограничением скорости: регулятор поднимает её, пока задержка на пути не растёт, и режет вдвое, как только растёт — раньше, чем это заметит регулятор видео. Картинка и отклик остаются прежними, файл берёт остаток полосы; на локальной сети — десятки мегабайт в секунду. Ход передачи виден в заголовке окна и в меню (там же «Отменить передачу файлов»); каждый законченный файл объявляется подсказкой. - **Защита.** Файлы попадают только в папку «RDP FIDO»: имена очищаются (`..`, диски, запрещённые символы, имена устройств), совпадения получают суффикс «(2)». Хост может запретить файлы целиком: `"streamFiles": false` в `gate.json` (на вьювере — `--no-files`). Пока файл не дошёл целиком, он лежит рядом как `.part` и удаляется при обрыве. - Со сторонами версии 1.20 поток работает как раньше, просто без файлов (клиент сообщит «хост не принимает файлы»). ## 1.20.0 — 26.09.2026 - **RDP FIDO для Linux.** Шлюз `rdpfido-gate` для Ubuntu, Astra Linux и РЕД ОС: закрывает порт xrdp своими правилами nftables (или iptables, если nftables нет) для IPv4 и IPv6 и открывает его только адресу, прошедшему проверку FIDO-ключом, — те же проверки и тот же протокол, что у шлюза для Windows. `sudo rdpfido-gate setup` делает всё сразу: сертификат, служба, xrdp стартует только после шлюза, порты в ufw/firewalld, код регистрации. - **Клиент для Linux**: окно `rdpfido-gui` и командная строка `rdpfido`. Ключи — любые FIDO2 USB/NFC (через libfido2), подключение — FreeRDP, пароли — в связке ключей рабочего стола. Подключается к шлюзам на Windows и на Linux. - **С Windows на Linux.** Windows-клиент сам узнаёт, что на той стороне xrdp, и подключает mstsc без NLA (xrdp её не умеет; TLS остаётся), не пытаясь обновить Linux-шлюз файлом для Windows. - **Исправлено (важно для безопасности, касается и шлюза на Windows).** Ключ, удалённый командой `remove-key`, продолжал открывать порт до перезапуска службы, а при следующем использовании любого ключа служба записывала его обратно в список. Теперь удаление действует сразу. Обновите шлюз. - **Исправлено (касается и шлюза на Windows).** Две одновременные авторизации с одного адреса могли оставить правило брандмауэра, которое никто не отслеживал и которое поэтому не закрывалось до перезапуска службы. Теперь такого не бывает — проверено нагрузкой до 150 авторизаций в секунду. - Linux-шлюз закрывает порт RDP уже при загрузке, до сети и до xrdp; если это не удалось, xrdp не запускается. Порт 3389 в ufw/firewalld открывается только под защитой шлюза, а `uninstall` возвращает ufw/firewalld в прежнее состояние. - Регистрация ключа с Linux-клиента может сразу сверить отпечаток шлюза (`rdpfido enroll … --fingerprint`, поле в окне) — код регистрации не уйдёт подставному серверу. - Шлюз (и на Windows): служба и командная строка больше не могут одновременно переписать `gate.json` и потерять изменения друг друга. - **FIDO Stream на Linux — в обе стороны.** Linux-машина может отдавать свой рабочий стол потоком (агент в пакете шлюза: захват X11, H.264, звук, ввод, геймпады) и смотреть поток с Windows или Linux (`rdpfido stream`, кнопка «Поток» в окне, `rdpfido-viewer`). Windows-клиент открывает поток на Linux-машину так же, как на Windows. Порты потока открываются только адресу, подтвердившему вход ключом. Подробности — [LINUX.md](LINUX.md). - **Срок работы без обновления — один год.** Каждая версия работает год с даты выпуска, затем требует обновления. Клиент перестаёт подключаться: Windows-клиент сам скачивает и ставит новую версию, Linux-клиент называет команду обновления пакета. Шлюз по-прежнему проверяет ключ, но не открывает доступ, пока его не обновят: Windows-клиент при этом сразу отправляет шлюзу новую версию и подключается снова, Linux-шлюз обновляется пакетом (команда — в сообщении и в `status`). За 30 дней до срока — предупреждения. Перевод часов назад срок не продлевает. Регистрация ключей и аварийный `unlock` работают и после срока. - Клиент для Windows больше не считает повреждённым список сессий, сохранённый с меткой BOM (PowerShell, старый «Блокнот»). ## 1.19.3 — 20.09.2026 - **Больше нет ложного «ПОСТОРОННИЙ ДОСТУП К RDP!» за пробросом порта.** Раз в минуту клиент проверяет, что порт RDP не отвечает без ключа. Если хост доступен через проброс (netsh portproxy, SSH- или программный релей, некоторые роутеры), соединение принимает сам проброс, и проверка поднимала красную тревогу, хотя порт RDP за ним был закрыт. Теперь клиент считает порт открытым, только получив настоящий ответ RDP на начало сеанса. Порт, который действительно открыт без ключа, по-прежнему вызывает тревогу. Меняется только клиент, шлюз обновлять не нужно. ## 1.19.2 — 20.09.2026 - **Меню сеанса вернулось — и всё остальное, что потеряла 1.19.** 1.19.0 и 1.19.1 были собраны из линии разработки, в которую не попали четыре более ранних выпуска, поэтому обновление до 1.19 молча убрало: меню в окне потока (Ctrl+Alt+Shift+M) и его горячие клавиши, панель у верхнего края в полном экране, Ctrl+Alt+Del на хост, исправления положения указателя, «разрешение хоста по моему экрану» и исправление шлюза, из-за которого подключение потока открывало RDP-порт. Всё это возвращено вместе со всем, что добавила 1.19 (точная частота монитора, оверлей метрик, AV1 / 10 бит / HDR, Opus, реле, геймпад). - **Обновите и шлюз.** Две линии заняли одни и те же два внутренних номера сообщений под разное. С клиентом 1.19.0–1.19.1 и шлюзом 1.18.1 подключение нажимало на хосте Ctrl+Alt+Del и раз в секунду просило сменить видеорежим. В 1.19.2 оба номера выведены из оборота; пока обе стороны не станут 1.19.2, поток работает с возможностями 1.18 (без AV1, 10 бит, HDR и точной частоты) — и ничего хуже. - Выпуски теперь проверяются взглядом на само окно потока — тестовая таблица должна прийти неперевёрнутой и в цвете, меню должно открыться, — а скрипт публикации отказывается собирать из дерева, где нет чего-либо выпущенного раньше. ## 1.19.1 — 20.09.2026 - **FIDO Stream показывал чёрное окно.** Сессия подключалась, заголовок окна и оверлей сообщали нормальную частоту кадров, но сама картинка оставалась чёрной — на любой машине, с любым кодеком и настройками качества: вьювер отбрасывал прямоугольник с видео ещё до отрисовки. Исправлено; вместе с ним снова виден и удалённый указатель мыши. Меняется только клиент — шлюз ради этого обновлять не нужно. ## 1.19.0 — 16.09.2026 - **120 / 144 / 240 Гц.** Поток идёт с точной частотой вашего монитора (143,856 Гц так и остаются 143,856, а не 144): хост захватывает и кодирует в этом ритме по таймеру с субмиллисекундной точностью, а вьювер показывает кадр либо сразу после декодирования («Сразу»: минимальная задержка, разрешён разрыв), либо на следующем обновлении экрана («Плавно»: без разрывов и повторов). «Автоматически» выбирает «Плавно», когда частота потока совпадает с частотой монитора. Мышь передаётся событие за событием с её собственной частотой опроса (1000 Гц включительно); события, скопившиеся пока окно было занято, объединяются без добавления задержки. Программные кодеры ограничены 60 к/с. - **Оверлей метрик и трасса.** Ctrl+Alt+O показывает, на что уходит каждая миллисекунда: захват, преобразование, кодирование, сеть и сборка, декодирование, ожидание обновления экрана, показ; битрейт, потери, доля FEC и восстановления, NACK, RTT, задержка в очереди, размер датаграммы, реле; частота и дрожание показа; оценка «клик → фотон» — клики и нажатия помечаются, и ищется первый кадр, захваченный хостом после их ввода (время отклика самого монитора не входит). Ctrl+Alt+T пишет CSV-трассу (строка на кадр со всеми отметками времени, строка в секунду со счётчиками канала, строка на событие) в `%LOCALAPPDATA%\RdpFidoClient\traces`; сессия может стартовать с включённым оверлеем или записью трассы. - **AV1, 10 бит, 4:4:4 и HDR.** Новые настройки сессии «Кодек» (авто / H.264 / HEVC / AV1) и «Цвет» (авто / 8 бит / 10 бит / 4:4:4 / HDR). AV1 кодируется на NVENC (RTX 40) и на AV1-кодерах Intel Arc и AMD RDNA3, декодируется на NVDEC или аппаратном декодере. 10-битные HEVC/AV1 убирают полосы в градиентах; 4:4:4 сохраняет чёткость тонкого текста. При включённом HDR в Windows на хосте и HDR-мониторе у клиента рабочий стол дублируется в FP16, на видеокарте переводится в 10-битный PQ BT.2020 и показывается как HDR (на SDR-мониторе — с тон-мэппингом). Всё автоматически понижается до того, что умеют обе стороны; «Автоматически» берёт AV1 или HEVC, когда узкое место — канал, и H.264, когда — компьютеры. - **Звук Opus.** Звук хоста передаётся Opus 128 кбит/с (режим restricted low delay, кадры 10 мс), микрофон — 48 кбит/с; потерянный пакет восстанавливается из встроенного FEC следующего. libopus 1.5.2 (BSD-3) собран внутрь исполняемых файлов; старые версии остаются на ADPCM. - **Реле для симметричных NAT.** Когда напрямую не достучаться ни до одной стороны, поток идёт через ваше реле: `rdpfido-relay` для Linux-VPS (`src/relay`, `make install`, systemd-юнит) или `RdpFidoGate.exe relay serve` на Windows. Реле перечисляются в `gate.json` шлюза (`"streamRelays": [{"address": "relay.example.com:7443", "name": "eu-1"}]`); обе стороны пробуют их и берут ближайшее, дав прямым путям фору 1,5 с. Реле пересылает только сквозно зашифрованные датаграммы и ключей не имеет. - **Настройка для WAN.** Контроль перегрузки масштабирует пороги задержки по базовому RTT (12 мс в локальной сети, до 50 мс через континенты), бюджет на восстановление растёт с RTT, FEC — на длинных путях. MTU discovery поднимает датаграмму с 1200 до 1472 байт, когда путь это выдерживает (меньше, но крупнее шардов), перепроверяя каждые 30 с и откатываясь при смене пути. - Совместимо по протоколу с 1.15–1.18: старые версии игнорируют новые сообщения. ## 1.18.1 — 13.09.2026 - **Подключение FIDO Stream больше не открывает RDP-порт.** Авторизация потока заодно открывала разрешение на RDP, которым поток не пользуется; недожившее RDP-соединение могло удерживать его открытым, и клиент рисовал на плитке ложную тревогу «RDP открыт всем». - **Разрешение хоста по вашему экрану** (выключено по умолчанию; галочка в параметрах сессии и пункт в меню сеанса): хост переключается в режим вашего монитора или в наибольший с теми же пропорциями и возвращает прежний по окончании сеанса. ## 1.18.0 — 16.09.2026 - **Геймпад в FIDO Stream.** Подключите XInput-геймпад (Xbox One/Series, Xbox 360, большинство геймпадов с переключателем «X») к клиенту: на хосте он появляется как контроллер Xbox 360, игра ничего не замечает, вибрация возвращается на ваш геймпад. До четырёх геймпадов на сессию. Как и клавиатура, геймпад управляет хостом только пока окно потока впереди. - **На основе ViGEmBus.** Виртуальный контроллер — открытый драйвер ViGEmBus от Nefarius Software Solutions (лицензия BSD-3), тот же, на котором работают Sunshine, Apollo и DS4Windows. Проект архивирован в конце 2023 года; его последний выпуск (драйвер 1.21.442.0, подпись Microsoft/WHQL) ставится на текущие сборки Windows 10/11 x64 без тестового режима и с включённым HVCI. Пакет вшит в `RdpFidoGate.exe`: `setup` его устанавливает, шлюз, обновлённый на месте, ставит его при следующем запуске службы, а `uninstall` удаляет только драйвер, который поставил этот шлюз — ViGEmBus, принесённый другой программой, остаётся. `RdpFidoGate.exe gamepad status|install|remove` управляет им; `RdpFidoGate.exe stream gamepad-test` проверяет весь путь на хосте (подключение, XInput его видит, вибрация возвращается, отключение) без вьювера. Если драйвер поставить не удалось, шлюз и поток работают, просто геймпад на этом хосте ничего не делает. - Оба установщика кладут рядом с программой `THIRD-PARTY-LICENSES.txt` (ViGEmBus, заголовки ViGEmClient, заголовки кодеков NVIDIA). - `gate.json`, сохранённый с меткой порядка байтов UTF-8 (Блокнот, Windows PowerShell), больше не останавливает службу; номера шагов `setup` теперь видны в журнале Windows Installer. ## 1.17.2 — 12.09.2026 - **Указатель попадал мимо.** Агент хоста не учитывал DPI: при масштабе экрана больше 100 % абсолютные координаты мыши ложились на экран меньше захваченного; а при захваченной мыши вьювер ставил указатель хоста по размеру видео, а не хоста, и в уменьшенном потоке он не доезжал. ## 1.17.1 — 12.09.2026 - **Меню сеанса и горячие клавиши.** Ctrl+Alt+Shift+M открывает меню в окне потока: захват мыши, полный экран, баланс качества, Ctrl+Alt+Del, отключение. Горячие клавиши на трёх модификаторах, которые не занимает ни одна игра: +Z мышь, +X полный экран, +D Ctrl+Alt+Del, +Q отключиться. Ctrl+Alt+End шлёт Ctrl+Alt+Del, как mstsc. В полном экране у верхнего края выезжает панель. - Окно потока было чёрным на машинах без видеокарты. ## 1.17.0 — 11.09.2026 - **Один файл на сторону.** Агент хоста FIDO Stream теперь встроен в `RdpFidoGate.exe`, окно потока — в `RdpFidoClient.exe`. Оба установщика и автообновление приносят всё, что нужно потоку; вручную больше ничего копировать не надо. Шлюз запускает себя командой `stream serve` в сеансе пользователя, клиент — командой `viewer` в дочернем процессе, поэтому падение декодера или драйвера закрывает только окно потока. - На установленном хосте доступны команды диагностики `RdpFidoGate.exe stream encoders`, `stream encoders --bench`, `stream selftest` и `stream audio-devices`. - Самообновление при открытом потоке: старый файл сначала переименовывается, потом копируется новый, поэтому обновление больше не срывается, пока идёт стрим. - **Шлюз восстанавливается после зависшей службы брандмауэра Windows.** Если вызов в службу брандмауэра не возвращается, сторожевой поток завершает шлюз через 90 с, и диспетчер служб перезапускает его — вместо ответа «рабочий поток брандмауэра не ответил вовремя» на каждый запрос, пока кто-нибудь не заметит. Гранты, записанные из потока брандмауэра, истекают по расписанию, даже если вызывающая сторона перестала ждать; удаление правил не теряется. ## 1.16.1 — 11.09.2026 - HEVC декодируется на видеокарте безопасным путём: NVIDIA NVDEC на NVIDIA, аппаратный DXVA-декодер на Intel и AMD. Программное расширение HEVC от Microsoft не используется (оно падает), поэтому вьювер без подходящей видеокарты переходит на H.264, а не падает, и пишет причину в `client.log`. - Декодер H.264 Media Foundation теперь тоже работает на видеокарте (DXVA). ## 1.16.0 — 10.09.2026 - **Кодер и декодер выбираются в сессии.** «Кодер (хост)»: Автоматически / NVIDIA NVENC (напрямую) / Аппаратный (любая видеокарта) / Программный (процессор); «Декодер»: Автоматически / Аппаратный (GPU) / Программный (CPU). NVENC работает напрямую через драйвер, аппаратный вариант — кодер любого производителя через Media Foundation (Quick Sync, AMF), программный — H.264 Microsoft. - `encoders --bench` измеряет каждый бэкенд на синтетических кадрах без экрана и сети. - Два исправления задержки: ожидание захвата экрана больше не блокирует поток кодера, а настройки низкой задержки кодера NVIDIA применяются там, где он их учитывает. Кодирование 2560×1600 — с 60 мс до 6,5 мс на кадр; задержка «из конца в конец» в локальной сети — с 380 мс до 25–45 мс. ## 1.15.0 — 10.09.2026 - **FIDO Stream** — второй режим подключения рядом с RDP для игр и другой работы, где важнее всего задержка «клик — фотон». Видео, звук и ввод идут по UDP: AES-256-GCM на ключах из ECDH, привязанного к билету, который шлюз выдаёт только после подтверждения ключом FIDO2; код Рида–Соломона (FEC) вместо ретрансляций; надёжный канал для ввода; контроль перегрузки. - Хост: захват DXGI Desktop Duplication, аппаратное кодирование (NVENC / Quick Sync / AMF через Media Foundation) с путём пикселей D3D11 без копий, звук WASAPI, внедрение ввода скан-кодами. Вьювер: аппаратное декодирование, вывод D3D11 flip без вертикальной синхронизации, raw input, захват мыши (Ctrl+Alt+Home), полный экран (Ctrl+Alt+Enter), отключение (Ctrl+Alt+End). - Один ползунок **«Баланс»** от «плохой канал» до «слабые компьютеры» с режимом «Авто»; звук в обе стороны, включая микрофон; хост сам дозванивается до клиента через большинство NAT по кандидатам адресов, переданным через HTTPS-канал шлюза. UDP 7441 открывается только для подтверждённого адреса и только на время сессии. ## 1.14.0 — 03.09.2026 - **Один объединённый установщик** `RdpFido-Setup.exe` задаёт единственный вопрос — это хост (к нему подключаются) или клиент (с него подключаются) — и ставит нужную половину. Без диалогов: `RdpFido-Setup.exe host|client`. Клиент остаётся пакетом «на пользователя» (без прав администратора), шлюз — «на машину» (служба). ## 1.13.0 — 01.09.2026 - Шлюз поставляется как MSI, `RdpFidoGate-Setup.msi`: включает удалённый рабочий стол с NLA, привязывает сертификат к порту 7440, регистрирует службу и показывает одноразовый код регистрации ключа на последней странице, на языке Windows. Тихо: `msiexec /i RdpFidoGate-Setup.msi /qn`. ## 1.12.x — 30.08.2026 - Подписанные лицензия и манифест обновлений, баннеры с картинками по выбору сервера с офлайн-ротацией, контроль порта RDP, неудачные вызовы шлюза записываются в `client.log`.