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

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.

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.