Grapevine 

Grapevine is an early example of a distributed system. The paper describing 
Grapevine is an "experience" paper. The idea of distributed systems is not new at 
the time of writing, and the authors describe an implementation of and experience 
with Grapevine - a distributed system, which provides mail service, name to 
address translation (like DNS), and authentication. 

For me the value of reading this paper was in being able to see how distributed 
systems evolved in the last 17 years: which issues existed then, how they have been 
solved up to now, what are the areas that underwent changes, and what has stayed the 
same. 

The overall design of Grapevine can be summarized as follows: 

1. The Grapevine network consists of servers that offer registration and message 
services. Registrations services include name resolution (similar to modern 
DNS) and authentication (including some functions of the YP on Unix systems).   
Messaging services include buffering and delivering mail. Messages are buffered 
on servers until the user decides to retrieve them, and any server can accept a 
message for delivery. 

2. Mailboxes and registration databases are replicated among several servers.  
Each user has a primary and secondary mailbox for failover purposes. Registration 
database is replicated and distributed. Names are hierarchical (only on 2 
levels), and are represented with a dotted notation Name.Registry. The name space 
is divided into registries, such that registries mirror the administrative 
structure of the organization.  However, each registration server has to know the 
name of each registration and message server - and that is a scalability 
bottleneck.  In the modern Internet name directory (DNS) this has been solved by the 
use of hierarchical referrals (a server needs to know an IP address of any of the 7 
root DNS servers, which can refer it down through the hierarchy to a machine that 
would know how to resolve the name of interest). 

3. Grapevine servers had a capability of remote administration. It seems that 
there has been absolutely no progress made in the administration of computer 
systems since the time of Grapevine. The administration programs and facilities 
that were available at that time seem to have been able to provide as much service as 
the programs used by sysadmins today.  Maybe systems researchers should pay more 
attention to this area of research. (Although admittedly I do not find it very 
interesting). 

Mostly, the paper was not interesting to read because distributed systems have 
improved significantly from the times of Grapevine, and more or less acceptable 
solutions to the issues described in the paper have been already found. However 
there are a few things in the paper that I found entertaining. 

I thought that the facility that allowed an administrator to remotely fix a hard 
disk by looking at graphical display of disk blocks on the screen was very cool!  I 
would like to get my hands on something like this just for the purpose of studying 
file systems. 

In Grapevine each server provided both registration and messaging services. 
Designers thought that it might be a good idea to decouple those services and assign 
each one to a specialized machine responsible only for this service. They have not 
tried this themselves, but this is probably how things are down today in most 
organizations where the servers are highly loaded. 

It was interesting to note how the authors were concerned with the growing amount of 
messages that were circulated in their system: they were concerned that 
eventually the number of messages will become overwhelming for any server to 
deliver.  This problem has been solved by restricting users to mail servers within 
their administrative domain and replicating mail servers as necessary, as 
opposed to allowing any mail server accept messages for delivery. 

The designers of Grapevine recognized that it was a disadvantage that their 
servers did not know anything about the state of the internet when deciding which 
server to use for message delivery. This has been recognized as an important 
problem, and modern routers use various kinds of metrics when trying to calculate 
the best path to a particular node. 

It seems that most of the solutions used in this system came out of an engineering, 
rather than research environment, and most of them were quick fixes rather than 
results of well thought-out design.  This is another reason why this paper was not 
particularly interesting for me and was not very easy to follow. 
Grapevine:
email
directory
access control
resource allocation
(just like AOL)

Registry
	group of key-value pairs
Registration Server
	machine itself
	128kb, 5mb, 30um fn call
Registrar
	human being

Paper
experience paper.
how do they scale the system: they say it scales linearly.
they specifically address management; dialin administration
punted on:
	ok if you get two copies of message
	access control passes slowly -- loose consistency is ok
when a message was sent to many people, there was just one copy, and
then everybody got a pointer.


RPC
in 1984, people went from a variety of doing remote procedure calls to
doing it the way described in the paper.

Client packs up foo(7), sends over wire; server has large CASE stmt,
which then calls the right fn.  Client and server foo_stub()s are
generated automatically.
vs message passing and distributed shared memory.
arguments get pickled/serialized.