I agree that I need to have a mental-paradigm-shift to make better
use of 0MQ. Brian's comment that "1 connection oriented TPC socket
==> multiple 0MQ sockets bundled together" seems strange...isn't
the role of middle-ware usually to reduce complexity/reduce the
number of things I need to create to get the job done?
That is the big surprise. It *will* reduce complexity, even though it
won't seem like ti at first. Try to go implement the architecture you
are describing using TCP sockets (OK, maybe you have). You will find
that to support all the features you have described, you will write
more code than you do using 0MQ, it will have worse performance and be
harder to maintain. You will basically end up rewriting parts of 0MQ
yourself (you will need queues to make things properly asynchronous).
In my experience, once you find the right 0MQ socket combination, the
amount of code you will need is very minimal.
I would say that having to write less code is just one advantage.
The other, maybe more important one, is that this "1 TCP socket =>
multiple 0MQ sockets" methodology forces you to separate your aggregated
TCP datastreams into basic sub-streams, each one having clear semantics.
This in turn allows you to do interesting things with the streams. You
can scale them. You can set network QoS for them...
For example, take you lunar rover example. If "rover telemetry" is
clearly separated from "rover control", you can set separaste QoS for
each. In this case I would expect you want "real-time" QoS for telemetry
and "reliable" QoS for control.
Martin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
