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: /Y /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 ", where 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.