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