rPman

Чем больше зависимостей, тем сложнее поддержка в будущем.

Для крупных проектов (в смысле пользовательской базы) отказоустойчивость (готовые решения, поддержка от разработчиков компонентов) может оказаться предпочтительнее своих велосипедов.

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

Я настоятельно рекомендую не городить лишних сущностей и хранить файлы на том же веб сервере как статические. Если нужны ограничения доступа, то используй штатные инструменты авторизации веб сервера либо свой велосипед. Это 10-15 строк кода, например файлы изначально хранятся в не опубликованном каталоге, а при предоставлении доступа к файлу в публичном создается симлинк, в имени которого id сессии (например id_сессии/id_файла причем если доступ сразу ко всем файлам, то достаточно линка на каталог по id_сессии), а при отзыве доступа, удаляются все симлинки с указанным id сессии.

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

Подключайся к своему же веб-серверу, и отсылай ему системное сообщение (про авторизацию не забудь).

Вебсокет ратчет сервер это 1-поточное приложение, соответственно получив сообщение будет исполнен метод в том же пространстве где можно хранить список клиентов. Точно помню у ратчет был массив со списком всех подключенных клиентов, не уверен, доступен ли он публично напрямую, но в худшем случае можно собирать собственный список, доступный глобально.