Limitations of SunRPC mechanism as a Client-Dispatcher-Server architecture and comparison with Broker

Question

I am reading a book on design patterns (an old edition) "Pattern-oriented software architecture". In the chapter dedicated to Client-Dispatcher-Server, SunRPC is cited as a Client-Dispatcher-Server architecture, with portmapper acting as Dispatcher in the Client-Server negotiation. I never used SunRPC practically, although I know more or less how it works.

I have three questions:

• What are the software limitations (in terms of interfaces and features) of SunRPC as a Client-Dispatcher-Server mechanism ?
• What are similar better systems today to achieve the same Client-Dispatcher-Server architecture (regardless of language) ?
• What are the intrinsic differences between a Broker architecture and a Client-Dispatcher-Server architecture ?

I do realize the questions are many and complex. I considered splitting into independent questions, but the point of this submission is about general architecture principles and limitations, with a specific example (SunRPC) as a typical case. Due to these considerations I preemptively announce that I will put a 100 rep bounty as soon as I have the chance, regardless of my level of satisfaction with answers during the grace period.

Answer 1

That's a good set of questions. You could try the siemens-patterns list serve as uiuc. Last I knew it was pretty low volume but there were a number of sharp folks there, even some of the authors. You could ask and share your enlightenment.

Answer 2

This terminology is unusual (to me at least), maybe that's the reason why you aren't getting many responses. Judging by the diagram on page 327, client-dispatcher-server means that a redirection to the real server occurs at connection time, while broker interposes in the whole communication (page 109)? Assuming that, modern-day terms would be "redirect" (or "name service" or "directory service" etc), and "proxy", respectively. The main difference is a trade-off between latency and availability, ie brokers are in a position to patch things up when a server dies, which dispatchers aren't; but brokers add a modicum of processing time to the pipeline.

Modern-day instances of both patterns can be found on high-volume Web sites: they will typically employ a round-robin or more sophisticated load-balancing DNS service (the dispatcher) as well as caching reverse proxies (brokers).

I don't know much about SunRPC and its limitations, and I have no idea if it can possibly be used in a round-robin kind of way (searching Google for "portmap load balancing" turns up nothing FWIW). An entry in the portmapper's table will typically point to a single server running on the same host, ie mostly this mechanism serves to avoid allocating well-known TCP ports to SunRPC services.