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. Ref: FidoNews 6-22 (29-May-1989) http://195.226.109.55/jhassler/wif/doks/fnews/fido622.txt By: Tom Jennings