Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

317
Vistas
Cómo configurar un patrón ZMQ PUB/SUB para servir solo para suscriptores preautorizados

¿Cómo puedo implementar o hacer una especie de "pirateo" en el patrón PUB - SUB para poder publicar solo para suscriptores autorizados , desconectar suscriptores no autorizados, etc.?

Busqué en Google este problema, pero todas las respuestas son muy similares para configurar el filtro de suscripción en el lado del suscriptor.

Pero quiero, como dije, publicar mis actualizaciones de PUB solo para aquellos clientes que pasaron una autorización, o tienen alguna key secreta, que se recibió en REQ - REP .

Gracias por cualquier idea.

over 4 years ago · Santiago Trujillo
2 Respuestas
Responde la pregunta

0

Lee el Capítulo 5 de La Guía , específicamente la sección llamada "Pros y Contras de Pub-Sub".

Hay muchos problemas con lo que está tratando de lograr en la forma en que está tratando de lograrlo (pero hay soluciones, si está dispuesto a cambiar su arquitectura).

  • Presumiblemente, necesita que el conector PUB sea generalmente accesible para el mundo, ya sea el mundo en general o simplemente un mundo que consta de algunos conectores que están autorizados y otros que no lo están. De lo contrario, puede controlar el acceso (a través del firewall) al propio socket PUB solo para máquinas/sockets autorizados.
  • Cuando un socket PUB recibe una nueva conexión, no sabe si el suscriptor está autorizado o no. PUB no puede recibir comunicación real de los conectores SUB, por lo que no hay forma de que el conector SUB comunique su autorización directamente. Los zócalos XPUB/XSUB superan esta limitación, pero no le ayudarán (ver más abajo).
  • No importa cómo comunique la autorización de un conector SUB a un conector PUB, no conozco ninguna forma en que el conector PUB elimine o ignore la conexión del conector SUB si no está autorizado. Esto significa que un conector SUB que no es de confianza puede suscribirse TODOS ('') y recibir todos los mensajes del conector PUB, y el conector PUB no puede hacer nada al respecto. Si confía en que el conector SUB se controle a sí mismo (usted crea el conector de conexión y controla las máquinas en las que se implementa), entonces tiene opciones para simplemente suscribirse a un tema de "control", enviar una autorización y hacer que el conector PUB retroalimente el canales/temas a los que puede suscribirse.

Entonces, esto prácticamente lo mata por lograr la seguridad general en un paradigma PUB/SUB que es de acceso público.

Aquí están sus opciones:

  1. Abandonar PUB/SUB : la única forma en que puede controlar exactamente a qué par envía cada vez en el lado de envío (que yo sepa) es con un conector ROUTER. Si usa ROUTER/DEALER, el socket del DISTRIBUIDOR puede enviar su autorización, el socket del ROUTER lo almacena con su ID, y cuando se necesita enviar algo, simplemente encuentra todos los sockets conectados que están autorizados y lo envía, secuencialmente, a cada uno. de ellos. Si esto es factible o no depende de la cantidad de sockets y la carga de trabajo (tamaño y cantidad de mensajes).
  2. Cifre sus mensajes : ya ha dicho que este es su último recurso, pero puede ser la única respuesta factible. Como dije anteriormente, cualquier conector SUB que pueda acceder a su conector PUB puede simplemente suscribirse a TODOS ('') los mensajes que se envían, sin supervisión. No puede ocultar efectivamente la dirección/puerto de su socket PUB, no puede ocultar ningún mensaje que se envíe a través de ese socket PUB, pero puede ocultar el contenido de esos mensajes con cifrado. El método adecuado para compartir claves depende de su situación.
over 4 years ago · Santiago Trujillo Denunciar

0

Como Jason le ha mostrado una excelente revisión sobre por qué (no olvide agregar un +1 a su notable respuesta, ¿de acuerdo?), Permítame agregar mis dos centavos sobre cómo:

P: ¿Cómo?

R: Olvídese del arquetipo PUB/SUB y cree uno específico para el caso

Sí. ZeroMQ es más bien una caja de herramientas muy poderosa que puede hacer, que una caja de dulces que tiene prohibido probar y elegir para ensamblar su próximo supercódigo.

De esta manera, su código está y permanece en el poder de establecer controles y medidas para el comportamiento del código del lado SUB que de otro modo sería incontrolable.

La creación de una solución de mensajería propia, compuesta y en capas es el verdadero poder que ZeroMQ aporta a sus diseños. Ahí te das cuenta de que eres el maestro del diseño de sistemas distribuidos. Además de los ejemplos académicos, nadie usa los arquetipos de comportamiento primitivo simple, sino que normalmente compone patrones de mensajes compuestos más sólidos y a prueba de realidad para las soluciones de grado de producción.

No existe una sola línea para hacer que su caso de uso del sistema funcione.


Si bien no es necesario que responda a todos sus detalles, es posible que desee leer los comentarios

  • sobre la gestión de conexiones PUB / SUB
  • sobre las medidas de autorización de ZeroMQ .
over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda