285 lines
11 KiB
Plaintext
285 lines
11 KiB
Plaintext
Tom Jennings
|
|
30 Apr 84
|
|
Fido #1: (415)-864-1418
|
|
|
|
Some preliminary ideas for the FidoNet. (If you�
|
|
haven't heard, FidoNet is an intersystem message forwarding�
|
|
system mostly for Fidos, but could be used for others as�
|
|
well.)
|
|
|
|
Please, don't worry about all the seeming complexity�
|
|
here. Most will go away. I have just typed everything I�
|
|
could think of all at once, and not all is applicable.�
|
|
(Besides, you're (probably) not gonna code it.)
|
|
|
|
There are some points that need ideas: mainly, how�
|
|
to pay for it, how it will appear to callers trying to send�
|
|
mail, and any mysterious operational type problems you see.�
|
|
Like most of Fido, I imagine this too will be built with 90%�
|
|
suggestions.
|
|
|
|
If you have any ideas on this proposed system,�
|
|
please leave me a note on Fido #1 at the above number.�
|
|
Thanks.
|
|
|
|
O P E R A T I O N
|
|
|
|
|
|
From a callers point of view, the system will have�
|
|
one additional feature when entering a message. One way or�
|
|
another the caller tells Fido which system the message is to�
|
|
be sent to. This could consist of a prompt (System A, B,�
|
|
...) or some such thing. (Any ideas?)
|
|
|
|
In any case, mail will only work from a MAIL�
|
|
subdirectory. Messages left here will be like all other�
|
|
messages; readable or not, depending on the privacy, etc.�
|
|
Replies can be left, etc, which get mailed in the same way.
|
|
|
|
It may be desirable to search this area for each�
|
|
user after signon, the same way message searching works now.�
|
|
If old messages don't pile up like in other areas, this�
|
|
should be nice and fast.
|
|
|
|
There will not be any automatic confirmation of�
|
|
received messages. It will be up to the user to do so, by�
|
|
mailing a message stating that is was received. Maybe it�
|
|
will be possible to confirm, by reading the RECV'D flag from�
|
|
the message, but that won't go into the first one.
|
|
|
|
In the MAIL area, the usual message search�
|
|
("Messages to you" etc) should be adequate, if mail traffic�
|
|
is less than or the same as the current message traffic.
|
|
|
|
I M P L E M E N T A T I O N
|
|
|
|
The only change to Fido will be a new command line�
|
|
parameter:
|
|
|
|
<number>/Y
|
|
<number>/W
|
|
|
|
/Y Is the hour of the day to start doing mail as�
|
|
opposed to normal BBS stuff. /W is the window width, in�
|
|
minutes, to do mail in. For example, 0200/Y 90/W says do�
|
|
mail from 2:00AM, for up to 90 minutes, i.e. until 3:30AM.�
|
|
During this time, Fido will not accept any normal callers.�
|
|
Also, outside these times, Fido will not accept mail. If no�
|
|
switch is present, or the window is set too small (TBD) then�
|
|
it will not send or receive mail, like it does now.
|
|
|
|
Neither will it bump someone off if they happen to�
|
|
call just before the appointed time. However, as soon as�
|
|
they logoff, it will start handling mail if it's supposed�
|
|
to.
|
|
|
|
The mailer (the program that actually sends and�
|
|
receives mail) is a seperate program. It is run from the�
|
|
batch file (RUNBBS.BAT) right after Fido.EXE. This works�
|
|
like Control-C and errors do; via ERRORLEVEL. For instance,�
|
|
the batch file might look like:
|
|
|
|
FIDO ... 0200/Y 90/W
|
|
IF ERRORLEVEL 4 GOTO MAIL
|
|
IF ERRORLEVEL 1 GOTO END
|
|
RUNBBS
|
|
MAIL:
|
|
MAILER 0200/Y 90/W
|
|
RUNBBS
|
|
END:
|
|
|
|
Like current Fidos, ERRORLEVEL is 0 if normal�
|
|
termination (caller hung up, etc) 1 if Control-C or stack�
|
|
overflow, 2 if disk file error (disk full, missing files,�
|
|
etc) or 4, the new level for: "Time to do Mail".
|
|
|
|
If it's time to do mail, Fido exits with ERRORLEVEL�
|
|
4. If 4 or higher, it runs MAILER, which then runs�
|
|
RUNBBS.BAT which starts it all over again. Otherwise, if 1�
|
|
(or higher) it is an error, it goes to the end and stops.
|
|
|
|
When run, the mailer sits and waits for phone calls,�
|
|
or if instructed to do so, (command line switches or a�
|
|
command file, whatever) makes calls. If a human type caller�
|
|
calls, they will get a message to the effect "Waiting for�
|
|
mail, please call back after <xxx>", where <xxx> is the end�
|
|
of the window to wait for mail, and hang up on them. (The /W�
|
|
and /Y switches will be duplicated in the mailer, for�
|
|
reasons I'll not bother with now.)
|
|
|
|
C O S T
|
|
|
|
First, it is very important that we figure out what�
|
|
it would cost. This is the second most important part. The�
|
|
cheaper it is, the more likely FidoNet can be made operable.�
|
|
However, no matter how cheap it is, if an ingenous way of�
|
|
paying for it doesn't exist, then it all falls flat.
|
|
|
|
Right now, late night long distance (coast to coast)�
|
|
toll charges are about $13.00 per hour. ATT is proposing, as�
|
|
part of some other boring issue, lowering this to $10.00 per�
|
|
hour. This is quite cheap; a lot of messages can be sent in�
|
|
an hour.
|
|
|
|
I hereby declare the mail size unit to be the Cubit:
|
|
|
|
1 Cubit == 80 characters * (1200 / baud rate)
|
|
|
|
A cubit of mail sent at 300 baud will cost 4 times�
|
|
as much as one sent at 1200. When 4800 baud modems become�
|
|
available, the price per cubit will drop.
|
|
|
|
Unlike commercial mail systems that are out for�
|
|
profit, FidoNet's mail unit, the Cubit, is small enough to�
|
|
account for very small messages, but large enough not to be�
|
|
too small to account for. There are 12.8 cubits in a K byte.
|
|
|
|
An error checking transfer protocol is needed;�
|
|
XMODEM will not be used, as transfer times routinely double�
|
|
with long phone lines. (Dont want to pay for that.) More on�
|
|
that later.
|
|
|
|
As an example, say we want to send a small (five�
|
|
lines, 64 characters per line) message from Los Angeles to�
|
|
New York. Each message has a header (to, from, date, etc)�
|
|
that consumes about 80 characters. Assume also that the�
|
|
transfer rate is 1200 baud, and also that the transmission�
|
|
method has a 10% overhead.
|
|
|
|
Msg size: 4. Cubits
|
|
Message Overhead: 1. Cubit
|
|
Message Size: 5. Cubits
|
|
Message Size: 400. Characters
|
|
|
|
Cost Per Hour: 13.00 Dollars
|
|
Chars/Second: 120.0 (10 bits/char)
|
|
Cubits/Second: 1.3636.. (120sec / (cubit * 1.10))
|
|
|
|
Cubits/Hour: 4,909. (3600 sec * cubits/sec)
|
|
Cost/Cubit: 0.2648 Cents ($13.00/cubits/hr)
|
|
|
|
Sample Msg Cost: 1.324 Cents
|
|
|
|
Yes ... its cheap. Remember, this is pure cost, no�
|
|
hardware maintenaince overhead, no payroll, no profit, etc.�
|
|
Delivery time, nor even delivery, is garenteed. The above�
|
|
does NOT include any connect/disconnect or disk access�
|
|
overhead. However, it also does not count any savings from�
|
|
text compression, which could save 10% to 40% maximum.�
|
|
Probably more like 20% maximum in the real world.
|
|
|
|
P A Y I N G F O R A L L T H I S
|
|
|
|
This is the most serious problem. The technical part�
|
|
is easy! Also, BBS's in general are run more like little�
|
|
fiefdoms than businesses, in the sense the are usually�
|
|
operated privately, and almost never pay for themselves,�
|
|
never mind make money! If FidoNet takes inordinate amounts�
|
|
of effort on the part of the sysop, it'll probably fold up�
|
|
due to that also.
|
|
|
|
There are a couple of ways this can be paid for, but�
|
|
none are really any good for typical free systems. (Note�
|
|
that receiving (accepting) mail costs nothing. FidoNet might�
|
|
be able to operate well with only a few well placed�
|
|
"benefactors", and work acceptably well with only local�
|
|
"paying" nodes, if mail is limited to say, an area code.)
|
|
|
|
IF YOU HAVE ANY IDEAS AT ALL ON THIS SUBJECT PLEASE�
|
|
LET ME KNOW!!!!!! THIS WILL MAKE OR BREAK THE FIDONET�
|
|
IDEA!!!!
|
|
|
|
In any case, some sort of accounting will have to be�
|
|
done. Except for very rare cases, mail will have to be paid�
|
|
for. The mailer will be able to account for each messages�
|
|
cost, length of transmission, etc. There must be a method�
|
|
for limiting mail sent by a specific user, and a "sysop"�
|
|
type feature for relatively unlimited, or at least�
|
|
differently limited, mail. The information associated with a�
|
|
peice of mail will have to be worked out in detail later,�
|
|
and while not too complex (any complexity can be put upon�
|
|
the mailer) it must be adequate for future expansion.
|
|
|
|
Presumably, not everyone will be allowed to forward�
|
|
mail indescriminately. That would be awful nice, but�
|
|
unfortunately not practical. There may be exceptions: for�
|
|
instance, for a club-run system, you might want to let any�
|
|
user send a fixed amount of mail over a fixed period of�
|
|
time, say, a month. If it was a dues paying club, a number�
|
|
could be worked out that would accomodate this. Anything�
|
|
beyond that amount would have to be accounted for by some�
|
|
other method.
|
|
|
|
|
|
IDEA #1
|
|
|
|
Club-run systems. Basically, covered above.
|
|
|
|
IDEA #2
|
|
|
|
Private, pay-ahead system. While this is very�
|
|
workable, it means even more work for the sysop, and�
|
|
probably some legal liability, like running a business,�
|
|
unless the proper rigamarole wording is used, i.e.�
|
|
"donations" not "charges".
|
|
|
|
No one will be able to send mail unless they mail�
|
|
some amount of money to the sysop. The amount donated is�
|
|
kept in a list maintained by the mailer, who subtracts the�
|
|
cost of the message from the balance. Usual warnings if not�
|
|
enough, etc, and probably a warning when it reaches some�
|
|
threshold.
|
|
|
|
T H E N E T W O R K
|
|
|
|
|
|
Might as well be trendy and use some network�
|
|
terminology here. Some of it's even handy.
|
|
|
|
The topography of FidoNet is in keeping with�
|
|
bulletin board philosophy; totally random and as little�
|
|
organization as possible. Also, there is no control over the�
|
|
location of the various message nodes (mail send/receive�
|
|
systems).
|
|
|
|
My first thought was to pass mail over as short a�
|
|
distance as possible; however, this is a waste of time, as�
|
|
late night long distance calls are charged on a per hour�
|
|
basis, and in any case the more transfers the higher�
|
|
likelyhood of messages getting lost.
|
|
|
|
Message delivery time, if all is well, should be�
|
|
overnight. If a system goes down, delays will be in�
|
|
increments of 24 hours.
|
|
|
|
There should also probably be a "broadcast" type�
|
|
message, that stops at each node. Also, there really isn't�
|
|
anything stopping binary files from being mailed; they are�
|
|
not included here mainly because costs will skyrocket, but�
|
|
it would be a nice way to do Fido updates, etc.
|
|
|
|
|
|
So, my current idea (any other ideas at all�
|
|
welcome!) is:
|
|
|
|
Each sender has a list of systems it can forward to.�
|
|
This can be used to limit forwarding to non-toll call areas�
|
|
if desired. Also, this same list can be used to send mail�
|
|
destined for one system, to be sent to a different system,�
|
|
for further forwarding. This allows cheapskates to let�
|
|
someone else make the toll calls. (If they in turn let it�
|
|
go) Also, it lets a well funded system forward mail for�
|
|
other systems.
|
|
|
|
If there are messages destined for five different�
|
|
systems, there will be five calls made (unless the�
|
|
abovementioned forwarding is done). This "nodeless" system�
|
|
is then relatively insensitive to down machines, etc, such�
|
|
that only mail for the down system will not be sent.
|
|
|
|
If the net gets tied up (everyone calling everone�
|
|
else, for instance, though I think thats unlikely!) then�
|
|
some message forwarding can be done to lessen the traffic�
|
|
load between busy systems.
|
|
|
|
|