[zeromq-dev] CZMQ & CLIENT-SERVER identity frames.

[Luca Boccassi]

On Mon, 2017-10-09 at 12:41 +0000, Stephen Gray wrote:
> A few years ago I devised and implemented this zeromq scheme<https://
> docs.google.com/drawings/d/19fkuumKbSJItjAZ6RrsOYpSmA0lOZEAN8Lc2naaI-
> R4/edit?usp=sharing> to facilitate cloning and transmission of past-
> accumulated and live-updating time-series data from multiple sources
> to multiple selective consumers.  At the time the sources were
> running on Windows, the consumers on Linux or Windows.  I was unable
> to build CZMQ on Windows so it was necessary to re-invent the wheel
> and code up my own socket handling class and multipart-message class
> in C++.  This scheme is in use & works reliably day-to-day.
> 
> Times have now changed; I'm able to build & use CZMQ on Windows &
> Linux.  I would like to revisit the scheme, update it to SERVER-
> CLIENT socket types (ROUTER-DEALER is to be superseded) and implement
> it all in CZMQ, also adding authentication and encryption ala
> IronHouse<https://github.com/zeromq/czmq/blob/master/examples/securit
> y/ironhouse.c>.
> 
> My questions are:
> 
> 
> 1.        To implement this scheme the most demanding technical
> challenge is the accumulating, preserving & switching the prepend
> order of routing 'identity' frames such that the ROUTER (or SERVER?)
> can direct the message to its destination.  Can this be accomplished
> with CZMQ; can multiple accumulated identity frames be accessed and
> prepend order manipulated?

Have you looked at Malamute? It's a broker built on top of CZMQ, sounds
somewhat related:

https://github.com/zeromq/malamute

> 2.       SERVER-CLIENT sockets at present don't support multipart
> messages so zmsg_encode () & zmsg_decode ()would be necessary; will
> this interfere with access to routing identity frames?

Note that, since many users expressed the desire to keep using
multipart, ROUTER/DEALER is no longer marked as deprecated and will be
maintained alongside the new thread-safe socket types. See:

https://github.com/zeromq/libzmq/issues/2699

So if you need that feature for your use case you can continue using
those socket types.

> 3.       Is the scheme/pattern of value/interest to the zeromq
> community, would it be worthwhile to collaboratively redevelop it on
> Github?

It sounds interesting and if you need resources like a repository in
the org please let us know and we'll help.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20171009/6dc6b6db/attachment.sig>