It's similar but not really the same thing. Still, polling on two sockets sounds a lot more straightforward than trying to make one socket receive from two others but only send to one of them.
On Tue, Dec 17, 2013 at 6:42 PM, Matt Connolly <[email protected]> wrote: > This sounds a bit like the “reliable pub sub pattern” mentioned in the > guide: > > http://zguide.zeromq.org/page:all#Reliable-Pub-Sub-Clone-Pattern > > You could swap two threads for two sockets and poll for messages on either > socket and process them in an event driven way. Would that help? > > -Matt > > On 18 Dec 2013, at 9:34 am, Lindley French <[email protected]> wrote: > > > I'm trying to figure out the appropriate pattern to use here, and I'd > like some assistance getting started down the right path. > > > > I have two types of messages: shared data, and one-shot data. The idea > is to make the one-shot messages as small as possible by sending data that > is common to many of them only once as shared data, and then referring to > it by a simple integer in the one-shot message. This is background; my > question focuses on the shared data. > > > > I would like to send a block of shared data from host 1 to host 2, along > with the integer used to represent it. Host 2 sends back an "I have X" > message indicating it received the shared data. Host 1 is comforted. > > > > However, it's possible a shared data message could be lost for a variety > of reasons even when tcp is the underlying transport. If this occurs, > potentially many one-shot messages will become useless, so I can't tolerate > it. My thinking is that if a one-shot message arrives at host 2 with an > unknown shared data id, host 2 should send a message to host 1 saying "I > don't have X", and host 1 will then resend it. Host 1 can assume that an "I > don't have X" message won't arrive (or can be ignored) once an "I have X" > message arrives. > > > > Now, the problem is that sending shared data X must occur in two > separate places: up front, at the caller's request, and also upon receipt > of an "I don't have X" message. This is a complication because the natural > inclination is for these two things to occur in separate threads, but we > can't share zmq sockets across threads without a mutex. I don't mind > mutexes, but I'm trying to see if there is a better approach. It occurred > to me that perhaps the caller's initial request on host 1 should be passed > to an inproc socket which spits it out identically to an "I don't have X" > message from host 2 so it can be handled the same way. > > > > This implies to me that host 1 should use a ROUTER socket, since that is > the only way to have two incoming connections (tcp and inproc) but ensure > all outgoing messages are directed over tcp. However, host 2 also needs a > ROUTER socket because it needs to know where to send "I don't have X" > requests, and host 1 can't be hard-coded. The client requests on host 1 can > go into an inproc DEALER socket I suppose. > > > > Am I thinking about this correctly? > > _______________________________________________ > > 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
