Department of Computer Engineering

SEM- VIII Distributed Computing

Module - 4
Code Migration

Traditionally, code migration in distributed systems took place in the form of process
migration in which an entire process was moved from one machine to another. Moving a
running process to a different machine is a costly and intricate task, and there had better
be a good reason for doing so. That reason has always been performance. The basic idea
is that overall system performance can be improved if processes are moved from
heavily-loaded to lightly-loaded machines. Load is often expressed in terms of the CPU
queue length or CPU utilization, but other performance indicators are used as well. Load
distribution algorithms by which decisions are made concerning the allocation and
redistribution of tasks with respect to a set of processors, play an important role in
compute-intensive systems. However, in many modern distributed systems, optimizing
computing capacity is less an issue than, for example, trying to minimize communication.
Moreover, due to the heterogeneity of the underlying platforms and computer networks,
performance improvement through code migration is often based on qualitative reasoning
instead of mathematical models. Consider, for example, a client-server system in which
the server manages a huge database. If a client application needs to do many database
operations involving large quantities of data, it may be better to ship part of the client
application to the server and send only the results across the network. Otherwise, the
network may be swamped with the transfer of data from the server to the client. In this
case, code migration is based on the assumption that it generally makes sense to process

Code Migration Ashvini Gaikwad

 Department of Computer Engineering
SEM- VIII Distributed Computing

data close to where those data reside This same reason can be used for migrating parts of
the server to the client. For example, in many interactive database applications, clients
need to fill in forms that are subsequently translated into a series of database operations.
Processing the form at the client side, and sending only the completed form to the server,
can sometimes avoid that a relatively large number of small messages need to cross the
network. The result is that the client perceives better performance, while at the same time
the server spends less time on form processing and communication. Support for code
migration can also help improve performance by exploiting parallelism, but without the
usual intricacies related to parallel programming. A typical example is searching for
information in the Web. It is relatively simple to implement a search query in the form of
a small mobile program that moves from site to site. By making several copies of such a
program, and sending each off to different sites, we may be able to achieve a linear
speed-up compared to using just a single program instance. Besides improving
performance, there are other reasons for supporting code migration as well. The most
important one is that of flexibility. The traditional approach to building distributed
applications is to partition the application into different parts, and deciding in advance
where each part should be executed. However, if code can move between different
machines, it becomes possible to dynamically configure distributed systems. For
example, suppose a server implements a standardized interface to a file system. To allow
remote clients to access the file system, the server makes use of a proprietary protocol.
Normally, the client-side implementation of the file system interface, which is based on
that protocol, would need to be linked with the client application. This approach requires

Code Migration Ashvini Gaikwad

 Department of Computer Engineering
SEM- VIII Distributed Computing

that the software be readily available to the client at the time the client application is
being developed. An alternative is to let the server provide the client’s implementation no
sooner than is strictly necessary, that is, when the client binds to the server. At that point,
the client dynamically downloads the implementation, goes through the necessary
initialization steps, and subsequently invokes the server. This principle is shown in Fig.
3-7. This model of dynamically moving code from a remote site does require that the
protocol for downloading and initializing code is standardized. Also, it is necessary that
the downloaded code can be executed on the client’s machine. Different solutions are
discussed below and in later chapters. The important advantage of this model of
dynamically downloading client side software, is that clients need not have all the
software preinstalled to talk to servers. Instead, the software can be moved in as
necessary, and likewise, discarded when no longer needed. Another advantage is that as
long as interfaces are standardized, we can change the client-server protocol and its
implementation as often as we like. Changes will not affect existing client applications
that rely on the server. There are, of course, also disadvantages. Blindly trusting that the
downloaded code implements only the advertised interface while accessing your
unprotected hard disk and does not send the juiciest parts to heaven-knows-who may not
always be such a good idea.

Code Migration Ashvini Gaikwad

 Department of Computer Engineering
SEM- VIII Distributed Computing

Models for Code Migration

