The List of Submitted Questions
1. Given that a remote procedure call is fundamentally different than a local procedure call, in terms of both the semantics of parameter passing/returning and the length of time it takes to complete, is it a good idea to make them look the same? The Scheme programming language adopts the convention of adding an exclamation mark to functions, which alter state (e.g. set!) to remind the programmer that they are to be used judiciously; it might similarly be wise for a programming language to distinguish remote procedure calls to deter overuse.
2. Now that there are commonly available RPC systems (e.g. Java RMI), how much do they get used in practice? Does the trend toward web-based programs make use of RPC? If not, is it for lack of a suitable implementation?
3. Is there a mechanism to cancel a RPC in the case that the server deadlocks or loops ?
4. How does grapevine authenticate the changes made to it. ie How do you prevent a bogus server from exporting their procedures via grapevine ?
5. In exception handling, the user is not told whether a failure indicates a function was executed just once or maybe not at all. Isn't this a problem for functions that update data?
6. What are examples of applications that require RPC? I can imagine maybe a certain function being exported to a system having more resources, but isn't this mechanism actually useful only to a very narrow stream of applications because of the communication over head?
7. Why not use a standard protocol for RPC? It would save a lot of work of defining a new protocol (and half the paper...) e.g. TCP in the normal case (no loss) behaves quite similarly to their protocol, so it shouldn't really be worse.
8. Is there a better paradigm? Procedure calls are serial in nature, and that could encourage development of low-performance distributed applications, especially over WAN. (Windows RPC over DSL comes to mind...)
9. I would like to ask about the efficiency of the RPCs implementation. Do you think the procedure calls implemented are simple enough for communication to be fast and is that true?
10. For the packet-level transport protocol, could we use other transport protocols like TCP, UDP instead of the protocol PUP?
11. On the page, when a the caller's user-stub is making a call on an imported remote interface, the call packet it manufactures contains the unique identifier and table index of the remote interface, and the entry point number of the desired procedure in the interface. The callee side will use the procedure entry point number to select the procedure to run. Therefore it is very important that the interfaces on the caller and the callee match. Grapevine`s access controls allows only certain machines to export interfaces based on their names but not on the content of these interfaces. What can be done in the presented implementation to make sure that the caller and callee have matching interfaces?
12. Grapevine is used as their discovery tool, their authentication management tool, and their encryption tool? Do you think it is a good idea to have made their RPC package depend on Grapevine that much ? How could they be decoupled?
13. Maybe security wasn't a huge concern but encryption and playback protection aren't good enough. Couldn't someone forge their host information and register an RPC with Grapevine and use it to steal information? Maybe it's because all this process is automated b the compiler generated code to manage user/server stubs?
14. It's interesting that they designed a specific light weight protocol to meet RPC needs but do we really need it? It is mentioned later on in the paper that in a worst case this protocol would actually transmit twice as many packets as needed. I know we always make sure the worst case rarely happens but how can we really predict future network traffic and behavior?
15. Why the procedure call was decided as the paradigm used for the control and data transfer? For example, in modern language, why we do not use message passing?
16. I wonder whether there is congestion control technique to manipulate congestion?
17. For figure 4, if the caller machine crashes before it send ack for result packet, what will happen? I know callee machine would retransmit the result packet. But after the caller machine reboot, how callee machine do with this situation ? Do you have some idea to inform the callee machine about it?
18. There are a lot of ways to increase network security, such as encryption. Why the author did not use this on this system ? Do you think the mentioned authorization way is enough for the system security?
19. Just like others, I am also interested in protocols of this system. I think we could modify TCP/IP to have similar functions. What is your idea ?
20. During the time of the paper, the Grapevine DB was used in order to act as a medium for the RPc calls. Fast forward a few decades, and we now use things like Java's innate RPC methods, which while innovative in its own ways, still relies on requiring some sort of shared commonality, in this case Java's VM. Do you foresee there being any way of doing RPC calls on completely different platforms without the need for mediums, or is it the nature of the beast, as it were?
21. With the RPC design envisioned in the paper, what sort of changed would be needed to implement OO RPC(beyond some minor headaches with marshalling order and stack handling, that is)?
22. How does the RPC described in the paper differs from the RMI feature in Java (other than the fact that the RPC method in he paper uses a separate well-known server to locate the RPC servers).
23. Can we implement a P2P RPC protocol? What factors o we need to consider in terms of securities?
24. If a callee (server) is blocked it can not send any more messages or receive any new requests. How could the model be redesigned to get around this problem. I.e. how could you make a non-blocking server? To help you a bit: Do you think that the server should take care himself of the incoming requests? Do you think that having k servers would solve the server-blocking problem? In that case, what would be the optimal k?
25. How would you compare RPCRuntime with TCP and UDP? Which one of the TCP, UDP do you think it is closer to?
26. In which cases would you hardcode the explicit addresses, and in which would you use Grapevine?
27. What is different in binding mechanism between RPC and RMI, and between RPC and COBRA?
28. How has the RPC mechanism changed after the paper was published? When I read Section 3.3, I wanted to know if the transport protocol changed or not. Thus, I searched the Internet and found that RPC is implemented based on TCP, and other keywords such as SOAP and XML-RPC. So I was wondering what the current status of RPC mechanism and application is.
29. Was there any attempt in constructing an asynchronous remote procedure call, which seems to be a probable solution to increase parallelism in a distributed system?
30. With today's hardware performance, is there still any incentive to optimize remote procedure call by bypassing the layered protocol hierarchy?
31. Binding is not allowed at a finer grain than an entire interface. They have claimed that binding in finer levels is useless. Is this statement still true in the present time considering the changes over time? Are there any cases in which binding in a finer grain might be useful?
32. What is the relationship between stubs and adaptors (from the past papers)?
33. In the paper, on page 46, there is a description of a (relatively) slow startup procedure for exporting interfaces. This limits a machine to an average of 1 Export Interface call per second. What is the benefit of such a slow startup? Is it related to the Grapevine database and its data replication? If it is purely a technology related issue, are those issues gone now and we have faster startup of RPC code?
34. The authors describe an elaborate mechanism for handling exceptions (signals) within their RPC implementation. This seems to be an outgrowth of the nature of Mesa. Is the modern equivalent of RPC able to handle exceptions/signals/interrupts or has this feature been "lost"?
35. In the year that the paper was written (1984), comms was pretty expensive and in fact the benchmarks in the paper showed that the overhead for doing RPC was quite high when compared to doing the same call locally. How could they justify doing more work despite this result?
36. Would this particular version of RPC be vulnerable to a man-in-the-middle attack? The Grapevine database appears to be central to managing the different servers on the network.
37. For what types of applications or remote calls would this RPC abstraction be inappropriate?
38. The authors state that the stub mechanism allows full location transparency. Could we implement some scheduling system to offload function calls to remote servers when the local server is under heavy load?
39. In their performance results, why did Birrell and Nelson omit measurement of maximum cycle counts?
40. This paper focuses on RPC over a reasonably reliable network with a (for the era) high-speed connection. How might their proposal change for a more distributed (as opposed to clustered) scenario?
41. One of the design goals of the RPC was to prevent programmers from thinking that communication over the network is too expensive, lest "... application designers strenuously avoid it." Regardless of whether this goal was met at the time, do you think this criterion is filled today? Is it not the case that many application designers go to great lengths to avoid RPCs and other forms of network communication if they can avoid it? If this is the case, is it 'misleading' to dress up network communication in such a way that it resembles a programming construct that is generally very efficient (local procedure call)?
42. No discussion here is made of asynchronous RPCs. Why do you think that this logical extension was not even mentioned of asynchronous calls?
43. The authors mention that their protocol does not work well when delivering large payloads of data, and wonder if it is possible to design a general-purpose protocol that does well both with 'small' and 'big' RPCs. Most RPCs today are delivered via TCP/IP: Would you argue that it has or does not have this property?