Aaah thanks ... Will use Jyre probably as quick reference but will wrestle with C as well. Was doing some 15 years ago. As well I plan to use this pattern on some Arduino / Atmel microcontrollers ... sometimes :-)
Robert 2013/12/19 Pieter Hintjens <[email protected]> > Robert, > > You might even look at the Jyre project, which is a (slightly out of > date) Java implementation of the Zyre protocols. > > -Pieter > > On Thu, Dec 19, 2013 at 9:08 PM, Robert Gallas <[email protected]> > wrote: > > Pieter, Andrew > > > > > > Thanks for pointers. I'm not the best C source reader, but beacon was > well > > written and not that much difficult to understand. I'll try to look > around > > in Zyre as well. > > > > I have run quickly through http://markburgess.org/BookOfPromises.pdfand it > > seems that Kivix is targeting same area. By coincidence it seems that > what > > Promise Theory calls "promise" in Kivix is implemented as "capability". > And > > has a form of URN urn:kivix:demo:mathapp. > > > > Bundles of promises seems like failover functionality. Which brinks me to > > question why have bundle of promises and not just start more nodes with > same > > capability / promise. But that is not question for this thread and > probably > > not for ZeroMQ community. > > > > I'll look at Zyre and will read Promise Theory draft. Hope I'll be able > to > > come up with simple "just enough" API or else I'd rather drop this > failover > > feature. > > > > Many thanks again > > Robert > > > > > > > > 2013/12/19 Andrew Hume <[email protected]> > >> > >> this also fits in nicely with promise theory (mark burgess, uni of oslo) > >> which gives a different take on how to reason about cooperating nodes. > >> > >> On Dec 19, 2013, at 3:01 AM, Pieter Hintjens <[email protected]> wrote: > >> > >> One thing you could look at is how we did distributed log collection > >> in Zyre. Any node can be a log collector. When nodes discover each > >> other, and interconnect, they indicate if they collect logs, and then > >> their peers connect back, over ZeroMQ, and stream log events to them. > >> > >> -Pieter > >> > >> On Wed, Dec 18, 2013 at 8:27 PM, Robert Gallas <[email protected] > > > >> wrote: > >> > >> Thanks Pieter, > >> > >> For PoC purpose only node discovery is implemented. ZeoMQ (JeroMQ) will > be > >> used as core node interconnection protocol. Other protocols are present > >> just > >> as PoC of hexagonal application design possibilities. > >> > >> So far I can live with unreliable Beacon style heartbeat for monitoring > >> purposes. > >> > >> Node management is more interesting topic. To be honest I have not very > >> clear vision yet. Kivix is meant to be set of autonomous nodes. But > nodes > >> form functional topology only if they cooperate with each other. > >> Autonomous > >> nodes design is therefore in direct contradiction to cooperating nodes. > In > >> traditional style of system management there are agents installed on > every > >> node where we need to support manageability. There are three basic types > >> of > >> node functionality failures: > >> > >> 1. managed functionality fails, agent runs and we can contact the agent > >> 2. management agent fails > >> 3. failure at network level > >> > >> Only in first scenario management agent can help to resolve failure > >> situation. And there is of course topic of who discovers failed node. > >> Basically it's the same situation as with central broker vs brokerless > >> architecture. Having central management console is something I would > like > >> to > >> avoid. > >> > >> One possible way of solving node manageability is to have functionality > >> requesting node to report failure. Then along with listening to service > >> urn > >> to show up on network, node can start to broadcast resource starvation > >> message. Then only really required functionality is reported to be > failed. > >> Basically there is no need for urn:com.example.kivix.mathapp to be > >> reported > >> as failed if there is no node requesting that functionality. > >> > >> Then there is question how to respond to node failure. There can be > latent > >> nodes on network which can implement more than one capability. Then in > >> case > >> of resource starvation broadcast message, node can takeover the > >> responsibility and start to provide required capability. This kind of > >> behaviour can be then used in self-load-balancing nodes. If there is too > >> much messages waiting in dealer queue, dealer can broadcast resource > >> starvation message and if there is possibility, some nodes can switch to > >> worker mode with required capability. > >> > >> But again there are categories of applications where there are very > >> different requirements about level of manageability. > >> > >> At this time I'm not decided which approach to begin with. Kivix is only > >> sideproduct of another application. I'm implementing features only if > >> requirement is driven by that application or if there is some > interesting > >> idea like Beacon worth to try out as PoC. > >> > >> If you can point me to some resource where this topic is discussed I > would > >> be glad. I'd like to avoid reinventig the wheel. > >> > >> Robert > >> > >> > >> 2013/12/18 Pieter Hintjens <[email protected]> > >> > >> > >> Hi Robert, > >> > >> This is neat! Have you used ZeroMQ for instance for monitoring and > >> managing nodes? > >> > >> -Pieter > >> > >> On Tue, Dec 17, 2013 at 10:24 PM, Robert Gallas < > [email protected]> > >> wrote: > >> > >> Hello, > >> > >> I'd like to announce simple beacon implementation in Kivix framework. > >> Inspiration comes from beacon implementation in czmq. So far as PoC > >> only. > >> There is no API or protocol similarities implemented yet. Example is > >> given > >> at http://gabert.github.io/index.html?art=exno5_6 > >> > >> Many Thanks > >> Robert > >> > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > >> > >> > >> > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > >> > >> > >> ----------------------- > >> Andrew Hume > >> 949-707-1964 (VO and best) > >> 732-420-0907 (NJ) > >> [email protected] > >> > >> > >> > >> > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
