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
