[249] in Resnet-Forum
Re: Bootp
daemon@ATHENA.MIT.EDU (paul@atlas.abccomp.oz.au)
Mon Apr 18 20:39:46 1994
From: paul@atlas.abccomp.oz.au
Date: Tue, 19 Apr 1994 10:11:36 -0500
To: Roger.L.Gulbranson.1@nd.edu (Roger Gulbranson), paul@atlas.abccomp.oz.au,
resnet-forum@MIT.EDU
Thus expounded Roger Gulbranson on Apr 18, 8:29am:
/--------------------
|At 10:12 AM 4/18/94 -0500, paul@atlas.abccomp.oz.au wrote:
|>We sell a commercial RARP server which allocates addresses on the fly -
|>BOOTP will be done as soon as I can convince the boss it'll fly!
|>
|>We recover addresses bvy actively ARPing each allocated address, at some
|>user-controlled rate (usually around one ARP per second, so each machine
|>gets tested every couple of minutes or so). If a machine does not answer
|>5 consecutive ARPs, the address is considered available for re-allocation.
[... rest of plug deleted...]
|
|How do you deal with systems, PCs in particular, that only respond while
|they have an active application running?
Applications that I can think of like this are things like NCSA Telnet and
derivatives, etc - applications with no TSR component - and these send
out a new RARP/BOOTP request when they next run, and don't need an address
when they aren't running (!). I don;t know of any application that remains
in memory and remembers addresses from one 'session' to another, but in
between times doesn't respond to network traffic at all.
Well, I can think of one - our TSR network kernel can be set up so
that, when no sockets are open, it detaches itself from the packet driver,
so that other packet driver applications can use it without needing to unload
our TCP/IP from memory. When a new socket is opened, however, it automatically
re-initialises itself with the packet driver and sends out a new RARP/BOOTP
query, so that isn;'t a problem, either.
In fact, this mode was added for use with the RARP server, for a specific
instance you all might be interested in - a client had over 500 PCs
they wanted to use TCP/IP, but only a 50-concurrent-user license on their
Unix server, so only needed 50 IP numbers (they only have one class-C space)
active _at_any_instant_. So the RARP server allocates out of a pool
of 50 addresses on a first-come, first-served basis, but when someone
logs out, the TSR detaches, the RARP server eventually times out the
address and allows someone else to use it. When the person wants to log on
again, it sends out another RARP query, which may result in a different
IP number from last time (but who cares), and off they go - without having
to reboot, or load/unload software, etc. Its great for things like
teaching labs, where out of say three labs only two might be going
at any one time - you only need to reserve as many IP addresses as you
want simultaneously active, instead of one per machine that _might_
one day be active.
Did you have anything specific in mind that behaves differently? I don't
know of anything that would break it, and none of our installations have
come up with anything to our knowledge, either.
|Roger L. Gulbranson, Ph.D.
|Director, Networking Services
Paul Brooks, (Ph.D. in 3 months)
Developer, Networking Software
--
Paul Brooks |paul@abccomp.oz.au |Emerging Standard:
TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet
579 Harris St., Ultimo | | been superseded.
Sydney Australia 2007 |ph: +61 2 281 3155 |
