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
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
