Comments 6
А можно просто поставить stoat chat. хоть клиент хоть сервер. Тем более что в РФ построить какую то коммерцию на этом без СОРМ невозможно. И даже не коммерцию тоже если будут услуги сторонним людям.
UPD: он ещё и в Linux работает.
Да, Stoat можно было использовать, и это вполне нормальный вариант. Особенно плюс за открытый код, самостоятельное размещение и Linux.
Но наша задача была немного уже: голосовые комнаты без регистрации и почты, быстрый вход команды, PTT, игровой оверлей, одинаковая работа Windows, Android и браузера, персональная громкость и собственная настройка передачи голоса. Плюс нам был интересен сам путь разработки продукта под нашу команду, а не только получение готового чата.
У self-hosted Stoat тоже есть нюанс: в официальной документации указано, что сейчас не все официальные клиенты полноценно поддерживают сторонние серверы, лучше всего работает веб-клиент/PWA. Но проект интересный, спасибо, изучим его внимательнее.
По СОРМ замечание справедливое. Бесплатность сама по себе не отменяет возможных требований законодательства. Мы не собираемся делать вид, что этого вопроса нет: перед масштабированием или коммерциализацией обязательно разберём правовой режим с профильными специалистами. Пока БОЛТУН остаётся бесплатным развивающимся проектом. Linux у нас тоже в планах.
Вот где пригодился бы асинхронный ввод-вывод, но в Унихе его не было (хотя абсолютно во всех многозадачных ОС 1960-70-х он был в обязательном порядке и, более того, является основной любого ввода-вывода -- в силу асинхронной природы самих операций), в Линухе сравнительно недавно завезли громоздкий и переусложнённый IO_URING, который, судя по Хабру, далеко не везде поддерживается, а стандарт POSIX, предусматривающий, в т.ч., и асинхронщину (без неё реально тяжко сделать многие вещи, требующие более-менее реального времени), Линух не поддерживает.
В целом согласен: дисковый ввод-вывод вообще не должен находиться в горячем аудиопотоке. Асинхронный writer с ограниченной очередью был бы наиболее чистым решением: если очередь переполнена, теряем строку диагностики, а не голосовой кадр.
Но описанная в статье ошибка возникла не на Linux-сервере. Блокирующие std::ofstream::open, запись и std::endl выполнялись в Windows-клиенте непосредственно в аудиотракте. Мы сначала применили прагматичное исправление: оставили файл открытым, убрали постоянный flush, сократили частоту событий и стали писать пачками. Следующий правильный шаг здесь именно отдельный поток журналирования с bounded queue, а не io_uring.
Серверный координатор написан на Go. Сетевой ввод-вывод там проходит через netpoller рантайма, который на Linux использует epoll, поэтому напрямую работать с io_uring нам пока нет необходимости.
И небольшое уточнение: POSIX AIO в Linux всё-таки доступен через glibc, хотя его реализация основана на пользовательских потоках, имеет ограничения и действительно не всегда даёт то, чего ждут от полноценного kernel AIO. Спасибо за замечание: в статье стоило чётче разделить клиентский файловый I/O и серверный сетевой тракт.
После блокировки Discord в России 8 октября 2024 года мы какое-то время пользовались обходным способом. Потом перестал работать и он.
Ютуб с телеграмом в вашем лесу тоже больше не работает? И про технологии древних, типа тимспика, вы тоже не слышали?
Голос пропадал каждые три секунды: как пять друзей из Tarkov Arena сделали БОЛТУН