У меня есть существующая служба, которая уведомляет большое количество клиентов о возникновении события. Он использует длинный механизм опроса, который я переворачивал сам. Я изучаю замену этого механизма концентратором signalr и работаю прототипом. Но у этого есть довольно значительная неэффективность, которая кажется, что должно быть решение, но я не нахожу его.SignalR Hub: вызов того же метода с одинаковыми параметрами для нескольких клиентов
Я понимаю идею групп в signalr, и группы, очевидно, предназначены для предотвращения этой неэффективности, но есть причина, по которой я не могу использовать группы. Я надеюсь, что достаточно сказать, что мне нужно вызвать один и тот же клиентский метод с одинаковыми значениями параметров для многих клиентов, использующих ConnectionId каждого клиента. Я могу объяснить, почему в случае необходимости, но это действительно не имеет значения.
Предположим, у меня есть список из 200 ConnectionId, и мне нужно вызвать тот же метод, при каждом из которых передается один и тот же параметр объекта. Если я просто прокручиваю вызов вызывающего Клиента Clients.Client (ConnectionId) .clientMethod (param), я предполагаю, что объект param будет сериализован 200 раз.
Есть ли способ сериализации параметров (ов) один раз, а затем вызвать клиентский метод с использованием уже сериализованных параметров?
UPDATE
Я нашел проблему GitHub, что звуки, связанные (может быть, даже это точный выпуск) в Allow to Send Json Strings without duplicate Serialization. Похоже, что функциональность была добавлена в signalr, но проблема github ничего не говорит о том, как это сделать, и я не могу найти что-либо относительно этого в signalr docs.
UPDATE 2
В вопросе GitHub, указанным выше, новая функциональность была реализована PersistentConnection только - не хабами. При постоянных соединениях при отправке параметра типа ArraySegment signalr предполагает, что он предварительно сериализуется и отправляет его как есть, без его сериализации.
По какой-то причине это не было реализовано для концентраторов, хотя было бы полезно для концентраторов по той же причине, что было полезно для постоянных подключений.