Hi Ian, > I've been away from the list for a few days, so apologies if this has > been suggested. I was thinking about the router/xrep issue, and the fact > that we know people want and have valid use cases for service routing. > However, XREP is not ideal for that at the moment as it effectively > promotes routing to nodes rather than services. It also occurred that we > have half the problem solved in the XPUB/XSUB branch. > > What I considered was something similar to the subscription matching and > forwarding. For example, a worker creates a socket and sets a new sockopt: > > socket->setSockOpt(ZMQ_PROVIDE, "createOrder"); > socket->setSockOpt(ZMQ_PROVIDE, "deleteOrder"); > > When connected to a ROUTER type socket, these PROVIDEs are sent across. > When a message is received by the ROUTER, it sends it to any connected > socket which PROVIDEs the service, using the same prefix matching as > subscriptions, but it only sends to a single connection at a time (round > robin between them as normal). If the ROUTER is connected to another > ROUTER, it sends upstream all the PROVIDEs it is aware of, and hence > propagates the availability in the same way as the subscription > upstreaming on XSUB. > > This seems to give us the routing flexibility, but still saying scalable > and 0MQ-y.
I think we are conflating two problems here. The first one is "how to conflate requests for several service types into a single topology". That's what you are addressing in your proposal. My feeling is that feeds that are inherently different (ie. those that must be routed to different stateless services to be processed) should not be conflated. The problem with conflation of incoherent feeds is that it effectively prevents lower layers of the stack and/or intermediaries to do anything useful based on the feed ID (think of monitoring, traffic shaping, smart routing, head of line blocking problems etc.) Btw, the example with createOrder and deleteOrder actually doesn't involve two separate feeds. Both commands can be -- presumably -- executed by exactly the same nodes. Thus all you need is a simple application level protocol. Something like "if first byte of the message is 0, it's createOrder, if it's 1, it's deleteOrder). A more realistic example of two different feeds is market data distribution vs. order management. The second problem is the stateless vs. statefull service problem. With stateless services, the REQ/REP paradigm works OK (put aside couple of holes in the current implementation). The point is that all the stateless services are the same (they have no state to distinguish them) and thus it's ok to send a request to the "cloud" of services and let infrastructure to decide which particular instance will the request be delivered to. On the other hand, with statefull services every instance is different. You have to route your request to the particular instance because the data you are interested in are stored at that instances and are not accessible to other instances. You can in theory solve that by creating a separate topology (ie. assigning a different TCP port etc.) for every statefull service instance. However, that would become a management nightmare pretty quickly. So, the only sane solution, AFAICS is devising a special messaging pattern(s) for accessing stateful services. That's where the ROUTER socket type would fit in IMO. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
