Привет! Скажу сразу: главная цель этой статьи — поделиться полезным и бесплатным инструментом для передачи файлов. Просто реальная история и рабочий инструмент.

Короткая предыстория

Я разработчик. У меня нет кучи серверов, сложной инфраструктуры или дорогого железа. Есть ноутбук (Dell XPS L322x) с GNU/Linux и пара виртуальных машин с ним же.

На прежней работе я плотно возился со SPICE-протоколом. Была задача — добавить выделенный канал для передачи файлов между тонким клиентом и виртуальной машиной прямо в «подкапотку» SPICE. Это означало:

  • модифицировать серверную часть (spice-server),

  • модифицировать клиентскую часть (spice-gtk),

  • написать с нуля гостевой агент для ВМ.

Я всё это сделал. И понял две простые вещи:

  1. Возможность удобной передачи файлов в VDI сильно упрощает жизнь простым трудягам. Подтверждением этого стала реакция отдела тестирования, который занимался тестированием канала SPICE для передачи файлов.

  2. Вся эта конструкция не оправдывает себя.

Ты напрочь завязан на протоколе доставки рабочего стола и при этом ограничен только связкой «тонкий клиент ↔ виртуальная машина». А если мне нужно передать файл вне этого сценария? Например, тестовую сборку гостевого агента на другую ВМ. Как это сделать?

Мне надоело постоянно смотреть IP-адреса виртуальных машин и через основную ОС перегонять файлы по scp. Настройка сетевых папок и интерфейсов — тоже гиблое дело.

Если честно, у многих компаний-разработчиков VDI-решений на ваше удобство, скажем так, «положено с прибором». Citrix, VMware, отечественные вендоры — они комплектуют свои продукты стандартными вариантами: сетевые папки, выделенные каналы с drag-and-drop (в лучшем случае), либо вообще всех загоняют в облака. Технологический застой в этой сфере объясняют просто: не видят большого дохода от разработки таких инструментов. Ну, не видят и не видят — мы пойдём другим путём.

Решение проблемы

Я устал от этой рутины и решил сделать свой инструмент, который бы работал вне зависимости от протоколов и окружений. Так появилась Комета-4.

Что это такое?
Комета — это набор из двух программ: сервер и клиент.

  • Сервер запускается на ОС хоста — и всё, больше никаких настроек не нужно.

  • Клиенты подключаются к этому серверу и через него передают файлы без каких-либо ограничений.

Все клиенты равноправны. Неважно, где запущен клиент — на виртуальной машине или на реальном устройстве. Вы сможете передать файл в любом направлении любому другому клиенту. При этом не нужно знать IP-адреса устройств — достаточно один раз ввести IP-адрес сервера и номер клиента-получателя (В версии Комета-4 это номера от 0 до 3).

Проще говоря, Комета может передавать файлы в любых направлениях:

  1. ВМ ↔ ВМ

  2. ВМ ↔ Физическое устройство

  3. Физическое устройство ↔ Физическое устройство

Как это выглядит на практике

Представьте: у вас есть ноутбук и три виртуальные машины на сервере. Вы запускаете сервер Кометы на хосте (одной командой ./comet_server 192.168.1.35 8888). На каждой ВМ и на ноутбуке запускаете клиент и подключаетесь к серверу по его IP-адресу и порту(192.168.1.35 8888). Все устройства получают номера: ноутбук — 0, ВМ1 — 1, ВМ2 — 2, ВМ3 — 3.

Теперь, чтобы передать файл, вы просто указываете в клиенте номер получателя (от 0 до 3) и отправляете файл (файлы попадают в /home/user/CometDownloads/).
Всё. Не нужно смотреть IP-адреса, не нужно подключаться по SSH, не нужно возиться с общими папками и кучей терминальных окон. Просто и работает.

4 клиента одновременно передают файлы между собой
4 клиента одновременно передают файлы между собой

Как это работает под капотом

Давайте чуть подробнее разберём архитектуру. На схеме ниже показана общая структура.

Общая схема Кометы
Общая схема Кометы

Комета использует простую клиент-серверную модель:

  • Сервер — это фактически виртуальный маршрутизатор, который работает на хосте. Он не хранит файлы, а только выступает мостом между клиентами.

  • Клиенты — это приложения, запущенные на каждой ВМ или физическом устройстве. Они сами устанавливают исходящее соединение с сервером (через TCP). Это почти всегда разрешено даже в самых строгих сетевых политиках.

    Ключевые преимущества такого подхода:

    • Не нужны публичные IP-адреса для ВМ — они сами инициируют соединение с сервером.

    • Не нужно настраивать проброс портов или VPN — всё работает «из коробки».

    • Нет зависимости от облачных сервисов — файлы не покидают вашу инфраструктуру.

После подключения сервер выдаёт каждому клиенту уникальный номер. Когда клиент А хочет отправить файл клиенту Б, сервер устанавливает между ними косвенное соединение и ретранслирует весь поток данных между ними через унифицированный виртуальный канал.

Комета спроектирована для простого масштабирования и лёгкой модификации. В основе архитектуры лежат модули и виртуальные каналы — это позволяет добавлять новый функционал без переписывания всего кода. Такой подход упрощает поддержку и ускоряет выход обновлений.

Особое внимание уделено производительности. Серверная часть использует многопоточность и равномерно распределяет нагрузку между всеми ядрами ЦП, но при этом не перегружает систему, оставляя ресурсы для других процессов и ОС. В перспективе появятся настраиваемые режимы работы для точного управления производительностью. И при всём этом сервер остаётся невероятно компактным — его исполняемый файл весит всего ~20 КБ. Для сравнения, обычный SSH-сервер (sshd) занимает около 700 КБ. Это примерно в 35 раз больше.

Клиенты на ВМ(2) и ВМ(1) передают файлы друг другу и клиент на хосте передаёт файл клиенту на ВМ(1)
Клиенты на ВМ(2) и ВМ(1) передают файлы друг другу и клиент на хосте передаёт файл клиенту на ВМ(1)

Интерфейс клиента: простота и практичность

Клиент Комета-4
Клиент Комета-4

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

Было перепробовано много вариантов: Dear ImGui, webview, RmlUI, CEF, Flutter. Но у каждого были свои недостатки. Любое приложение на веб-движке по умолчанию потребляет около 70 МБ оперативной памяти. А если добавить «современный» дизайн с тенями и блюром, то даже локальная ВМ на 2 ядрах с QXL не вывезет такой нагрузки. А это, знаете ли, ещё неплохая связка.

Зачем городить сложности, если пользователю нужно всего три действия: указать получателя и нажать «Отправить» и выбрать файл? В итоге остановился на LazarusIDE: кроссплатформенный, нативный, без лишних зависимостей, с GTK2 под капотом, отлично работает на слабых виртуальных виртуальных машинах. Клиент упаковал в AppImage — 30 МБ, портативно, запускается везде.

Итог

Главное отличие Кометы в том, что она решает проблему там, где другие инструменты просто не работают — в изолированных виртуальных средах, где ВМ не видят друг друга по сети. И делает это эффективно, с минимальными затратами ресурсов — сервер весит 20 КБ, клиент в AppImage — 30 МБ, и всё это шустро работает даже на слабых ВМ.

На этом я и закончу. Всем спасибо за внимание! Буду рад обратной связи в комментариях.

P.S. Пока что Комета работает только на Linux (начиная с Ubuntu 20.04 и всех её «сестёр»). В будущем поддержка будет расширена до Windows и macOS. Гораздо более старые версии дистрибутивов Linux тоже будут поддерживаться.