Паб / подписка и подписка на основе контента

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

Взгляните на некоторые из обучающих программ, предлагаемых RabbitMQ

Ссылка

Обратите внимание, что вы можете использовать маршрутизацию и темы для доставки сообщений применимым клиентам. "Сервер" здесь может просто отбросить сообщения в очереди, и клиенты могут просто прослушивать определенные сообщения на основе маршрутизации/тем, на которые они подписались. Вероятно, есть много других вариантов, но это, по-видимому, хороший маршрут для перехода. У RabbitMQ есть несколько клиентов .Net, и я был очень доволен их продуктом.

Я также использовал IBM MQ и MSMQ, но мне нравится Rabbit намного лучше. В основном потому, что он основан на AMQP, который является открытым протоколом, и позволяет мне использовать .Net, Python, Java и т.д., Чтобы подключаться вместо проприетарного драйвера или пытаться обернуть все в JMS. Ни в коем случае эксперт, поэтому, возможно, некоторые другие лучше понимают вашу проблему.

Удачи.

Распространение котировок акций - это именно тот случай, который привел к патентованию адресации публикации/подписки, которые мы теперь знаем и любим как "темы" в JMS и других технологиях обмена сообщениями (патент EP0412232).

В этом случае сервер будет публиковать биржевые котировки ( "тики" ) по предмету, содержащему символ тикера... в общем случае вы бы использовали пространство имен темы, которое давало некоторую иерархическую информацию о символе - например, NASDAQ.TECHNOLOGY.HARDWARE.AAPL.

Клиенты подписываются на символ или группу символов, используя подстановочные знаки субъекта. Механизм pub/sub обеспечил бы распределение только подходящим подписчикам. Использование многоадресной сети может сделать это очень эффективным.

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

Из краткого описания, которое вы даете, ваш сценарий выглядит как подходящий для внедрения OMG DDS (Data Distribution Service). Это спецификация языка, и есть несколько продуктов, которые предлагают С# API.

См. эту статью в Википедии для краткого введения и списка ссылок.

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

В частности, требование фильтрации содержимого, которое вы описываете, является важной функцией. Некоторые из доступных продуктов реализовали сложные механизмы фильтрации, которые хорошо масштабируются и имеют умные компромиссы между объемом трафика в сети и нагрузкой ЦП, необходимой для оценки фильтров. Эти фильтры выражаются в синтаксисе SQL, как предложение WHERE для SELECT.

Реализации DDS обычно являются высокомасштабируемыми и децентрализованными по своей природе. Компоненты, участвующие в инфраструктуре DDS, развязаны как в пространстве, так и во времени. Некоторые продукты DDS развертываются в многочисленных критически важных для бизнеса системах и системах.

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