[zeromq-dev] LRU broker queue in intuitive way on 3.0

[Paul Colomiets]

05.04.2011, 01:30, "Pieter Hintjens" <ph at imatix.com>:
>
> In fact the LRU mechanism could be done by the socket layer, because
> it's completely generic. It would IMO be a new socket pattern:
>
> * BOSS socket, which organizes a group of workers, and
> * WORKER socket, which takes orders from a BOSS socket
>
> The BOSS socket keeps a list of ready workers, which signal presence
> to the BOSS socket, when they connect, and when they reply to a
> request. They work synchronously, and look just like REP sockets to
> applications. They could fan-in from multiple BOSS sockets. The BOSS
> socket will queue messages until it can send them, and will return
> replies that can be sent back up to clients.
>

But Martin is right with the point that we must consider how that would
scale. If we consider that BOSS and WORKER are endpoints and
XBOSS and XWORKER are between them (probably it could be
ROUTER/DEALER, but nevermind). Then XWORKER must propagate
several workers either by sending endpoint adresses or by sending
number of paralel requests it could accept. Then if you connect
two BOSS sockets to single XWORKER, everything breaks. It's probably
meaningless, but will work for some applications (e.g. if you have A that
is connected to B and C and them in turn connected to D, and B and C
are acting like redundant devices). So the load balancing is probably
needed to be done in application-specific way.

But the thing I currently think of is how to make REP endpoints more
useful. The problem which needs REQ is that endpoint must present
itself for the router. What about socket option ZMQ_READY, which
sends some kind of message to router, and latter can register endpoint.
Then after timeouting request router it from the LRU. We have a practice
of options that are sent as messages (in PUB/SUB), so it should be not
a big problem.

This way can be solved another problem: if router is shut down while
worker sending reply, the worker will never get a request any more.
To fix this problem today you need to timeout on read
and reopen socket (hopefully RESET socket in future). But resending
READY message could be done by zeromq on reconnect, and
heartbeating can be done by zeromq or skipped in favor of TCP
keep-alives. I've just skimmed guide again, and seems that
you recommend to use XREQ sockets for this task, which seems even
less user friendly, and in fact every serious application needs that.

--
Paul