[zeromq-dev] ROUTER socket and zmq_socket_monitor
Pieter Hintjens
ph at imatix.com
Sat Sep 28 10:49:39 CEST 2013
These sound like good ideas. I think we lack documentation on the
event interface, and it could be worth wrapping in CZMQ too.
I think formalizing the internal protocol would be good, and using a
default inproc endpoint as we do with ZAP could make it simpler.
On Fri, Sep 27, 2013 at 8:57 PM, gonzalo diethelm <gdiethelm at dcv.cl> wrote:
> I have been looking into the monitor mechanism and I think there are several
> shortcomings, that I would like to address. I would like some opinions on
> these points before diving into the code.
>
>
>
> 1. We really need two separate “disconnected” events: one
> “local_close” for when the local socket has disconnected from its remote
> peers, another “remote_disconnected” for when one (out of possibly many) of
> the socket’s remote peers has disconnected from us. In the second case, it
> is necessary to identify the remote peer (by its address?).
>
> 2. We should also add a new type of event (as Doron Somech suggested
> half a year ago) that will trigger whenever the peer’s identity is
> ascertained by the local socket. This would allow us to then identify which
> was the peer that produced a “remote_disconnected” event.
>
> 3. I think (but have not thought this through) it would be easier for
> bindings if all the event data (except perhaps the event id) was formatted
> as ASCII strings, otherwise it is necessary to interpret binary data in
> other languages.
>
> 4. I think we should switch from 16 to 32 bits for the event mask, we
> have already used up the first 10 bits.
>
>
>
> Best regards,
>
>
>
> --
>
> Gonzalo Diethelm
>
> DCV Chile
>
>
>
> From: zeromq-dev-bounces at lists.zeromq.org
> [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Joel Lauener
> Sent: Wednesday, August 07, 2013 9:53 AM
> To: zeromq-dev at lists.zeromq.org
>
>
> Subject: Re: [zeromq-dev] ROUTER socket and zmq_socket_monitor
>
>
>
> Hi Richard,
>
>
>
> Thanks for your answer. I already receive the address but in the particular
> case of a router socket it's not that useful. I receive something like
> 'tcp://0.0.0.0:2000' which is the address to which the socket is bound.
>
>
>
> My question was if there is a way to know what is the identity of the peer
> that has been disconnected (as set on the client side with the ZMQ_IDENTITY
> option). There are many connections behind a router. When I receive a
> disconnect event I need to know to which connection it belongs in order to
> take the correct action on the server (callback user code, cleanup resource,
> ..).
>
>
>
> Cheers,
>
> Joel.
>
>
>
> Date: Mon, 5 Aug 2013 11:12:34 +0100
> From: Richard_Newton at waters.com
> Subject: Re: [zeromq-dev] ROUTER socket and zmq_socket_monitor
> To: "ZeroMQ development list" <zeromq-dev at lists.zeromq.org>
> Cc: zeromq-dev-bounces at lists.zeromq.org
> Message-ID:
>
> <OF242DDFB2.16EF4ADC-ON80257BBE.0037B5C6-80257BBE.00381560 at waters.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Hi Joel,
>
> The monitor event mechanism uses 2 sends to communicate, the first message
> contains the event details and fd, the second will contain the address, so
> you need to do a second receive to get the address.
>
> Apparently this was to make it easier for language bindings.
>
> Ric.
>
>
>
>
> From: "Joel Lauener" <Joel.Lauener at cern.ch>
> To: "zeromq-dev at lists.zeromq.org" <zeromq-dev at lists.zeromq.org>
> Date: 05/08/2013 11:02 AM
> Subject: [zeromq-dev] ROUTER socket and zmq_socket_monitor
> Sent by: zeromq-dev-bounces at lists.zeromq.org
>
>
>
> Hi,
>
> Currently I'm trying to setup a monitor on a ROUTER socket to detect clients
> disconnections. This system is put in place in addition to an heartbeat
> mechanism in order to provide faster disconnection detection on the server
> side.
>
> My problem now is that I effectively receive a ZMQ_EVENT_DISCONNECTED event
> from ZMQ, but the payload of this event only contains "fd" (file
> descriptor I guess?). In such case is there a way to find the identity of
> the peer (as set on the client side using the ZMQ_IDENTITY option)?
>
> Joel._______________________________________________
>
> ________________________________
>
> Declaración de confidencialidad: Este Mensaje esta destinado para el uso de
> la o las personas o entidades a quien ha sido dirigido y puede contener
> información reservada y confidencial que no puede ser divulgada, difundida,
> ni aprovechada en forma alguna. El uso no autorizado de la información
> contenida en este correo podrá ser sancionado de conformidad con la ley
> chilena. Si usted ha recibido este correo electrónico por error, le pedimos
> eliminarlo junto con los archivos adjuntos y avisar inmediatamente al
> remitente, respondiendo este mensaje. Disclosure: This Message is to be used
> by the individual, individuals or entities that it is addressed to and may
> include private and confidential information that may not be disclosed, made
> public nor used in any way at all. Unauthorized use of the information in
> this electronic mail message may be subject to the penalties set forth by
> Chilean law. If you have received this electronic mail message in error, we
> ask you to destroy the message and its attached file(s) and to immediately
> notify the sender by answering this message.
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
More information about the zeromq-dev
mailing list