Newcastle Connection

The Newcastle Connection (or UNIX United) was a software subsystem from the early 1980s that could be added to each of a set of interconnected UNIX-like systems to build a distributed system. The latter would be functionally indistinguishable, at both user- and system-level, from a conventional UNIX system.[1][2] It became a forerunner of Sun Microsystems' Network File System (NFS). The name derives from the research group at Newcastle University, under Brian Randell, which developed it.

The term "UNIX United" describes the scheme of combining the overall filesystems of the participating UNIX machines; "Newcastle Connection" describes the undelying communication layer which enables this.[3] A UNIX United system constructed with the Newcastle Connection is functionally indistinguishable from a centralised UNIX system at the system-call level.[4]

In essence, the concept of the "parent directory" was re-interpreted at the root of the filesystem, where it originally had no significant meaning, to mean "this directory is on a remote machine", similar to subsequent "Super-root (Unix)" usage.

UNIX United

As a reminder, a typical single UNIX directory tree might resemble:

• /
  • home
    • brian (current directory '.')
      • a
      • b

UNIX United acts as an extra level the / root. If the example machine is named "unix1", an overall UNIX United scheme with an additional second machine, "unix2", would look like:

• /..
  • unix1
    • home
      • brian (the current directory '.')
        • a
        • b
  • unix2
    • home
      • brian
        • b
        • c

If we wish to copy file a from "unix1" to "unix2" to sit alongside files b and c, example equivalent commands might be:

• cp /home/brian/a /../unix2/home/brian/a
• cp a /../unix2/home/brian/a
• ( cd /../unix2/home/brian ; cp /../unix1/home/brian/a a )

Internals

It required no changes to the UNIX kernel. Rather, it ran in user-space, using a modified version of the C standard library of its day which was capable of recognising these new semantics. To a first approximation this was to recognise pathnames beginning with "/..". A match would divert such a reference through to the new software, which then used remote procedure calls to the remote machine. All other pathnames would simply go through to the local kernel as usual. (If the current working directory was itself remote, this needed to be taken into account.)

It did, however, require that all software intended to use it, including shells, the "cp" command, etc. needed to be re-linked with this new library.

Continuing one of the previous examples, the "cp" command attempts, as expected, to open the two files:

• open("a", ...)
• open("/../unix2/home/brian/a", ...)

Assuming the command has been relinked with the revised C-library, the first open() happens as normal on the local system. The second, however, is diverted into the "Newcastle Connection" software because of the filename's leading "/..".

Portability

The original implementation at Newcastle was for UNIX V7 on a set of PDP-11 computers connected by a Cambridge Ring network.[3] Subsequent implementations added support for other versions of UNIX (including BSD 4.2 and System V), network technologies, protocols and hardware architecture (VAX, Motorola 68000).[4]

References

1. Brownbridge, David R.; Marshall, Lindsay F.; Randell, Brian (1982). "The Newcastle Connection" (PDF). Software – Practice and Experience. 12: 1147–1162. doi:10.1002/spe.4380121206. Archived from the original (PDF) on 16 August 2016. Retrieved 23 December 2018.
2. Callaghan, Brent (2000). NFS Illustrated. Addison Wesley. ISBN 0-201-32570-5.
3. "The Newcastle Connection" (PDF). Newcastle University. Retrieved 24 December 2018.
4. Borghoff, Uwe M. Catalogue of Distributed File/Operating Systems. Springer. p. 49. ISBN 3642768806.