Session 2018-19 (EVEN)

Creative Assignment for Distributed Operating System

Topic: Spring, Galaxy, Locus

Spring Distributed OS
Spring is a discontinued project/experimental microkernel-based object oriented operating
system developed at Sun Microsystems in the early 1990s. Using technology substantially similar to
concepts developed in the Mach kernel, Spring concentrated on providing a richer programming
environment supporting multiple inheritance and other features. Spring was also more cleanly
separated from the operating systems it would host, divorcing it from its Unix roots and even
allowing several OSes to be run at the same time. Development faded out in the mid-1990s, but
several ideas and some code from the project was later re-used in the Java programming
language libraries and the Solaris operating system.

History
Spring started in a roundabout fashion in 1987, as part of Sun and AT&T's collaboration to
create a merged UNIX, both companies decided it was also a good opportunity to "reimplement
UNIX in an object-oriented fashion". However, after only a few meetings, this part of the project
died. Sun decided to keep their team together and instead explore a system on the leading edge. In
addition to combining Unix flavours, the new system would also be able to run just about any other
system as well, and do so in a distributed fashion. The system was first running in a "complete"
fashion in 1993, and produced a series of research papers. In 1994 a "research quality" release was
made under a non-commercial license, but it is unclear how widely this was used. The team broke
up and moved to other projects within Sun, using some of the Spring concepts on a variety of other
projects.

Background
The Spring project started soon after the release of Mach 3. In earlier versions Mach was
simply a modified version of existing BSD kernels, but in Mach 3 the Unix services were separated
out and run as a user-space program like any other, a concept Mach referred to as a server. Data
which would normally be private in the kernel under a traditional Unix system was now passed
between the servers and user programs using an inter-process communication (IPC) system, ending
in ports which both programs held. Mach implemented these ports in the kernel, using virtual
memory to move data from program to program, relying on the memory management unit (MMU)
and the copy on write algorithm to do so with reasonable performance.

Advantages
Communication and resource sharing possible
Economics – price-performance ratio
Reliability, scalability
Potential for incremental growth
Disadvantage
Distribution-aware PLs, OSs and applications
Network connectivity essential
Security and privacy

Locus Distributed OS
LOCUS is a discontinued distributed operating system developed at UCLA during the
1980s. It was notable for providing an early implementation of the single-system image idea, where
a cluster of machines appeared to be one larger machine. A desire to commercialize the
technologies developed for LOCUS inspired the creation of the Locus Computing
Corporation which went on to include ideas from LOCUS in various products, including OSF/1
AD and, finally, the SCO–Tandem UnixWare Non Stop Clusters product.

Description
The LOCUS system was created at UCLA between 1980 and 1983, initial implementation
was on a cluster of PDP-11/45s using 1 and 10 megabit ring networks, by 1983 the system was
running on 17 VAX-11/750s using a 10 megabit Ethernet. The system was Unix compatible and
provided both a single root view of the file system and a unified process space across all nodes.

File System

In order to allow reliable and rapid access to the cluster wide file system LOCUS
used replication, the data of files could be stored on more than one node and LOCUS would keep
the various copies up to date. This provided particularly good access times for files that were read
more often than they were written, the normal case for directories for example.In order to ensure
that all access was made to the most recent version of any file LOCUS would nominate one node as
the "current synchronization site" (CSS) for a particular file system. All accesses to files a file
system would need to be coordinated with the appropriate CSS.

Node dependent files

As with other SSI systems LOCUS sometimes found it necessary to break the illusion of a
single system, notably to allow some files to be different on a per-node basis. For example, it was
possible to build a LOCUS cluster containing both PDP-11/45 and VAX 750 machines, but
instruction sets used were not identical, so two versions of each object program would be
neededThe solution was to replace the files that needed to be different on a per node basis by
special hidden directories. These directories would then contain the different versions of the file.
Application
 Migrating processes from slower to faster nodes and from nodes that run out of free
memory.
 Automatic resource discovery and workload distribution by process migration
 Users can login on any node and do not need to know where their programs run
 Migratable sockets for direct communication between migrated processes
 Live queuing – queued jobs preserve their full generic Linux environment
Galaxy Distributed OS
The GALAXY distributed operating system aims at true network transparency both for the
local-area networks and for the wide-area networks. The basic mechanism to accomplish this is
the three-level object-naming scheme which has many features for reliability, efficiency, and
flexibility. Based on this naming scheme, a network-wide virtual address space called the uniform
address space is constructed. It facilitates smooth load and information sharing. The mechanisms
for unified data sharing and synchronization for this global address space are provided. The
provision of static and dynamic data replications is useful for improving both reliability and
performance. The process structure of GALAXY is efficient and flexible enough to realize a fine
grain of concurrency in single/multi-processor systems. Global process management based on
process migration is indispensable for the network-transparent distributed processing. In GALAXY,
an object-based environment is implemented on its process-based system architecture. The object
group is a key mechanism in an object-based environment to realize hierarchical, integrated
object processing and management. In this paper, we first discuss the design goals and
requirements of GALAXY, and then describe the main concepts and mechanisms for achieving
these requirements.

Application
 the web content service has two virtual service nodes: the one in seattle has twice as
much capacity as the one in tacoma.
 it provides a vulnerable ‘victim’ server to be attacked by malicious clients. Such an
attack emulation service is useful to the understanding and prevention of attacks in
the real world.

Submitted By: Pratik Wahane

Signature

Name: Pratik Wahane

Roll No: CS15055