Arvind Santhanam (arvind@cwc.ucsd.edu)
Wed, 26 Apr 2000 19:04:54 -0700 (PDT)


Grapewine is a distributed, replicated system that provides
message delivery, naming, authentication, resource location and access
control services in an internet of computers. This paper throws light on
some of the virtues and vices of the Grapewine system.

Load is uniformly distributed among a large number of machines to
improve the efficiency of the system. The use of brief updates is a good
optimization and can conserve a good deal of system resources during peak
operating times. Grapewine also acts as a source of authentication and
controls access to information for the internet, by allowing the file
servers to check the user's credentials with Grapewine thereby
facilitating easy sharing of data. Incorporation of self-repairing
(correcting/ recovery) code would be a desirable feature in systems like
Grapewine which are prone to (occasional) system crashes. Grapewine
apparent failure to eliminate duplicate messages is still tolerable as the
alternative measure suggested might take a much longer time.

Reliability in Grapewine is provided by registry replication. The
Grapewine architecture seems reasonably stable (infrequent system
crashes), given its limited system resources and a large user population.
The grapewine system does scales well as the load of the system is
distributed system locally, although it seems like it wouldnt scale well
for a geographically wide area network, as it does not use parameters like
congestion on links, bandwidth available etc to compute the optimum routes
for message transfer. Active monitoring, control and repair functions
accessible through the internet are necessary for efficient and smooth
operation of Grapewine. The Grapewine system is not very amenable to
change and such rigid implementation would conflict with scalability and
other desirable features as dynamic reconfigurability, which are vital in
distributed environments.


Emerald is an object oriented language and system designed for the
construction of distributed programs. The main goals of Emerald are:

i. Language and run-time support for fine-grained object mobility.

ii. Efficient local execution.

iii. A single object model, suitable for programming both small, local
data-only objects and active, monile distribiuted objects.

The paper throws light on the object structure of Emerald,
discusses implementation issues pertaining to fine-grained mobility and
presents measurements drawing implications about the system design.
Distribution and (fine-grained) mobility can often result in performance
degradation of systems. Distributed object based systems are less.

Use of direct memory addresses in Emerald is a performance
optimization particularly for local invocations. The design also places
the price of mobility on those who use it, so in some sense there's an
equitable distribution of cost among users. The time taken by call-by-move
and call-by-visit are much lower than a call-by-remote-reference and are
perfomance optimizations with significant dividends. Emerald relies on
garage collection to recover memory occupied by objects that are no longer
reacheable. In distributed environments this is a tricky issue as the
object references can cross node boundaries.

The number of remote invocations with mobility in the mail system
is half of the system without mobility, which justifies the overheads
involved with each object in Emerald. The implementation of mobility in
Emerald involves trade-offs between the performance of mobility and more
fundamental mechanisms like local invocation. The number of network
packets sent and the total time elapsed are also significantly reduced.
Use of mobility of objects definitely shows improved performance as
reflected in Table 4, although the amount of data moved is sufficiently
high. Emerald is oblivious to network congestion and would not be suited
to run in large long-haul networks.