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.