[zeromq-dev] forwarding a message with metadata

Thomas Rodgers rodgert at twrodgers.com
Mon Aug 11 18:23:18 CEST 2014


>
> 1) I want to use CURVE and zmq_msg_gets()
>
> When I recv() a message on the ROUTER socket it has metadata attached
> to it. Can I (and how) forward this message across the PAIR socket savely
> keeping the metadata pointer intact so the app can still call
> zmq_msg_gets() on it?


caveat; I haven't tried it, but I did not see anything obvious in the
implementation that would preclude metadata attached to a message from
being forwarded over a PAIR socket by simply sending the received message.
 The underlying pipe just copies the msg struct by-value to a queue then
calls init(), resetting the supplied message to an empty state, without
messing with the refcount on the attached metadata.  The receiving side
will take ownership of the associated metadata reference when it dequeues
the message.



On Mon, Aug 11, 2014 at 10:14 AM, Goswin von Brederlow <goswin-v-b at web.de>
wrote:

> Hi,
>
> I hope you don't mind but I want to brainstorm a bit.
>
> I want a generic solution to handle heartbeats that I can reuse in
> different applications. The most transparent way for this seems to be
> to create a seperate thread for it. So the design looks something like
> this:
>
> [client] PAIR <--inproc--> [heartbeat thread] PAIR-DEALER <--tcp-->
>
> and
>
> <--tcp--> ROUTER-PAIR [heartbeat thread] <--inproc--> PAIR [server]
>
>
> The heartbeat thread just forwards messages between the app and the
> outside world and back monitoring the traffic. And when there is no
> traffic it inserts heartbeats at regular intervals. It also filters
> out incoming heartbeats from the outside world.
>
> So far this is pretty simple. But now for the interesting parts:
>
> 1) I want to use CURVE and zmq_msg_gets()
>
> When I recv() a message on the ROUTER socket it has metadata attached
> to it. Can I (and how) forward this message across the PAIR socket savely
> keeping the metadata pointer intact so the app can still call
> zmq_msg_gets() on it?
>
> 2) I want to report disapeared peers to the app
>
> Basically I have normal messages and control/monitoring messages. I've
> been thinking that on a ROUTER socket each message starts with an
> identity frame. So I could send a 0 frame to indicate the message is a
> control message.
>
> But what do I do with the client? I can't use the same with a DEALER
> socket. I would have to prefix every message with 0 (control) or 1
> (data) and that would need change the application. I couldn't just
> plug in or remove the heartbeat without rewriting the message parsing.
>
> A short time ago we talked about using some bit in the message itself
> to say wether it is a control message or normal and having in-band
> control messages for connect/dicsonnect and so on. Maybe it would be a
> good time to design and implement something like that now and use it
> here?
>
> 2b) Combining 2 and 1. Can I set my own metadata for control messages?
>
> I think the lack of a User-Id on a message could be used to identify
> control messages. Right?
>
> 3) I want to connect/disconnect/bind/unbind or set HWM and so on
>
> The app and the DEALER/ROUTER sockets are in different threads. This
> makes modifying them directly impossible (never share a socket between
> threads, right?).
>
> So this would also need some form of control message but going the
> other way this time.
>
> Should this be just a custom control message that is specific to my
> use case or would it make sense to define a set of control messages
> for all the socket operations in zmq so other use cases use the same
> syntax? I'm thinking this could be reusable for proxies.
>
> MfG
>         Goswin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140811/502cf3a4/attachment.html>


More information about the zeromq-dev mailing list