Am 12.06.2013 um 13:04 schrieb Erik Aronesty <[email protected]>: > my opinion, > > how do peers discover that each other exist? is there a central point where > they can register, and then receive a list of peers? if not, you may need to > look into multicast (224.0.0.1) during peer discovery for your network > segment, if so, then just leave that central point a req/rep
in my case it's a rather static setup, one would really want to know the peers and in advance > it would be better, if it's possible, to use req/rep and just say all > transactions require confirmation. updates flow in both directions rather fast, but only the last one counts, so there's no point in gagging throughput with a lockstep protocol vanished peers will be detected by a separate keepalive, but at a much lower frequency and only on lack of traffic > but sometimes this isn't reasonable, esp if the message rate is high, or you > want to take advantage of zmq's blocking to wait for a reply from a > single-threaded router. if that's the case, use router/dealer, where each > peer is a "router" and also has dealer connections to other peers. this is a > flexible/open configuration that can be fraught with trouble if you aren't > careful, but also can be blazingly fast and reliable if you are I wound up with a socket setup straight from asyncserv.py, one backend thread per peer, works great - Michael > - erik > > > > On Mon, Jun 10, 2013 at 3:33 AM, Michael Haberler <[email protected]> wrote: > Hi, > > I am about to implement a protocol between peers; the phases and interactions > being roughly: > > - an negotiation phase (peers exchange options and reach agreement or dont) > - an 'open' phase entered on agreement, where state updates flow either > direction as needed, not necessarily requiring confirmation > - a shutdown phase initiated by either side > > Potentially there might be more than two peers. Message flows and encoding > are done (protobuf). > > -- > > The thing I am unsure about is: which socket type should I choose? I dont see > an obvious match in here: http://api.zeromq.org/3-3:zmq-socket > > the closest thing supporting that rather free-form of exchange of messages > would be two pipes made of ZMQ_PUSH/ZMQ_PULL sockets, one pipe per direction > and peer > > any better suggestions? > > - michael > > > > _______________________________________________ > 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
