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

Stephen Gray riskybizlive at live.com
Mon Oct 9 14:41:47 CEST 2017

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/security/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?

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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20171009/df735c8d/attachment.htm>

More information about the zeromq-dev mailing list