Although code migration suggests that we move only code between machines, the term
actually covers a much richer area. Traditionally, communication in distributed systems is
concerned with exchanging data between processes. Code migration in the broadest sense
deals with moving programs between machines, with the intention to have those
programs be executed at the target. In some cases, as in process migration, the execution
status of a program, pending signals, and other parts of the environment must be moved
as well. In this framework, a process consists of three segments. The code segment is the
part that contains the set of instructions that make up the program that is being executed.

Code Migration Ashvini Gaikwad

 Department of Computer Engineering
SEM- VIII Distributed Computing

The resource segment contains references to external resources needed by the process,
such as files, printers, devices, other processes, and so on. Finally, an execution segment
is used to store the current execution state of a process, consisting of private data, the
stack, and the program counter. The bare minimum for code migration is to provide only
weak mobility. In this model, it is possible to transfer only the code segment, along with
perhaps some initialization data. A characteristic feature of weak mobility is that a
transferred program is always started from its initial state. This is what happens, for
example, with Java applets. The benefit of this approach is its simplicity. Weak mobility
requires only that the target machine can execute that code, which essentially boils down
to making the code portable. We return to these matters when discussing migration in
heterogeneous systems. In contrast to weak mobility, in systems that support strong
mobility the execution segment can be transferred as well. The characteristic feature of
strong mobility is that a running process can be stopped, subsequently moved to another
machine, and then resume execution where it left off. Clearly, strong mobility is much
more powerful than weak mobility, but also much harder to implement. An example of a
system that supports strong mobility is D’Agents, which we discuss later in this section.
Irrespective of whether mobility is weak or strong, a further distinction can be made
between sender-initiated and receiver-initiated migration.
In sender initiated migration, migration is initiated at the machine where the code
currently resides or is being executed. Typically, sender-initiated migration is done when
uploading programs to a computer server. Another example is sending a search program
across the Internet to a Web database server to perform the queries at that server. In

Code Migration Ashvini Gaikwad

 Department of Computer Engineering
SEM- VIII Distributed Computing

receiver-initiated migration, the initiative for code migration is taken by the target
machine. Java applets are an example of this approach.
Receiver-initiated migration is often simpler to implement than sender initiated
migration. In many cases, code migration occurs between a client and a server, where the
client takes the initiative for migration. Securely uploading code to a server, as is done in
sender-initiated migration, often requires that the client has previously been registered
and authenticated at that server. In other words, the server is required to know all its
clients, the reason being is that the client will presumably want access to the server’s
resources such as its disk. Protecting such resources is essential. In contrast, downloading
code as in the receiver-initiated case, can often be done anonymously. Moreover, the
server is generally not interested in the client’s resources. Instead, code migration to the
client is done only for improving client-side performance. To that end, only a l
imited number of resources need to be protected, such as memory and network
connections. In the case of weak mobility, it also makes a difference if the migrated code
is executed by the target process, or whether a separate process is started. For example,
Java applets are simply downloaded by a Web browser and are executed in the browser’s
address space. The benefit of this approach is that there is no need to start a separate
process, thereby avoiding communication at the target machine. The main drawback is
that the target process needs to be protected against malicious or inadvertent code
executions. A simple solution is to let the operating system take care of that by creating a
separate process to execute the migrated code. Note that this solution does not solve the
resource-access problems just mentioned. Instead of moving a running process, also

Code Migration Ashvini Gaikwad

 Department of Computer Engineering
SEM- VIII Distributed Computing

referred to as process migration, strong mobility can also be supported by remote cloning.
In contrast to process migration, cloning yields an exact copy of the original process, but
now running on a different machine. The cloned process is executed in parallel to the
original process. In UNIX systems, remote cloning takes place by forking off a child
process and letting that child continue on a remote machine. The benefit of cloning is that
the model closely resembles the one that is already used in many applications. The only
difference is that the cloned process is executed on a different machine. In this sense,
migration by cloning is a simple way to improve distribution transparency.
The various alternatives for code migration are summarized in Fig. 3-8.

Code Migration Ashvini Gaikwad