How would adding rpc-bind-daemon-like function change sRPC? Explain.
An rpc-bind-daemon-like function serves as a directory of all RPC services running on the same host as the rpc-bind-daemon. The sRCP system doesn't need an rpc-bind-daemon-like function because the sRPC clients specify the host and port at which they expect the server.
Adding an rpc-bind-daemon-like function to sRPC would remove the need for sRPC clients to specify port numbers;, sRPC clients would only have to know the name of the service it wants and the host on which it may be running. The sRPC run-time system would then contact the server hosts at a well-know port number to determine if the service was available, if the proper version was being offered, and so on.
Many people tried to answer this question by arguing that servers are at the mercy of the operating system when they bind (not allocate) a socket, and that an rpc-bind-daemon-like function helps solve the problem in indeterminate port numbers. This is only partially true. A process can bind a socket to any port number it wants, but it may fail because it doesn't have permission or the port's already allocated.
When implementing the boss-worker model in RPC, the first question to answer is "Which is the server and which are the clients?" The two obvious answers are "Make the boss the server and the workers the clients." and "Make the boss the client and the workers the servers."
When the boss is the server, it would offer two procedure calls to its clients
(the workers): get_problem(), which would return some instance of a
problem the client could work on, and the_answer() which the clients would
use to pass the solution back to the server. This approach turns inside-out
the way computation is usually carried out in RPC systems: the clients do all
the heavy lifting while the server just distributes the work (just as in
boss-worker model).
When the workers are the servers, each would offer a single procedure that accepts as input a problem and returns the problem's solution. The boss (the client) would then subdivide a problem and call the workers to solve the subproblems. For this scheme to work well, the boss would use concurrency to have the servers work on the subproblems at the same time.
Most people chose to have the boss be the client and the workers be the servers, but almost nobody mentioned the need for concurrency for this scheme to work well.
The Law of Demeter essentially says "No globals". Globals cause difficulties when designing an RPC-based system because a global easily accessible in an address space on one host is not a easily accessible from another address space on another host (or even from another address space on the same host). By prohibiting global access from code, the Law of Demeter is a help in designing systems that are more easily factored into RPC-based systems.
Most answers involved implementation details about argument handling, but the problem asked about designing RPC-based distributed systems, which should have been a clue.
As always, the appropriateness of concurrency depends on the time it takes to service a client vs. the rate at which clients are arriving. The client interactions with a stateless server are short, lasting for the duration of a request and its response.
The client interactions with a stateful server are longer than they are for stateless servers, starting when the client first contacts the server and ending when the client breaks contact. In between first and last contact, the client could initiate one or more request-responds pairs.
When implementing a single-threaded server, multiplexing is more important for stateful servers. Without multiplexing, when a client contacts a stateful server, it monopolizes the thread until it ends the contact. In the meantime, all other clients to the server are left to wait.
A lot of the answers used the tautology "stateful servers need to manage state" to answer this question. That's true, but it doesn't really get around the answering the question.
This page last modified on 14 April 2003.