I my experience having the client/server access and behavior patterns as demonstrated in the zeromq guide as a layer on top of zeromq inside your application extremely helpful to write good and stable software. it also forces you to write better code, since some subtle errors/limitations can occur when an app knows e.g about delivery automatically.
That being said, the typical patterns e.g. pirate or majordomo should really be made part of each driver to pick and choose from when creating your own topology. Luckily thats not to complicated , due to the awesome zeromq guide which includes examples in a few languages for most patterns already, getting them up to snuff into production quality code is pretty straightforward. While I would love to already have access to drivers that have them integrated, we're not there yet. Basically a c library, including production quality implementations of these patterns as demonstrated , would be helpful of course, drivers could simply refer to them the same way they refer to the original zeromq lib until they potentially implement it themselves. I would still suggest to implement the patterns in the drivers in their language anyway, since it is that language the dev will be most familiar with and thus it would be easier to understand for the dev and most importantly to change and extend depending on requirements. I am pretty sure this is going to happen, since it really does not make any sense to re-implement e.g. the majordomo pattern for every app. - Matthias Götzke On 21.08.2011, at 01:22, Pieter Hintjens wrote: > On Sat, Aug 20, 2011 at 10:49 PM, Mathijs Kwik <[email protected]> > wrote: > >> However, in the LRU example, routing/load balancing is lifted from >> zeromq into the application itself. > > Yes, that's right. > >> Basically you end up replicating big parts of functionality that >> normally get provided "behind the scenes" in push/pull sockets, just >> because there's no way to close a socket without losing data. > > Push/pull sockets do not provide this functionality at all, which is > why we do build it on top, if we want it at all. > >> Application code doesn't hear about the reconnection, >> forcing the use of (arbitrary) timeouts and cleaning up yourself in >> the application. > > Indeed. This is being improved in 4.x, to make ROUTER sockets more > useful. However it's not a major issue since worker failure is > presumably rare. You just need to detect it, recovery can entail > resubmitting the entire job. Your original question was about custom > routing so that some workers could be left idle. > >> Writing all that routing/problem detection/message tracking code seems >> to take the usefulness (and fun) out of zeromq. > > ZeroMQ doesn't try to do everything, that's a large part of its fun > and usefulness. > >> If the application has to provide all those things by itself, I think >> it can just as easily be applied to plain tcp/unix sockets (maybe add >> some framing code then). > > Well, you would have to do exactly as much work to handle routing and > errors, but additionally you'd need to do pretty much everything else > 0MQ does. There's a reason even the more complex (and realistic) > examples in the Guide are still a few hundred lines of code. > > I'd certainly encourage you to try plain TCP sockets. > > -Pieter > _______________________________________________ > 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
