Hi, Pieter. >> Yes, thats right, If you've got a better idea how to solve my problem, I'll >> be happy to try it.
> A few things come to mind. As Lucas says, this seems close to the > Freelance pattern so I'd definitely try to use that. There are are > number of aspects that could be helpful: > > * knowing the peer's identity without hard-coding it. > * using ping-pong heartbeats to know when a peer is online. > * splitting peers into clients and servers. Splitting peers into clients and servers would help if I didn't want to make it p2p :) > > Even if you want every node to be both a client and a server, > splitting the flow would be better IMO than trying to both connect and > bind on the same socket. Please explain, why? If by "splitting the flow" you meant "have a bound socket and a connected socket", than well, I've started with two sockets at each peer. I polled both sockets and read from the one that was ready. When I made the patch and removed one of sockets, the code didn't actually change, just got a bit simpler. So to me it is - why should I have two TCP connections instead of one, if having one is not only more "economical", but also makes code simpler? > You should not need to patch 0MQ to make this work. I've made things work w/o patching. It just came to my mind that issues I've been working around at application level are much easier eliminated by a simple patch. I admit the patch is not as elegant as one wishes. At least, I'm trying to point out that there are some things lacking for certain scenarios, which are probably worth considering for zmq 3.0 ... > > -Pieter -- Brugeman Artur
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
