Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!rutgers!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcso!hpfcdc!daveg
From: daveg@hpfcdc.HP.COM (Dave Gutierrez)
Newsgroups: comp.sys.hp
Subject: Re: Booting discless over multiple LANs
Message-ID: <5570375@hpfcdc.HP.COM>
Date: 6 Feb 90 19:50:49 GMT
References: <3249@plains.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 50


The current design of HP diskless is to limit the cnodes to a single logical
LAN (i.e. repeaters and/or bridges are OK, but not gateways. Once the kernel
is downloaded to the diskless cnode, the cnode expects its root file services,
and potentially its swap resources, to come from the machine that provided
it with the kernel. While it is true that the HP diskless implementation
provides LAN break detection, this feature has nothing to do with root server
support being limited to a single LAN card, although repeaters and bridges act
as terminators and it is difficult to detect breaks on the other side. The
inability to work over a gateway is a result of using link-level addressing
for inter-cluster communication. The use of broadcast messages is also very
limited in the implementation.

To answer the question, yes the implementation "could" be extended
to work across multiple LAN cards on the server. The rbootd daemon does
not care which card it attaches to and would be perfectly capable of
downloading a kernel from the server over two cards. The changes to support
this type of topology would require changes to the transport code and
would not be real difficult. It would require keeping track of which card
a request came in on and making sure the reply went out on the same card.
Handling broadcasts would be a little more difficult.

Overall high level algorithms play a key role in performance of distributed
systems. Special purpose light-weight networking protocols, server processes,
and network buffer management routines must all play together in the design
of such a system. Good performance not only requires a system view of the
goals to be achieved but the implementation of the design must also be
efficient.

Special purpose designs like the HP-UX diskless implementation have their
advantages and disvantages. The advantages are considerable in the context
of a closely knit work group where a single file system view, high speed
intra-cluster communication, and transparent sharing of files and access
of data is extremely important. As long as the special purpose design allows a
peaceful co-existence and complete inter-connectivity with the outside
world via standard and evolving networking services (Arpa/Berkeley, NFS,
etc), the user is then provided with a powerful combination of capabilities.
The HP-UX diskless operating system provides these capabilities.
It is only in the more limited context of wide-area connectivity for diskless
cnodes that the special purpose design shows disadvantages, Specifically,
the inability to operate across a gateway limits the range of
inter-connectivity possible. However, it is precisely this type of situation
that places other undesirable limits on the design and tends to hinder
the ability to achieve higher levels of performance.

It can certainly be argued that with new VanJacobson TCP/IP implementations
and improved buffer and data management, special purpose networking protocols
are unnecessary. The HP diskless implementation preceeds these IP modifications.

regards: daveg ( #include <disclaimer> )