textfiles/bbs/FIDONET/JENNINGS/STANDARDS/fidonet.rpw.txt

101 lines
5.2 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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