[3] in 6.033-lab
Overview of papers
daemon@ATHENA.MIT.EDU (Constantine P. Sapuntzakis)
Thu Mar 6 06:17:33 1997
To: 6.033-lab@MIT.EDU
Date: Thu, 06 Mar 1997 06:18:06 EST
From: "Constantine P. Sapuntzakis" <csapuntz@MIT.EDU>
I thought the papers showed a good bit of thinking, though most designs
had a couple holes. Here were a couple of points found in the best designs papers:
1) They handled server crash and restart as well as client crash and
restart. See Tanenbaum for a discussion on how to handle this.
2) They had a way, in the protocol, to notify the client that some error
had occured with the RPC call (be it a buffer overflow or a server
restart)
3) They sent fewer packets. The most minimal designs, like the Birrell
paper, had just a request and a reply in the fast case. The next
client request acted as the acknowledgment for the previous reply.
4) They discussed the state necessary to keep on the server and client.
This can be tricky - how many past replies do you need to keep on the
server? and how many past unique RPC IDs do you need to keep track of on
the client?
Other notes:
The blast protocol most people chose is a very anti-social one for the
network. If the computer sends out packets at too quick a rate, many
will be dropped because of congestion, but not before they cause pain
in the rest of the network.
Notes on writing:
The 6.033 design project assignments will be handed out today. Take a
look at the setion on how to write up the design projects - it provides
some good guidelines for this writeup too.
For the final paper, you need to write with your recitation instructor
as the audience. Mostly, they will be reading your design papers for clear
arguments as to why each field in your packets and why each bit of state
kept on the server is necessary for the correctness of the protocol.
They will most likely not be interested in the low-level C or C++ code,
though they may be interested in higher-level
implementation details, such as how state is kept around on the
servers.
You should clearly state the motivation for implementing RPC (no -
that's not getting an A in the lab) as well as the requirements which
fed into your design. This will help them appreciate your design in
context.
Diagrams will help clarify many of the problems that arise.
Finally, try to make the prose as crisp as possible. To reinforce this,
I recommend revisiting the Gopen paper on scientific writing before you
embark on your final write-up.
Finally, you should have started coding already. This lab is going to
take a good bit of time to get right and you have less that two weeks left.
Feel free to use the list (6.033-lab) to discuss problems - especially
implementation issues that arise.
Good luck!
-Costa
csapuntz@mit.edu
