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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Я был первоначально смущен с вопросом, но после его прочтения снова я понял, что мы работаем над почти идентичными проектами. Mine присоединяет простой последовательный клиент к psuedo TTY, который передает что-то очень похожее на Ajaxterm. Это облегчает доступ к консолям к виртуальным машинам с виртуальными виртуальными виртуальными машинами Xen.

Answer 2

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

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

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

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