FIDONET:  Response    5/24/84

Richard P. Wilkes
WILKES SOFTWARE SYSTEMS
PO Box 1577, Baltimore MD 21203
(301) 889-7894

With  all  due  respect  to  Tom  Jennings, I feel the FidoNet implementation
as  described  in  the  FIDONET.DOC  file  is not practical.  Let me explain,
hopefully without becoming too verbose.

I  have  been  working  on networking systems for seven years now.  One thing
that  truly  amazes  me  is  the  effort by every implementor to reinvent the
wheel.   Now,  sometime  when the wheel doesn't exist, you have to create it.
But  in this case, there are already MANY different ways to network computers
together  that  WORK;  if  a  network is to be designed, let's chose one that
won't leave us isolated from the "rest of the world."

People  in  the  micro  BBS  environ  often are totally unaware that there is
a  working,  FREE,  network  of  mini and microcomputers exchanging gigabytes
of  mail  around  the  country (by phone).  Some are part of the Arpanet, but
the one we should examine is UUCP, a network of machines running Unix.

The  UUCP  mailer  is  not  small,  but could be modified (with great effort)
to  run  on a PC.  I know that vortex!lauren@RAND-UNIX is working on an MSDOS
version.   Note  that  the address format shown here is a standard.  Messages
addressed  in  this  manner can be gatewayed through many networks to finally
reach  its  destination.   "vortex"  is  the  UUCP  machine;  "lauren" is the
username (for Lauren Weinstein); RAND-UNIX is the Arpanet gateway.

Now,  all  of  this  may  not seem like it has much to do with FidoNet.  But,
the viability of such a network depends on several vital points:

1)  Virtually  no cost or minimal cost that could be easily absorbed by local
administrations (as they do now).

2) Connectivity with other systems.

3)  Personal  mailboxes,  a  feature unsupported by Fido to date.  These also
gobble disk space.

4)  net.news:    This  is  the equivalent of country-wide SIGs.  Messages are
gatewayed  through  several  hosts and utimately reach all systems where they
are  posted  in  message  areas.   Note that messages may range from 5 to 500
*lines*.

Now,  I could go on for many pages on the capabilities of systems like these.
Right  now,  you  can mail a message and have it delivered free to almost any
university  or  major technology corporation in the country via this network.
Other networks also allow file transfer (FTP).

I  don't  want  to  throw so much cold water on this that it never gets done.
However,  I  have  been around long enough to know that this ain't no one man
task.   Please, consider how naive the notion is of a "simple" routing scheme
for  40,000  pc's!   [UUCP  gets  around  this  by  chaining host names.  For
example,  brl-bmd!jhu!aplvax!joe  is  a  message address.  To deliver it, the
holder  contacts  brl-bmd  (Ballistic  Research Lab).  It need not know where
it  is  headed  after that.  brl transfers the message to jhu (Johns Hopkins)
which  passes  it  on  the the Applied Physics Lab (aplvax).  "joe" is a user
on  aplvax; the message is put in his mailbox.  This scheme may sound clumsy,
but it works with small, fairly static routing tables.]

The  idea  of  a  network is terrific.  As a matter of fact, I was working on
interfacing  with  a  UUCP  host  myself  for  a  BBS  that I use to publish,
CompuCenter.   I  came to these conclusions:  1) you need at least a 33M hard
drive  at  the  major  nodes,  perhaps more.  This is expensive.  2) You need
nodes  that  are  multi-caller.   I  mean, most of these systems are busy for
HOURS.   You  don't want mail delayed like that.  And, major nodes would have
to spend so much time transferring that they would not be usable for anything
else.   If  you had one line dedicated to MAIL with another for file transfer
and another for messages, maybe it would work.  But hey, an IBM PC at 4.77MHz
just ain't the baby for that kind of load.

All  in  all,  I'd  say...   wait.   The  technology  is coming.  With a good
multiprocessing  environment  with  5-6  serial lines, a high speed processor
(80286?),  and  86M  drives  on  the major nodes, we can start to really work
at making it a reality.  

For  the  time being, I strongly urge that those that are strongly interested
in  this  type  of  system  start  doing  some research.  When you can hold a
reasonable  discussion  on file transfer protocols (real ones, of course--NOT
XMODEM),  message  headers  and  formats,  routing  algorithms,  connectivity
analysis,  delivery  systems  and scheduling, plus some of the more intricate
cost  analyses,  we can join the work that is already advancing in the "other
world" so we are not left out once again.

I  welcome  any reasonable comments.  I frequent Fido CLP -- Baltimore, only.
I  can  be  reached  via  MCI  Mail  174-9184  or  CIS 72746,1712.  I am also
RICK@MIT-MC, eed_wgmm.jhu@csnet-relay, and brl-bmd!jhu!eed_wgmm.  

Please,  let's  keep  up  the  talk.   But more importantly, we must approach
this  formidable  task  with  a  little  humility  and  a  lot of good, solid
knowledge.

Sincerely,

Richard P. Wilkes