Hi all, There have been some discussion lately on semantics of XREP socket, say whether it should drop unroutable messages silently.
This email attempts to give some background to the discussion, so it'll be a bit long, but it's probably worth reading it. XREP socket type was introduced as part of request/reply messaging pattern. Request/reply pattern is an interaction mechanism that can be seen in various RPC implementations as well as in SOA systems (CORBA, DCOM etc.) How it works that a "client" sends a request which (after passing through arbitrary intermediate nodes) gets to the "service". Client asks for particular service type to be performed. He doesn't ask for particular client instance to perform it. That way the intermediate nodes (brokers) can load-balance the requests among arbitrary number of service instances. Once the service processes the request it sends a reply which gets routed back the original client. Note that "drop if unroutable" strategy makes perfect sense in this pattern: If the original requester doesn't exist any more, the reply can be dropped. Now, 0MQ provides two different layers of functionality. It's "end-to-end" layer and "hop-by-hop" layer. Those who are familiar with how core Internet protocols work know that IP works in hop-by-hop manner, simply re-sending the IP packets to the adjacent nodes in the network, while TCP is layered on top of it and provides the end-to-end functionality, where two endpoints, with arbitrary number of hops between them can communicate and provide added value (ordering, reliability etc). With 0MQ, socket types beginning with X are hop-by-hop, while the rest are end-to-end socket types. The end-to-end type is always layered on top of the corresponding X socket. E.g. REP is layered on top of XREP etc. In short, if you have two applications communicating via intermediate device, each of 4 endpoints (1 per app + 2 in the device) have it's own X socket and the terminal nodes (the apps) have non-X socket layered on top of the X socket. That's the theoretical model. Now, XREP socket is implemented in such a way that it's "send the reply back to the original requester" functionality can be used to route messages to specific peer. However, note that this is an implementation detail. If the implementation of request/reply pattern changes, the routing functionality can break. Let me give an example: If request contains an unique "request ID" (say an UUID) instead of backtrace stack and intermediate devices remember the UUID along with which connection it was received from, they would be able to route replies (which would contain the original UIID copied from the request) back the original requester. Obviously, not to store stale data and eventually run out of memory, the UUID=>connection entry in the map would be deleted after the reply was routed back. Thus, if you try to remember the ID and use it to route the messages to that particular endpoint, only the first one would get there. Any subsequent messages would be dropped as unroutable. Lately, there's lot of usage of XREP as a router, so we have to deal with it somehow. I think there are 3 basic attitudes to the problem to choose from: 1. Routing is a low-level functionality used to build 0MQ patterns on top of it. This layer is equivalent to generic networking frameworks such as ACE or Boost.Asio. If so, libzmq should be separated into 2 libraries, one providing the basic networking functionality, the other, being layered on top of it, providing well-designed messaging patters. 2. Routing to address is a separate messaging pattern and should be exposed as such. Routing to address is definitely a stand-alone messaging pattern that is implemented by protocols such as SMTP, XMPP and even IP as such. I deliberately haven't introduced it to 0MQ along with other messaging patters, given it's well supported by other products and really complex to implement (propagation of routing tables etc.) However, if there's enough interest and resources to support such a pattern, nothing prevents us to add new socket types etc. 3. Routing to an address is not an valid and/or redundant pattern and thus people are using XREP as an router at their own risk and should expect strange behaviour (such as silent dropping of unroutable messages) to happen. Thoughts, anyone? Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
