XMPP: agregar bidireccionalidad a pubsub?

Question

No estoy seguro de si pubsub o multiuserchat es el camino a seguir?

Lo que creo que necesito es pubsub, pero con la capacidad adicional para que los suscriptores transmitan mensajes a la fuente también. Flujo de información bidireccional, si lo desea.

El caso de uso es tal que los suscriptores estarán suscritos a un promedio de 1000 feeds diferentes, pero cada feed individual solo transmite información en promedio una vez por semana. Por lo tanto, muchos feeds, pero baja actividad en cada uno. Sin embargo, debido a que hay 1000 suscripciones activas diferentes, un suscriptor aún podría recibir una notificación de 100 mensajes por día, y debería poder "responder" al igual que enviar contenido a cualquiera de esos feeds.

Parece que lo que necesito es un híbrido pubsub/multiuserchat. Pero eso no existe, ¿o no? Alguna idea o punteros?

¡Muchas gracias!

Answer 1

Si un suscriptor está publicando datos, entonces no es solo un suscriptor, sino que es un editor. Y no hay razón para que la misma entidad no pueda ser un editor y un suscriptor al mismo tiempo.

En cuanto a su pregunta más general sobre pubsub frente a MUC, esa es una pregunta que me parece que surge mucho hoy en día.

Obviamente, a primera vista, MUC y pubsub son muy similares, ambos tratan sobre la transmisión a un grupo. Muchas aplicaciones podrían usar fácilmente una u otra sin problemas.

Para ayudar a decidir cuál se adapta mejor a sus aplicaciones, repasemos algunas de las diferencias entre los dos protocolos.

MUC:

1. es absolutamente bueno para las salas de chat estándar de usuarios se comunican entre sí. Si esto es lo que estás haciendo, úsalo.
2. Incluye presencia, es decir, notifica a otros ocupantes acerca de la unión, salida y cambio de estado.
3. Permite la comunicación privada anónima entre ocupantes.
4. Funciona de fábrica con prácticamente cualquier cliente XMPP estándar (para mensajes de chat estándar).
5. Abandono automático de la sala cuando el usuario se desconecta o desconecta.
6. Se admiten mensajes con cargas útiles personalizadas, lo que significa que está limitado a enrutar mensajes de chat estándar.

PubSub:

1. uno o unos pocos editores transmitir a muchos de sólo lectura de suscriptores territorio pubsub núcleo. A diferencia de MUC, los suscriptores no publican y no reciben información sobre otros suscriptores.
2. Las implementaciones de servidor tienden a tener un control de acceso mucho más flexible para pubsub.
3. Solo cargas útiles personalizadas, no hay mensajes de chat estándar.
4. Opcionalmente tiene persistencia completa del artículo.
5. Un nodo se puede administrar como una lista de elementos (es decir, agregar/eliminar con notificación) en lugar de simplemente difusión.
6. Las suscripciones pueden persistir estando fuera de línea.

Los puntos anteriores son solo una guía. Por lo general, se puede lograr mucho a través de la configuración del servidor. Como ejemplo, la especificación MUC permite que las habitaciones retengan emisiones de presencia para ciertas clases de ocupantes según la configuración. El truco aquí está en las implementaciones ... ya que este es un uso poco común de MUC, encontrará que puede no ser compatible en muchas implementaciones de MUC. El punto es que como MUC se diseñó para el chat y no como pubsub genérico, encontrará en gran medida todas las implementaciones y herramientas alrededor de MUC para enfocarse en ese tipo de uso.

Answer 2

No estoy seguro de cuál es el problema. El suscriptor simplemente necesita ser un editor también. No hay nada que les impida publicar y suscribirse (a menos que los nodos estén configurados para no permitirlo).

Esto parece ser un caso pubsub muy típico.