DnA 6-12: An Introduction to Fido-Type Nets (part I)
Written by Pazuzu - November 15, 1993
(C) Copyright 1993 Digital News Associates
ALL RIGHTS RESERVED
With everyone and their uncle wanting to join a net these days, and with 95% of the nets out there using the Fido networking standard there needs to be a tutorial on setting up on one of these nets. The terminology and volume of software required to run on a Fido net can be quite daunting to the newcomer. And nowhere does a complete guide to setting up on one exist - the info you need is scattered across several software docs, and also in FTSC files which no human can understand. It seems the only way to get going is just to "hack it out" - with weird and often very negative results, or to get someone to do it for you. Well, now there is hope! After running nets for 5 years now, I've learned quite a bit about operating them and I've decided to share my knowledge via this article.
The first thing you need to understand is how systems on a Fido-style net are addressed. The official address format is Zone:Net/Node.Point. Now, this terminology is a bit confusing at first, because the "Zone" part is actually the net, while the "Net" part is really a "Sub-net" or region. Each separate network is a different zone - CyberCrime is zone 69, Platinum is 93, and so on. Within these nets, there are "sub-nets", usually individual area codes, such as 5714 in CyberCrime. Some nets don't use the area code as the "Net" entry, especially not FidoNet itself, but most of the underground nets do. The "Node" part is just the individual number assigned to each system within that Zone and Net. So Node #2 in the 5714 Net of Zone 69 would be 69:5714/2. The "Point" part is a creation of Satan and only crack smokers mess with them - they're basically "Sub-nodes" leeching off a main node. Don't worry about points - they're being phased out anyway. Systems with a node number of 0 are almost always hubs - this 0 address makes it easy to spot them - 69:5714/0 is my CCi node number.
After you understand addressing (which is really rather simple, see?) the next thing that confuses people is the volume of software required to operate on the net. There's really not much REQUIRED (besides your BBS) - just a mailer and most likely an echomail processor, but there is SO MUCH accessory software out there that a lot of people get very confused. Don't worry too much about all the other junk besides your mailer and echomail processor.
The mailer is definitely the most important part of your Fido networking software - without it, you are NOTHING. There are several mailers available - FrontDoor, Intermail, D'Bridge, etc. I prefer Intermail - it's easy as hell to get going. Anyway, what your mailer does is run your entire system. You will no longer load your BBS software to put your board up - you'll run a batch file which runs your mailer. The mailer answers the phone, determines if the call is a mail call or BBS call and reacts appropriately. If the call is for your BBS, it exits with the errorlevel you specified for BBS calls, which hopefully you have trapped in the batch file to load the BBS. If it is a mail call, it receives the mail and waits for another call. It is very important to understand the DOS errorlevel when setting up a mailer - most, if not ALL, of them use errorlevels to control everything. Get a basic DOS book if you don't understand ERRORLEVEL. The mailer also executes any nightly events you have configured it to - usually polling your hub is one of them. If you have any other nightly events your BBS was running - like packing message bases, on-line game daily maintenance, etc - you now have to configure these events into your mailer because your BBS isn't running unless someone is on it!
The other piece of software you'll need is an echomail processor (unless your mailer has one built it). My favorite is GEcho. In order for me to explain why one is needed, I'll have to explain the way echomail works. Echomail is a Fido standard for networked message bases. In this standard, each message base has a separate directory on disk, and each message is a single file in that directory with the name #.MSG ... Message #1 would be 1.MSG, #2 would be 2.MSG, and so on. This is a very simple concept, and one that works well. In order to get the messages sent out to wherever they're going (most likely your hub), they have to be packetized. What this means is that something needs to gather them all up into one big file, and then .ZIP (or .ARJ, etc) this file, and get it sent out. This needs to be done for EACH system your system is feeding. This is what the echomail processor does. You also have to have a third program, which comes with most BBS packages. This program is the BBS's toss/scan program. What it does is take the new message from the BBS's message data files, and create the *.MSG files in the proper directories. This is called "SCANNING". It also takes incoming *.MSG files and puts them into the BBS's message data files. This is called "TOSSING". Some BBS packages do this automatically, without running a separate program, but most don't. The program is usually called <something>mail.exe. Renegade's is RENEMAIL, Celerity's is CELEMAIL, and so on.
Notice before I said " ... and get it sent out". How does this happen? Well, the Fido standard was VERY limited in its early days - it supported only messages between different persons on the net. However, each message could have several attributes set in it - Crash, Private, etc. One of the attributes is "File Attached". This is how echomail works - when the echomail processor packetizes the messages, it creates a message addressed to the SysOp of each system the messages go to (each system gets a separate packet, too of course) from "ArcMail" with the File-Attached attribute set - then the mailer knows to send that message (with the attached file of course) to that system. On the other end, the receiving system's echo processor looks for all messages from ArcMail, and then uncompresses the attached files, and places the individual messages into the proper directories, then the BBS's tosser runs and tosses the messages into the BBS's data files.
Because of the intimate interaction between the all these pieces of software, it is important to make sure all of the programs are looking for stuff in the right directories. Both the echomail processor and the BBS need to be set to look for the *.MSG files in the same directory for each base. So, if INF-BBS is set in the BBS to be in directory "C:\RG\ECHO\INF-BBS\", you had better make it the same in the echomail processor so it can find and place the files into the directory. Both the mailer and the echo processor - and sometimes even the BBS - need to know where to store netmail messages. The echo processor needs to know so that it creates the attach messages in the right directory and of course the mailer needs to know so that it finds these messages, and sometimes you may want the BBS to import netmail to you into your private mail on the board - I don't, but some people do. So always make sure your directories match - NON-MATCHING DIRECTORIES ARE THE BIGGEST CAUSE OF NETS NOT WORKING!
You will also most likely see stuff in mailers and echo processors about "Hudson Message Bases" - ALWAYS DISABLE THIS FEATURE - Set it to *.MSG or "Nothing" if there's no *.MSG option. Hudson bases are used by some BBS's and external editors, but they are evil and should be avoided by sane people.
Another thing you'll have to do is tell your hub which echoes you want. If you're lucky, your hub will have AreaFix capability so you can do this at will - automatically. If not, you'll have to email or call the SysOp of the hub and tell him what you want. With AreaFix (or AreaMgr), all you do is send a message to "AreaFix" at your hub, with your password in the subject line, and a list of echoes you want, one per line in the body. You'll be automatically added to the echoes. Much easier and faster than calling the SysOp.
After you've got all this software configured and running, you'll have to create a batch file which will automatically manage all this software. Below, I've included my batch file, which I have named FRODO.BAT because I used to run FrontDoor, and never got around to changing the name. I've included enough REM statements for you to figure it out, and change it to work with your setup. Good luck! - Next month, I'll go into more detail on some of the things you can do with this versatile networking standard.
<pazuzu@netcom.com>
>> EOF <<
