XMPP: добавить двунаправленность в pubsub?

Question

Я не уверен, что пабсаб или многопользовательский - это путь?

Мне кажется, что мне нужен pubsub, но с добавленной возможностью для подписчиков также транслировать сообщения в ленту новостей. Двунаправленный поток информации, если хотите.

Вариант использования таков, что подписчики будут подписаны в среднем на 1000 различных каналов, но каждый отдельный канал передает информацию в среднем только один раз в неделю. Итак, много кормов, но низкая активность в каждом. Однако, из-за того, что существует 1000 различных активных подписок, подписчик все равно может получать уведомления о 100 сообщениях в день, и он должен иметь возможность «отвечать», или постить контент, на любой из этих каналов.

Кажется, мне нужен гибрид pubsub / multiuserchat. Но этого не существует или нет? Любые идеи или указатели?

Спасибо большое!

Answer 1

Если подписчик публикует данные, он не просто подписчик, а издатель.И нет никаких причин, по которым одно и то же лицо не может быть одновременно издателем и подписчиком.

Что касается вашего более общего вопроса о pubsub и MUC, я обнаружил, что этот вопрос часто возникает.в настоящее время.

Очевидно, что на первый взгляд MUC и pubsub очень похожи, они оба предназначены для вещания в группу.Многие приложения могут легко использовать одно или другое без проблем.

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

MUC:

1. Абсолютно хорошо для стандартных чатов онлайн-пользователей, общающихся друг с другом.Если это то, что вы делаете, используйте его.
2. Включает присутствие, то есть уведомление других жителей о присоединении, выходе и изменении статуса.
3. Разрешает анонимное частное общение между людьми.
4. Работает "из коробки" практически с любым стандартным XMPP-клиентом (для стандартных сообщений чата).
5. Автоматический выход из комнаты, когда пользователь отключается или отключается.
6. Сообщения с пользовательскими даннымиподдерживаются, что означает, что вы ограничены маршрутизацией стандартных сообщений чата.

Pubsub:

1. Один или несколько издателей, отправляющих сообщения многим подписчикам только для чтения, являются основной территорией pubsub.В отличие от MUC, подписчики не публикуют и не получают информацию о других подписчиках.
2. Реализации серверов, как правило, имеют гораздо более гибкий контроль доступа для pubsub.
3. Только пользовательские полезные нагрузки, не стандартныесообщения чата.
4. Опционально имеет полное постоянство элементов.
5. Узлом можно управлять как списком элементов (т. е. добавлять / удалять с уведомлением), а не просто как широковещательную рассылку.
6. Подписки могут сохраняться в автономном режиме.

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

Answer 2

Не уверен, в чем проблема. Подписчик просто должен быть издателем. Ничто не мешает им публиковать, а также подписываться (если узлы не настроены на его запрет).

Это, похоже, очень типичный случай паба.