Evaluations: 04/27

Bianca ZADROZNY (zadrozny@cs.ucsd.edu)
Thu, 27 Apr 2000 07:56:19 -0700 (PDT)

Experience with Grapevine: The Growth of a Distributed System
-----------------------------------------------------------------

This paper describes the operation of Grapevine, a distributed system that
operates in an internet and provides registration and message services.
The paper enumerates the characteristics of the system that make it
scalable, together with the ones that limit its growth. It also suggest
changes that could be made to the system in order to improve its
scalability. Many of the limitations of the system were only noticed when
the system was working under substantial load. This paper is important
because it allows designers of new systems to be aware of the problems
that can happen when the system grows, so that they can make the
appropriate design decisions.

The registration service maps names to the system objects assigned to
them, including users, machines services, distribution lists, etc. This is
implemented as a two-level hierarchy: each name is a combination of a
registry name and a name within that registry. The registries are
distributed and replicated in different registration servers. This
two-level hierarchy allows the system to be more scalable with respect to
the number of names permitted. It is not necessary to increase the disk
space on servers when the number of names grows. New registries can be
created to accomodate a larger number of names, and more servers are added
to the system when the number of registries gets too large. The paper
suggests that another layer on the naming hierarcy might be needed if the
number of users is larger than what was specified for the system.

The message service delivers messages to individual recipients and
distribution lists. Messages are kept on inboxes in different servers,
until the receiver retrieves them. Any server can deliver a message, and
any server that has an inbox for a recipient can accept retrieval requests
for that recipient. However, distribution lists have not scaled well in
the system. As the number of users grew, the number of users belonging to
certain distribution lists also grew proportionally. Since the names in a
list are not generally correlated with the names in a registry, the
message server takes a long time looking up all the names in the
distribution list on different registration servers. The paper suggests
that a level of indirection be added to handle such lists. In this way,
there would be a subgroup of users in each server that are subscribed to
the lists. Then, the list would be implemented as a group pointing to the
subgroups in each registry.

I think this paper offers very useful lessons about scalability and
reliability of large distributed systems. However, I did not like the
organization of the paper. Instead of learning about the details of this
particular system, I would prefer to see a summary of the main benefits
and pitfalls of the system, along with suggestions on how to improve it.

------------------------------------------------------------------------------

Fine-Grained Mobility in the Emerald System
----------------------------------------------

This paper describes Emerald, an object-oriented language and system which
support object mobility within the system. This is important because
besides having the same advantages of a system that provides process
migration, object mobility allows the programmer to transfer data around
the system in a simple way. Another important characteristic of Emerald is
that the performance of local execution is not affected by the fact that
the system provides mobility.

The Emerald language provides primitives that allow the programmer to
explicitly move objects around the system. An interesting construct of the
language is the call-by-move parameter-passing mode. In this mode, the
arguments objects are sent together with the invocation request, which
optimizes performance.

One major difficulty in implementing object mobility is how to efficiently
keep track of process activation records when the objects that are invoked
can move freely in the system. The solution provided in the paper was to
delay the linking of the objects to the process activation record until
the process was pre-empted.

I think this paper is very well-written and easy to follow. I like the
idea of providing object mobility and I think the paper emphasizes
important trade-offs that were made when the system was designed. One
thing that I found strange is that the system does not provide any
constructs to control access to objects, such as capabilities.