Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!dciem!martin From: martin@dciem.UUCP (Martin Tuori) Newsgroups: net.unix-wizards Subject: Re: Any details on "the Newcastle Connec - (nf) Message-ID: <232@dciem.UUCP> Date: Wed, 1-Jun-83 14:28:46 EDT Article-I.D.: dciem.232 Posted: Wed Jun 1 14:28:46 1983 Date-Received: Wed, 1-Jun-83 16:22:19 EDT References: uiucdcs.2145 root44.2290 Lines: 51 I'd like to respond to some of the points raised in John Collins review of the networking software called 'The Newcastle Connection', aka 'Unix United' from The U. of Newcastle. I visited Newcastle two months ago, and had a good look inside their system. His items 1,2, and 5 question some of the implementation decisions, and the resulting performance of the software. The current version of TNC was deliberately implemented in user code, to maximize its portability. It can be moved to a new UNIX on a new machine much more quickly than if it had been placed in the kernel. The folks at Newcastle expect that the big vendors will choose to re-implement it more efficiently to suit their individual systems. In item 2, John raises the question of cost of recompilation when a new version comes along. I don't see that this is any different from other network software architectures; if 3COM sends you a new distribution of UNET, you will have to recompile every program that uses the network -- same result. I can assure you that TNC works, and that file creation, I/O, process activation, and signals are properly handled. What is surprising about the scheme is how easily everything follows from what is a very simple idea -- extending the filesystem namespace to include other systems' filesystems. The recent article in Software -- Practice and Experience did not prepare me for how easy TNC is to use. Herein lies its strength; a user wishing to use the network need learn one main rule -- the extended name space. Thereafter the commands, their arguments, and their combination by pipes, redirection, etc. follow normal UNIX conventions. In other network schemes I have used, the user is forced to learn a new syntax for file transfer, and new syntax for remote execution, etc. This saving in learning time is, to me, THE KEY ISSUE; implementation details are secondary. One last comment that came up in talking with people at Newcastle -- the hardest and most confusing parts of TNC arise from those parts of the user-to-UNIX dialogue that are not part of the filesystem namespace. Files, directories and devices are straightfoward; but if you want to mail to john on machine b, mail /../b/john isn't right. Mail uses a namespace separate from the filesystem, ie. the password file. Similarily, ps and kill operate on yet another namespace, numerical process ids; so you cannot say 'kill /../b/4073'. Both of these namespaces could be incorporated into the normal namespace, by provision (as for devices) of stubs -- say /procs/4073, and /users/john. The unifying concept of the UNIX filesystem could be carried a step further. I suppose it's obvious that I think very highly of their work. In fairness, it's not a new idea; I can remember similar suggestions arising several years ago. But I hope it's an idea that will bear fruit this time. I look forward to more discussion. Martin Tuori ...decvax!utzoo!dciem!martin