Software concepts

    Tightly vs. loosely coupled

        High autonomy and low communication characterize loose
        coupling

    Network Operating Systems

        Loosely coupled software and hardware

        Autonomous workstations on a LAN

        Commands normally run locally

        Remote login and remote execution possible (rlogin, rcp, rsh)

        Next step is to have a shared file system.

            Have file SERVERS that export filesystems to CLIENTS on
            the LAN.

            Client makes a request to server, which sends a response.

            Example from unix:  Unix file structure is a tree (really
            dag).  Dos is a forest (a: c: not connected).  For local
            disks, unix supplies mount to make one file system part of
            another.  To get the shared file system, the idea is to
            mount remote filesystems locally.  The server exports the
            filesystems to the clients, who do the mount.

            Client decides where to mount the fs.  Hence the same
            filesystem can be mounted at different places on different
            clients.

            This fails to give location transparency.

            An example from my research group (a few years ago)

                We had several machine all running unix.  Named
                after the owner: allan, eric, richard, jan, jim, susan
                and one other called lab.  We had several
                filesystems that were for common material /a /b /c.
                I remember that allan.ultra.nyu.edu had /e and
                exported it to other machines.  Our convention was
                to mount /e on /nfs/allan/e but have a link
                /e --> /nfs/allan/e so on all machines /e got you
                to the same place.

                However there were two system filesystems / and
                /usr that were on all machines (a little different
                on each).  For sysadmin we wanted all these
                assessible to all our admins.  So on allan I would
                have jim's /usr mounted on /nfs/jim/usr.  I could
                not link /usr --> /nfs/jim/usr.  Why?
                The name I used was /jim.usr but that is not
                location transparent.

            Another example from same place.

                To save disk space we kept only one copy of
                /usr/gnu/lib/emacs.  It was stored on lab in
                /d/usr.gnu.lib/emacs and everyone mounted /d and
                linked /usr/gnu/lib/emacs -->
                /d/usr.gnu.lib/emacs.

                Problem: When lab was down, so was emacs!

                So we went to several severers for this.  All
                controled manually.

            Reads and writes are caught by the client and requests
            made to the server.  For reads the server respondes by
            giving the requested data to the client, which is then
            used to satisfy the read

            Text gives detailed description of NFS implementation.  We
            will defer this until chapter 13 (distributed filesystems)
            where it belongs.

        Is a network OS a dist system?

    True distributed systems (according to st. andrew)

        (Comparatively) tightly-coupled software on loose-coupled
        hardware

        Goal is to make the illusion that there is a single computer.

        Single-system image

        Virtual uniprocessor

HOMEWORK 9.6

        Many scientists use the term single-system image or virtual
        uniprocessor even if the hardware is tightly coupled.

        Official (Modern OS) def: A DISTRIBUTED SYSTEM is on that runs
        on a collection of machines that do not have shared memory,
        yet looks to its users like a single computer.

        The newer book (Dist OS) uses the def we gave earlier: A
        distributed system is a collection of independent computers
        that appears to the users of the system as a single computer.


        Single IPC (interprocess communication) mechanism.

            Any process (on any machine) can talk to ANY other process
            (even those on another machine) using the same procedure.

        Single protection scheme to protect all objects

            Same scheme (ACL, unix rwx bits) on all machines.

        Consistent process management across machines.

        File system looks the same everywhere.  Not only the same name
        for a given file but, for example, the same rules for
        filenames.

        Easiest to do if all the machines are the same so the same
        operating system can be run on each.  However, there is
        considerable work on "heterogeneous computing" where (in
        principle at least) different computers are used.

            For each program, have a separate binary for each
            architecture.

            What about floating point formats and wordsize?

            What about byte order?

            Autoconvert when doing ipc

        Even when the each system is the same architecture and runs
        the same OS, one may not want a centralized master that
        controls everything.  

            Paging is probably best done locally (assuming a local
            disk).

            Scheduling is not clear.  Advantages both ways.  Many
            systems have local scheduling but communication and
            process migration for load balancing.