Абстракция сетевого программирования, декомпозиция

У меня проблема в следующем:

Серверный процесс 1

  • Постоянно отправляет обновления, которые происходят в хранилище данных

Серверный процесс 2

  • Клиенты связываются с сервером, который запрашивает хранилище данных и возвращает результат.

Дело в том, что результаты, которые процесс 1 и процесс 2 отправляют обратно клиенту, совершенно разные и не связанные между собой.

Как это разложить? У вас есть только один процесс, который постоянно отправляет данные, и определяете протокол, чтобы он имел бит, который соответствует типу возвращаемого значения 1 или 2?

У вас есть два процесса? Как тогда они совместно используют хранилище данных (это просто структура, а не база данных)?

Спасибо!


python networking network-programming twisted
person DevDevDev    schedule 01.10.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

Я хотел бы, чтобы первый серверный процесс был искаженным сервером, который использует txamp для потоковой передачи целых чисел в RabbitMQ. Любые клиенты, которым нужны оперативные данные, могут подписаться на поток в RabbitMQ, также используя Txamp. Клиенты веб-браузера могут использовать Orbited вот рабочий пример.

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

Не создавайте свою собственную систему обмена сообщениями, RabbitMQ хорошо протестирован, масштабируем и может сохранять ваши «сообщения» (необработанные данные), если что-то пойдет не так.

person Tom Leys    schedule 01.10.2009
comment
Я сначала так и думал, но не существует надежного клиента STOMP, который изначально работал бы на iPhone. - person DevDevDev; 02.10.2009
comment
Вам не нужна библиотека STOMP, если вы изначально работаете на iphone, вам нужна клиентская библиотека C++ AMQP, например, txAMP - это библиотека для python. Погуглите, чтобы найти тот, который вам нравится. - person Tom Leys; 02.10.2009

arrow_upward
1
arrow_downward

Если вы можете ограничиться Twisted, я рекомендую использовать Perspective Broker. По сути, это система RPC, и ее не очень заботят понятия «клиент» и «сервер» - либо инициатор TCP-соединения, либо ответчик могут запускать вызовы RPC в PB.

Таким образом, сервер 1 будет принимать регистрационные вызовы с помощью объекта обратного вызова и вызывать обратный вызов всякий раз, когда у него будут доступны новые данные. Сервер 2 предоставляет различные операции RPC по мере необходимости. Если бы они работали с одними и теми же данными, я бы поместил оба сервера в один процесс.

person Martin v. Löwis    schedule 01.10.2009
comment
И просто хранить данные как глобальную переменную процесса? Это более или менее путь, по которому я сейчас иду, используя Twisted. Можете ли вы указать мне пример использования обратных вызовов по сети? Разве тогда клиент не должен действовать как RPC-сервер? Прямо сейчас я делаю именно то, что вы сказали, за исключением того, что у клиента есть два потока, один просто блокирует получение данных с сервера 1, а второй доступен для отправки вызовов RPC на сервер 2. - person DevDevDev; 02.10.2009
comment
Я могу использовать Twisted только на стороне сервера, ограничивает ли это меня использованием прямого TCP? - person DevDevDev; 02.10.2009
comment
@DevDevDev: Чтобы получить реальный пример PB, взгляните на buildbot (buildbot.net). Ведомые сборки входят в мастер; затем RPC идут в обоих направлениях по одному TCP-соединению (что позволяет вызывать ведомые устройства, которые находятся за брандмауэром или NAT). Если клиенты написаны не на Python, вам нужно накатить свой собственный протокол RPC поверх TCP. Я рекомендую использовать кодировку TLV. - person Martin v. Löwis; 02.10.2009

arrow_upward
0
arrow_downward

Почему бы не использовать базу данных вместо «просто структуры»? Как реляционные, так и нереляционные БД предлагают множество практических преимуществ (отдельные процессы, использующие их, забота о репликации [[и/или моментальных снимках, резервных копиях, ...]), богатая функциональность, если она вам нужна для «запросов», и т.д. далее и так далее).

В худшем случае «просто структура» может быть обработана третьим процессом, который полностью предназначен для нее (в основном имитируя то, что может предложить любой движок БД — хотя движок, вероятно, сделает это лучше и быстрее;-), что позволит вам в как минимум сохраняйте хорошую декомпозицию (с двумя серверными процессами, взаимодействующими с «процессом хранилища данных»).

person Alex Martelli    schedule 01.10.2009
comment
Я надеялся, что никто не ухватится за это, потому что я сказал хранилище данных. База данных очень не подходит для этого приложения. Думайте об этом как о массиве целых чисел, они меняются, сервер должен отправить свои изменения, пользователь может запросить какой-то сложный расчет массива. - person DevDevDev; 02.10.2009
comment
@Dev*3, как бы то ни было - я все же предлагаю вам посвятить процесс уходу и наполнению этого хранилища (таким образом, также внутренне сериализуя доступ к нему, безопасный выбор - если вам нужны какие-то перекрывающиеся доступы, вы можете повеселиться, реализовав блокировку диапазона, R vs W и многопоточность процесса хранилища данных ;-). - person Alex Martelli; 02.10.2009