CometD службы по сравнению с широковещательным каналом

В статье http://www.cometdaily.com/2008/05/15/the-many-shades-of-bayeuxcometd-2/index.html автор описывает:CometD службы по сравнению с широковещательным каналом

Часто с PubSub, разработчики чувствуют необходимость создания канала для каждого пользователя, чтобы доставить личные сообщения клиенту. Например, если торговая система хочет уведомить пользователя о завершенных сделках, возникает соблазн создать канал, например/trades/a_user_id, и каждый пользователь будет подписаться на свой собственный канал. Этот подход работает, но не является самым ресурсоемким способом решения этой проблемы и требует кода безопасности для предотвращения несанкционированного доступа клиентов к другим каналам пользователей.

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

источник

2016-06-14 Chap

В статье довольно старый, он относится к CometD 1 в то время как мы сейчас на CometD 3. Вы можете проверить обновления на CometD website и читать CometD 3 documentation.

Понятия за трансляции против служебных каналов все еще действительны для CometD 3.

Сервер выделяет структуры данных для каждого канала создается, будучи его трансляции или обслуживания канала.

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

В данном конкретном случае все приложение необходимо выполнить, чтобы доставить сообщение конкретному клиенту. Для этого варианта использования лучше использовать служебный канал, потому что он использует меньше ресурсов (один и тот же серверный канал может использоваться для всех пользователей без риска, что пользователь получает сообщения, не предназначенные для него/нее), и это более безопасный.

источник

2016-06-14 08:48:08 sbordet

Благодарим за быстрый ответ! Я понимаю, что подкрадывая уязвимость, и не будем забывать об этом на секунду. Если мы создадим такое же поведение маршрутизации, как и широковещательный канал в канале обслуживания, отслеживая подписчиков для идентификатора пользователя, то не будет ли он потреблять одинаковое количество ресурсов или есть больше, чем просто память? От взгляда на код кажется, что для канала есть несколько частей накладных расходов, таких как подметание и инициализация. Это сильно влияет на производительность сервера, когда есть много каналов? – Chap

Вы _could_ используете один служебный канал для каждого 'user_id', но это было бы необязательно. Сказав, что CometD был протестирован в масштабе до десятков тысяч каналов без проблем, но вы все равно хотите обратить внимание на ненужные ресурсы, если это не обязательно. API CometD позволяет эффективно отправлять сообщения одному клиенту, поэтому очень просто написать такие приложения. – sbordet

CometD службы по сравнению с широковещательным каналом

ответ

Смежные вопросы