[nanomsg] Re: Trying to implement "directory" pattern
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- Date: Mon, 25 Feb 2013 20:54:28 +0100
On 25/02/13 09:14, Paul Colomiets wrote:
Sure. What I am saying is that when sending messages to two
destinations in parallel, reliably and if one of the destination
application hangs, it will ultimately cause the other application
hang. Thus the failure propagates sideways.
Eh, why? If subscriptions are buffered, the only thing that's not
perfect, is that subscriptions use twice the memory needed (one instance
is the tree itself, and the other is buffer), everything else works
perfectly. I think in 99.99% real cases subscription's memory usage is
at least two order of magnitude lower than memory usage of the
application. At least in pub-sub.
If you can put hard limit on overall amount of subscriptions, it may work.
For "directory" problem is slightly more complex as the system may
accept requests but be unable to send replies, being unable to
unsubscribe at the same time. But IMO that's not a kind of problem that
nanomsg can solve in any protocol.
I am not sure whether I really understand, but, for example, REQ/REP
handles non-deliverable replies by simply dropping them.
There's buffering code in inproc transport (inproc doesn't use a
network protocol with tx/rx buffers so it has to buffer messages
itself). See src/transports/inproc/__msgqueue.h
I should probably move that class into src/utils, so that anyone can
re-use it.
Yeah, that would be nice. So I need to create a pipe for subscriptions
and use worker thread to pick up messages one by one and put them into
the output pipe?
Yes.
In any case, before moving msgqueue to utils, it should be cleaned up.
There are references to nn_inprocb and nn_inprocc objects in it, meaning
it has dependency on inproc transport.
It doesn't block yet, because the subscription forwarding is not yet
implemented, but yes, I would say it should block.
Well, I believe that all blocking calls should have a non-blocking
counter-parts. Having non-blocking counter-part for this one seems to
complicate API.
Good point. What's the alternative here?
I can imagine not allowing unsubscriptions in pub/sub (only way to
unsubscribe would be to close the socket). Then, instead of using
SUBSCRIBE/UNSUBSCRIBE options, one can just send the subscription as a
message.
Yes. For consistency's sake, the option names should be prefixed by
socket type name. However, to keep names simple and consistent with
0MQ I opted to ommit them here, ie. NN_SUBSCRIBE instead of
NN_SUB_SUBSCRIBE.
Should we change that?
NN_SUB_SUBSCRIBE could be shortened, but trying to find synonyms for
NN_RESEND_IVL feels ugly. The prefix also helps to find mistakes in the
code, so I'm +1 for it.
I like the prefixes better myself. The question remains how annoying
would it be for the user. Presumably, not too much.
Martin
Other related posts:
