[nanomsg] Re: Persisted reliable messaging
- From: Jörg Singler <joerg@xxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Fri, 22 Nov 2013 18:35:07 +0100
Hi Paul,
for PUB->SUB and PUSH-->PULL I will use inproc or ipc and only req->reply
is used via tcp. I am playing around currently to get some feeling for
nanomsg. Stacking of the patterns is something which is suggested by zmq as
far as I understood. This might be the reason why I am sticking to it. I am
trying to leverage from all patterns somehow the best: from PUB/SUB the
subscriptions, req->reply for ackn and push-pull for load-distribution to
worker-nodes...
Best, Joerg
2013/11/22 Paul Colomiets <paul@xxxxxxxxxxxxxx>
> Hi Jörg,
>
>
> On Fri, Nov 22, 2013 at 6:33 PM, Jörg Singler <joerg@xxxxxxxxxxxx> wrote:
> > I used the following stacking
> > of patterns: Pub -> SUB (filtering on topics) -> Files
>
> I'm not sure about your use case, but pub-sub chain can loose
> messages when pushback is applied (when subscriber is not fast
> enough). And I'd say this defeats the whole purpose of the
> persistence.
>
> > -> req -> reply
> > (sending aknowledge only) -> PUSH --> PULL (distributing work to multiple
> > workers).
>
> I don't think you need aknowldedge here, because you can loose a
> message in push-pull anyway. Unless you do push/pull via inproc/ipc.
>
> > Do you think the stacking should/can be optimized? I will keep you
> > updated...
> >
>
> I think you are thinking in terms of "lets make rabbitmq over nanomsg"
> rather than "lets solve the task in neat way". I.e. you use 3 message
> patterns for doing a single task. That's not how nanomsg is supposed
> to work IMO.
>
> Do you have higher level task in mind, that you can describe? Or do
> you just playing with things as time permits?
>
> --
> Paul
>
>
Other related posts:
