How a LAN works - Someone Else's Problem

Copyright Dr Alan Solomon (1986-1995)

LANs are complicated, so complicated that everybody thinks that they
can't understand them.  Not so.  Whatever the mind of man can invent,
the mind of man can comprehend, and someone has found an extremely
neat trick to make networks easy to create and also to understand.

The trick is called SEP (Someone Else's Problem), and it was invented
by Douglas Adams, who used to run a Dec Rainbow and now runs a
Macintosh - a real creative mind.

When you ask your butler to fetch you a whiskey, you don't trouble
yourself with exactly how he does it - all you need to know is how to
make the request, plus what you get back as a result if everything is
working well.  All this stuff about finding the decanter, pouring out,
chopping ice, how to squirt soda - all that is Someone Else's Problem,
and you don't need to know how he does it.

Likewise from the butler's point of view, he doesn't need to know what
you're going to do with the whiskey.  Nor does he need to know how to
distill whiskey - the levels above and below are each Someone Else's
Problem.

Networks work the same way.  At the top level, we have Mr Green the
Grocer working on his accounts while Mrs Green is using the same data
to update the stock position.  They don't know or care how it all
works (SEP), all they know is that a gross of beans has just arrived
and needs entering.

Jim Hacker, the programmer, wrote that accounting package.  All he
needs to know is that there is a disk drive called K:  which is shared
over the network;  he doesn't need to know how the sharing is done.
He also knows that his program would be used by several people at
once, and that at some point two people would try to update the same
data at once.  Mr Green would read the data (100 cans of beans), and
then Mrs Green would read the same data.  Mr Green would change it to
reflect the fact that he had sold 40 cans, reducing the stocks to 60,
but Mrs Green would also update those 100 cans to add the 144 that
have just arrived, giving a total of 244.

One Green would save the change, and then the other Green would save
their change, and it would be pure chance whether the stock position
showed 60 or 244 cans;  it certainly wouldn't show the true 204 cans.
This is called a data collision, and you can see the extremely nasty
results you can get - the data becomes nonsense.

So Jim Hacker used file locking.  When Mr Green reads the data, the
file is locked so that no-one else can use it, until Mr Green saves
his changes, and then the lock is released, and Mrs Green can make her
changes.

Great - no data collisions.  But Mr and Mrs Green hated it;  whenever
anyone was doing anything whatsoever with the database, no-one else
could use it at all, even if they wanted to look at a completely
different area.  The Greens might as well go back to a single
computer.  So Jim Hacker had another go, and this time he used record
locking.  Only those bytes that Mr Green wants to change are locked,
and Mrs Green has the freedom of the rest of the file, and the Greens
are happy ever after.  And whenever they buy network software, they
make very sure that it uses record locking.

But how did Jim do it?  Dos 3.1 and later provides a function call for
record locking, and his compiler uses that.  Jim just asks Dos to lock
the record, and Dos does it.  The nice thing about this, is that Jim
doesn't need to know what network his system is running on;  that's a
problem for Dos to worry about.  All he needs to worry about is what
to lock, when to lock, when to release the lock, and how to get his
cheque from the Greens.  The rest is SEP.

That leaves two problems for William Gates the Whizz-kid.  William
wrote Dos with a bit of help from his friends, and it's the
best-selling program in the world.  He knows that Jim Hacker will be
asking Dos for data, and that sometimes this will be on a local disk
and sometimes on a remote networked disk.  He also knows that Jim
Hacker needs to be able to apply locks to shared data.  But he is in
the difficult position of not knowing how the network hardware works,
as most of it hasn't even been invented yet - there are new networks
coming out all the time.  Fortunately, William knows about SEP, and
uses it.  He decides not to read and write the disk directly, because
to do that, he has to understand the layout of the disk (how many
platters and suchlike) and whether it is a local or remote disk.
Instead, let us suppose that all computers have a thing called the
Bios that talks to the disk, and understands about each disk's
hardware.  But every Bios must have one thing in common - when you ask
it to read sector 13,426 it does whatever it has to do to get that 512
bytes of data.  The disk Bios is supplied with the hardware, so for
example, a Western Digital controller has a Bios on the card in Rom.

Now let's extend that idea, and have a thing called the Netbios.  So
when Dos wants sector 13,426 on the local disk it asks the Bios to get
it, and when it wants part of a file on the remote networked disk, it
asks the Netbios to get it.  Dos can also send requests to lock chunks
of bytes in files so that if someone asks for a locked area, it can
simply come back with "Locked - please try later".

So that all Dos has to do, is know how to ask the Bios and Netbios for
the data, and how to request a lock on part of a file, and the rest is
SEP.  Dos doesn't even need to know which network it's running on,
provided there's a Netbios that it can use.  Jim Hacker knows all this
- he doesn't know exactly how Dos uses the Netbios, all he knows is
that there had better be one or his software won't work, and he tells
the Greens to be sure to get a network that supports Netbios 100%.
Any less than 100%, and Dos might ask the Netbios for something, and
the Netbios doesn't understand the request, and then something doesn't
work properly.  So now you know why the Greens, Jim Hacker, William
the Whizz-kid and you, always insist on 100% Netbios compatibility in
a network.

So where does the Netbios come from?  Mr Midge, the board maker, knows
that people will be wanting to run software on his network cards, so
he provides software with each card.  This software might be in Rom on
the card, but more usually is in the form of a device driver that goes
into the CONFIG.SYS or a TSR that is run in the AUTOEXEC.  The job of
this software (called the Netbios or Netbios emulator) is to accept
requests for network services, and to pass these requests to a remote
machine.  Those requests are received by the remote, and sent to the
server software.  Somehow, the server software supplies the service
requested (which might be a request to print a file, or to read a part
of a file).  The Netbios on the server doesn't know or care how this
is done - SEP.  The Netbioses are just like two telephones linked by a
piece of wire;  the telephones don't care what language the callers
are using, or what they are saying to each other.  The phones just
pass the message, without understanding what it means - acting on it
is Someone Else's Problem.

So what does server software do?  Let's ask Messrs Bright Red and Big
Blue, who between them supply a lot of it.  The server software takes
requests for parts of files, and sends the data down the network to
the requester, provided he has permission to get it, and he isn't
asking for something that has been locked.  What the requester does
with the data is SEP.  How does the server get the data from the disk?
It asks the Bios, just like Dos does, and how the Bios gets data from
the disk is SEP.  Of course, it is the same Bios that Dos uses, so
that no-one has to reinvent the wheel.

We haven't yet covered how data is exchanged by the Netbioses at each
end of the wire.  This is a bit like how two phones exchange sound,
except that it tends to be simpler.  The network interface card
converts bytes into electrical signals, and the other card turns them
back to bytes.  The electrical signals can travel down a thin coaxial
cable if the cards are Ethernet, or down thicker pairs of wire if the
cards are Token Ring.  Other systems use other kinds of wire - this
part of it is the least important part of the whole system.  A network
is 99% software.  The hardware is the visible bit - you can drop it on
your foot.  But it is the software that makes the network do its job.

So now you see how it all works.  Even though a network is even more
complex than a dozen computers, by breaking it down into layers, that
complexity can be handled.  The key is to make sure that the different
layers don't need to know anything about the contents of any other
layer - all they need to know is how to communicate with the layer
above and the layer below.  Everything else is Someone Else's Problem.
And, in case you haven't guessed it yet, I've just explained the
ISO seven layer model that everyone else talks about, but never
explains.