Рекомендации по использованию ZeroMQ

Question

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

В моем клиентском приложении есть несколько фоновых потоков, которые периодически запрашивают данные с сервера. Кроме того, некоторые действия пользовательского интерфейса (например, нажатие кнопки) могут вызывать сообщение на сервере. WCF сделал это легко - код просто назывался соответствующим методом на однопользовательском прокси-сервере WCF (на самом деле я использую средство WCW Castle Windsor, которое дает мне возможности асинхронного вызова, но это, вероятно, не имеет отношения к моему вопросу).

Я не слишком уверен, как этот подход переведёт на ZeroMQ, особенно в отношении управления сокетами - я очень новичок в ZeroMQ и все еще читаю руководство. Правильно ли я говорю, что мне понадобится отдельный сокет для каждого потока (т. Е. Два потока b/g и пользовательский интерфейс)? Как насчет времени жизни сокета - создаем ли я каждый раз, когда я хочу отправлять/получать (предположительно неэффективно), или создавать сокет, когда поток запускается и повторно используется для всего жизненного цикла потока?

Answer 1

Одна вещь должна быть очень ясной. Розетки ZMQ могут подключаться и разговаривать только с гнездами ZMQ.

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

Выбор ZMQ Розетки для таких средств - хорошая идея. Это позволяет вам мгновенно создавать множество коммуникационных шаблонов, таких как req/rep, push/pull, pub/sub и т. Д., А также создавать более сложные топологии с использованием устройств ZMQ.

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

Является ли ваше приложение-клиент использованием обычных сокетов? Можно ли переписать его для использования сокетов ZMQ?

Если нет, то не используйте гнезда ZMQ для внешнего интерфейса , но только для связи вашего внутреннего компонента.

[Edit: Другие примечания]

ZMQ является оберткой над гнездами, но это делает несколько вещей, которые трудно получить сделано вручную

1. Он управляет сообщениями на более высокую пропускную способность путем пакетирования несколько сообщений одновременно
2. Оптимизирует использование сокета одновременно
3. Сокет может отправлять сообщения только одному другому сокету, гнездо ZMQ может подключаться к нескольким гнездам ZMQ ц
решение на основе
4. ZMQ сокет может немедленно воспользоваться различными узорами - REQ/REP, PUSH/PULL, PUB/SUB и т.д.

Как всегда, это обычная перепутать ZMQ быть очереди сообщений.

1. Очередь сообщений, которая доступна, имеет другие свойства, такие как сохранение сообщений и гарантия доставки, путем реализации очереди для хранения.
2. ZMQ означает «Очередь Нулевых сообщений»

Я только учусь ZMQ в последнее время и был очень счастлив использовать его.

заказ мой мини-учебник по ZMQ и посмотреть, если это имеет смысл для вас, чтобы использовать его:

http://learning-0mq-with-pyzmq.readthedocs.org/en/latest/

Answer 2

Что касается интеграции замка, проверить, что Генри сделано на вилке:

https://github.com/hconceicao/clrzmq2/tree/master/src/integration