Wrapper-daemon обрабатывает вывод обернутых программ

Question

У меня есть небольшой хобби-проект, в котором я пишу демон-оболочку в linux на C. Это значит, что он предназначен для запуска, мониторинга, выдачи команд и остановки других программ.Демон также обслуживает веб-интерфейс, где пользователи могут войти в систему и манипулировать запущенными программами.

Способ, которым он сейчас настроен, заключается в том, что всякий раз, когда программа записывает в свой стандартный вывод, этот вывод перенаправляется втруба.Всякий раз, когда кто-то обращается к программе через веб-интерфейс, веб-интерфейс начинает опросить демон через XMLHttpRequest (), затем демон проверяет, было ли что-то записано в канал, и отправляет ответ с тем, что было в канале ввремя.

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

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

Я думаю, что что-то вроде вышеупомянутого решения решит многопользовательскую проблему, ноЯ думал, что сделаю удар и запросю сообщество Stack Overflow об этой проблеме.Есть ли лучшее решение для такой проблемы?(Учитывая, что мне удалось описать проблему несколько понятным способом).

Answer 1

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

Я думаю, что попробую последний подход, ипросто забыть.то есть, всегда сохраняйте весь вывод навсегда.это потенциально весьма привлекательно для пользователей - в конце концов, какой эмулятор терминала не имеет большого размера буфера обратной прокрутки?это больше места для хранения, но в наши дни хранилище очень дешево.

Я не думаю, что использование БД - это плохая идея.вы можете, например, захотеть связать временную метку с выходными данными по мере их создания или выполнить поиск в контенте.Отслеживание того, как далеко в потоке пользователи увидели поток, скорее всего будет выполнено с помощью rowid, но пользователи могут по достоинству оценить интерфейс типа «покажи вывод за последний час».Хранение каждой очереди в виде таблицы с индексированием строк по времени - естественная рабочая нагрузка для БД, довольно эффективная в пространстве и времени.но базовую очередь незабудки можно было бы сделать очень просто в виде файла на поток с пользовательскими позициями, сохраненными как смещение.

Подход Тима с потоками на пользователя выполняет немного больше работы в контексте производителяв зависимости от того, как часто производитель имеет несколько подписчиков.не жизнеспособный подход, если ваши продюсеры похожи на твиттер: за ним следят миллионы пользователей;) но его подход «поток на пользователя» также может не мешать сбору мусора, может также включать идеи БД и меток времени.

Answer 2

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

Вам нужна какая-то система реализации и токенизации сеансов, где пользователи «подписываются» на определенные выходные потоки. Когда select() или poll() срабатывает на канале fd, эти данные должны быть записаны всем подписчикам этого конкретного процесса.

Вы можете реализовать оба варианта, когда данные, которые не достигли подписанного пользователя, будут сохранены для отображения при следующем входе в систему. Это не обязательно должна быть сложная или даже база данных SQL, простая пара ключ => значение будет работать так (например, просто сохраняя ее в INI-файле:

[process-token]
TIMESTAMP.SEC.(...) = "string"

Сначала я был озадачен вашим вопросом, но, прочитав его снова, понял, что мы работаем над почти идентичными проектами. Мой подключает простой последовательный клиент к TTY psuedo, который питает что-то очень похожее на Ajaxterm. Он облегчает доступ к консолям для паравиртуализированных виртуальных машин Xen.