Wed, 26 Apr 2000 10:01:08 -0700 (PDT)

Dear Prof. Geoff,

Please find the 7th Evaluation in the
email. And thanks for your advice on mobile

Yours sincerely

Zhanhai QIN


Mailing addr:
9152-F Regents Rd.
La Jolla CA-92037

Office addr:
VLSI CAD Lab (4550)
Applied Physics & Mathematics bldg.


1. Overview
Emerald is an objected-based language for the construction of distributed
programs. The goal of Emerald is to be competitive with standard languages
in local case and standard remote procedure call systems in the remote case.
The key points of Emerald are that 1) Emerald is uniformal-object-based, and
the unit of distribution and mobility is the object; 2) Emerald has language
support for mobility. Emerald is friendly to users in the sense that it is a
single-object model. In other words, users use single semantics for defining
all objects. Although there are multiple implementations, namely global objects,
local objects and direct objects, the Emerald compiler will automatically
generate an appropriate implementation. On the other hand, to optimize the
performance, Emerald allows users to explicitly specify their prefered
mobility scheme. For example, the Emerald programmer may specify explicitly
which objects move together and when handling parameter passing, they may
decide that an object should be moved on the basis of knowledge about the
application. The major effort of paper was focused on how mobility in Emerald
was implemented. The paper addressed the object implementation and addressing
(the implementation relies heavily on shared memory all objects on a single
node execute within a single address space), finding objects based on the
concepts of forwarding addresses, finding and translating pointer with the
help of templates for object data areas, moving objects across nodes, and
simplified garbage collection due to mobility.

2. Evaluation
One contribution of the paper was that objects in Emerald, could be moved
across different nodes. Moving processes across different nodes was not a new
idea, but the Emerald allowed objects to be moved partially, without moving
the process code in the objects. That could be efficient, though internode
communication burden was aggravated. Another contribution I think was that
they tightly coupled the compiler with run-time kernel so that in one hand,
mobility allowed us to take advantage of distribution and dynamically changing
environment, on the other hand, the performance of local operations would not
degrade to much.

1. Overview
The authors discussed their experience when using Grapevine and described
potential improvement to a couple of aspects of Grapevine. The main purpose
of Grapevine is delivering email but provides resource location, naming and
authentication on the Internet, and also access control. Registration database
holds user name, password(for authentication) buffer locations(inboxes) and
IP address(for servers). Basicly, Grapevine makes sure who you are before
giving you your mail. Grapevine is implanated as server code and user code.
Server side is really two separate ports registration server( which hold
registries - registration dBs) and message servers. User side does transparent
resource location. User prepares message - client program does resource location
to find message server, sends to message server. Message server calls registration
server to locate destination's message server (server willing to buffer inbox)
message sent sent to message server. Message server returns error if no such
user. Changes to registries are done by client software on administrator's
machine which locates a server. Server then propagates the updata to all other
replicated servers via Grapevine messages. normally, latest timestamp wins (on
registry updates) but on same creation, earliest wins. (They rely on name
creation to be centralized since atomic updates are difficult.)
2. Evaluation