[zeromq-dev] contributing to 0MQ

Martin Sustrik sustrik at 250bpm.com
Thu Apr 15 21:39:36 CEST 2010


Erich Heine wrote:
> Hi all,
> 
> Just figured I'd drop a quick note about the research I am involved in. 
> We don't do research on 0mq, but it is used in our research. It's 
> slightly off topic for "subjects to research" but sometimes it helps 
> just to know what others are doing. First a bit on what we are looking at:
> We are dong some experiments on a converged network as it relates to the 
> power-grid control space. By converged we mean SCADA, other sensors, 
> "engineering" (random data), and enterprise traffic all on the same 
> pipe. This space has some pretty interesting requirements, such as very 
> tight loop constraints (approaching and including real-time). Due to the 
> remote nature of many of the assets in the communication loops, there is 
> a constraint on simple over-provisioning. Further, simple 
> over-provisioning does not allow for certain SLAs to be reached anyway.
> 
> How we use 0mq:
> 
> * As a generic messaging layer: some of our work involves coordinating 
> endpoints, which we do via 0mq in a dedicated diffserv channel. We do 
> this because it gets us messages without the pain of dealing with 
> sockets directly, and more importantly, without the crap associated with 
> a lot of messaging systems.

Removing crap features can be as much fun as adding new features...

Actually it made me think of new slogan for 0MQ:

     "No Hassle. No latency. No features."

Kind of like when they run a project with AI-controlled robots at MIT:

     "Fast. Cheap. Out of control."

;)

> * As a traffic generator. Seriously, the perf tests are the only way we 
> have found yet which reliably fills a network pipe without also making 
> cpu usage go to 100% (useful for determining if our results are because 
> of our networking stuff or because of our real-time cpu scheduling).

I love hearing this!

> Near-future work:
> 
> *  0mq will be the transport for some work with "data diodes" -- 
> hardware enforced one-way data flows. These will probably be a 
> requirement for some power stuff in the future, and 0mq already has the 
> semantics in it.

That's pretty interesting. We've discussed this with Erich. "Digital 
Diode" is a piece of hardware that _really_ allows only for 
uni-directional data flow. 'Really' in this context means that the data 
in the opposite direction are physically removed, they don't arrive on 
the wire.

Once we've spend a lot of time designing 0MQ in a way to allow for 
_real_ uni-directional communication. Originally it was intended for 
(unreliable) multicast, but it fits perfectly in this case as well. As 
far as I know 0MQ is the only middleware whose semantic model natively 
allows for true uni-directional communication.

> * We have a real-time kernel and a real-time network scheduler, and are 
> looking to maybe tie 0mq in with that, so as to avoid our own messy 
> message handling stuff.
> 
> Cool things unrelated to our research:
> 
> * I was at the middleware 2010 conference, and using 0mq implemented a 
> couple of the algorithms being presented as they were being presented. 
>  This is another of the cool  things resulting from 0mq not getting to 
> high in the conceptual stack. Im certain that cool concepts like gossip 
> protocols and whatnot could easily be implemented/researched on top of 0mq.

Yay!

> Anyway, thats how 0mq is currently being used in my corner of academia, 
> hope that helps others think of cool research stuff.
> 
> Regards,
> Erich
> 
> PS sorry for the messy braindump presentation above :/

I've knew some pieces from discussions with you but couldn't manage what 
exactly are you working on. Another mystery solved.

Regards,
Martin



More information about the zeromq-dev mailing list