[zeromq-dev] Pattern help

[Lindley French]

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 <matt.connolly at me.com> 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 <lindleyf at gmail.com> 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
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131218/9a34ce56/attachment.htm>