SignalR поиск и отписка

Я хотел бы прояснить пару моментов вокруг SignalR. У меня есть приложение, которое считывает сделки (например, биржевые коды, связанные с потоковой передачей цен на акции). Группа для этого концентратора SignalR представлена ​​по стандартному коду. У него есть издатель, который запускается при запуске (для чтения потоковых данных) концентратора SignalR, после чего клиент (клиенты) подписывается на определенные биржевые коды. Рабочий процесс для этого типа концентратора довольно хорошо документирован.

У меня есть второй концентратор, который ищет несвязанные (с указанными выше) данные, которые считываются из таблицы. Издатель хаба для этого хаба не запускается при запуске хаба. У меня издатель запускается, когда происходит подписка. Подписчик получает критерии поиска, создает группу (чье имя в основном является критерием поиска). Этот тип хаба мне не слишком ясен. В частности, когда и где я должен отказаться от подписки, когда я ввожу другие критерии поиска. На данный момент я подписываюсь, а затем получаю ответное сообщение на основе поиска. Когда я ввожу другие критерии поиска, где я должен отказаться от подписки - (а) получить от клиента или (б) я должен просто передать старые критерии с «следующими» критериями поиска и вызвать отписку на сервере (т.е. отказаться от подписки и подписаться на другой) или (c) мне нужно явным образом отказаться от подписки?

Любая помощь будет принята с благодарностью


person TerrorBight    schedule 10.08.2015    source источник
comment
Что мне непонятно, так это то, что когда вы подписываетесь на поисковый запрос, ожидаете ли вы, что ваш клиент получит несколько ответов в разное время на основе новых результатов, доступных по тем же критериям? Я предполагаю, что да, но из вашего вопроса я не уверен, потому что тогда зачем другому критерию поиска нужно очищать предыдущий? Они смотрят на меня несвязанные поиски.   -  person Wasp    schedule 11.08.2015
comment
Что я пытаюсь сделать, так это то, что UserA подписывается на концентратор (передавая значение 123), который создает группу с именем ACCOUNT123 (123 — это номер учетной записи, который он/она ищет). Пользователь B подписывается на тот же концентратор (передавая значение 456), который создает группу ACCOUNT456 (456 — это номер учетной записи, по которому он/она ищет). Когда есть обновления того, что когда-либо возвращал поиск для каждого критерия, результаты должны возвращаться только соответствующему пользователю (т.е. если имя учетной записи для номера учетной записи 123 изменяется, обновление будет отправлено только Пользователю А, так как он / она подписан в группу АККАУНТ123)   -  person TerrorBight    schedule 11.08.2015


Ответы (1)


SignalR на самом деле не предназначен для pub/sub, есть библиотеки, созданные поверх SignalR, которые решают эту проблему, например, моя собственная https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy/wiki

Это абстрагирует signalr, и теперь вы можете отбрасывать строго типизированные сообщения так, как считаете нужным в своем домене (Backend). Клиенты могут прослушивать эти сообщения, и моя библиотека склеит их все вместе.

Моя библиотека не использует группы SignalR, вместо этого у нее есть собственная библиотека для маршрутизации сообщений определенным клиентам. https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy/wiki/Implement-constraint-handlers

Сообщение блога

http://andersmalmgren.com/2014/05/27/client-server-event-aggregation-with-signalr/

person Anders    schedule 11.08.2015
comment
Я немного удивлен, что ты так говоришь. Насколько я понимаю, SignalR вполне подходит для pub/sub (что является лишь одним из его предложений), особенно для чего-то немного сложного, когда вызовы, сделанные сервером клиенту (и наоборот), могут повысить ценность процесса — «все является stream», похоже, довольно хорошо реализована с помощью SignalR и RX (codeproject.com/Articles/851437/) - person TerrorBight; 11.08.2015
comment
Xsockets больше подходит для этого из коробки, signalr больше похож на RPC-фреймворк. - person Anders; 11.08.2015
comment
Спасибо, Андерс. Принял ваш совет относительно того, чтобы не использовать SignalR для этого типа требований. Я мог бы использовать сокеты, но пока я использовал WCF с обратным вызовом (в основном потому, что я использовал его раньше). Кажется, работает нормально, но со временем я посмотрю на XSockets, так как это может быть более надежное решение. - person TerrorBight; 12.09.2015