From: David Coleman \(Roxio Inc\) (v-davcol_at_windows.microsoft.com)
Date: Mon Feb 02 2004 - 17:09:16 PST
The Grapevine paper by Schroeder, Birrel, and Needham describes the operational results of a distributed system that provides naming, locator, authentication, access control and message services. This paper focuses on how well the original design stood up under several years of operation.
Several points jump out at me from this paper. It is very interesting that they conceived of a central registry/directory service in the first place. I do not know if this was a landmark idea at the time, but given the paucity of networks, I cannot believe they were widely discussed. The usefulness of having a central registry for both resource location, authentication, ACL, etc. is obvious now; when the system was conceived it had to be a fairly new idea. This system was very distributed and intended to be very robust in the face of communication failures due to unreliable connections. The range of transmission speeds across different connections between servers differs by about three orders of magnitude. It
The focus on scalability was also very interesting. I thought it was very insightful to realize that networks and user bases grow quickly and thus the infrastructure must be able to grow with them. However, I think their overall approach seemed a little naïve. To calculate the number of servers by looking at individual server capacity, estimate maximum load and then divide the two to determine number of servers overlooks several factors. First, there is overhead to having additional servers on the network. Much like adding engineers doesn't necessarily make a task go faster due to increased communication, adding servers that automatically replicate information also increases the communications overhead. Also, they probably needed to take communication speed into account for scalability issues. For reliability, they did factor in the robustness of communication links when determine where physically to locate resources. They needed similar analysis for speed of links.
Their experiences with e-mail messages and distribution lists growing much quicker than planned were humorous given today's glut of e-mail. Their comment, "At some point the number of messages arriving for a user would start to overwhelm both the user and the system." seems somewhat prescient given the overwhelming amount of (probably useless) e-mail traffic today. It was also interesting that they ran into the situation where users were storing their e-mail on the server by dialing in even when connected to the network. Even though random access and message storage was obviously important to users, they refused to alter their design.
The debugging and operational tools were very cool. Identifying the need for remote debugging, rebooting, and generally performing server maintenance was once again somewhat ahead of their time. This lesson was apparently forgotten for a while by the system designers that came after them.
Grapevine was an interesting system to read about. I would actually like to go back and read the original paper describing the design of the system as this paper didn't answer some of the questions I had (such as how did the GrapevineUser package locate registries if nothing was hardcoded/entered by the user - system broadcasts?). Their comment about not actually implementing proposed system changes due to minimizing risk showed some software process maturity. However, their comment about also avoiding changes because they couldn't remember how the system worked did not.
This archive was generated by hypermail 2.1.6 : Mon Feb 02 2004 - 17:09:17 PST