Tom Jennings
     Fido #1 in Net #...

             Unfortunately there isn't enough time to give you
     complete details, as it is now Sunday, the deadline for the
     newsletter, and I just got back from St. Louis this AM, but
     I'll at least cover all the major points. A more detailed
     summary will follow.

             On Thurs. 11 Apr, Ezra Schapiro and I talked at the
     McDonnell Douglas Recreational Computer Club (MDC/RCC) in
     St. Louis. Since we were going to be in town, an informal
     "FidoNet meeting" was arranged a few weeks ago. The meeting
     consisted of the St. Louis sysops (Ken Kaplan, Ben Baker,
     Tony Clark, Jon Wichman, Terry Mueller, Jack H.*), Ezra
     Schapiro and myself, and was held in Ken K's living room. We
     talked for 11 hours, and accomplished quite a bit. The
     topic: what to do about running FidoNet.

             I hope you have all read the file FIDOHIST.TXT, once
     published in this newsletter, and available for download
     from many Fidos. If not, shame on you, drop this and GO READ
     IT FIRST!

             An accurate node list is absolutely crucial to
     FidoNet. Without it, FidoNet is useless. An inaccurate list
     is worse than no list at all, and verifying all that good
     stuff takes time. The current rate of growth of FidoNet is
     about 12 - 15 nodes per week.

             Please note that from here on, when I refer to
     "running the net" or "managing the net" I really mean
     creating, updating and verifying the node list and Fido
     list, and helping new sysops get their systems up and
     running, and the ten thousand other little tasks that
     requires. As far as anything further goes, it's just
     basically impossible, and completely undesireable.

             To get right down to it: FidoNet is too large to be
     managed from a central point; the world wide net is going to
     be broken into a number of smaller nets.

             Don't panic yet, it's not that horrible! As a matter
     of fact, it will be easier and better for everyone, from the
     big nets such as Southern California to the single systems
     in out of the way places.

             Right now, each node is identified with a Node
     Number. Node numbers can be anything from 1 to 32767. Each
     node has a unique number of course. In general, this works
     fine, but it's really not practical for Ken Kaplan in St.
     Louis to have to give node numbers to sysops in England,
     Sweden and other far away places. And increasingly, within
     the U.S.

             The next version of Fido, 10H, will have a new thing
     called the Net Number. Nets can be numbered from 1 to 32767,
     and each net can have 32767 nodes. The idea is to be able to
     let geographical regions assign their own node numbers,
     without the horrible problem of duplicate node numbers.

             The best comparison is the phone company. Instead of
     trying to make each telephone in the US have a unique
     number, the country is grouped into area codes; local
     operating companies can assign individual numbers as they
     see fit, without worry of having a duplicate in some other
     part of the country.

             FidoNet Net Numbers work the same way; to send a
     message to a node in your own net, all you do is enter its
     number; to send to another node in another net, you must
     specify its net AND node number.

             To do all this, North America is divided into
     "regions", each with an "administrator" (admin for short).
     Each region has a unique net number. The admin for that area
     will pass out node numbers and keep a node list, just like
     Fido 51 does now.

             Instead of passing out node numbers, Fido 51 will
     pass out Net Numbers. There won't be as many nets as their
     are nodes. They will also take the node lists from each
     region and compile it into one large consolidated nodelist,
     and pass that back to each admin for distribution.

             In some areas there are "local nets", such as
     Boston, Southern California (SoCal), etc, that are more or
     less totally self contained nets; these kind of areas will
     be assigned seperate net numbers, and will generate their
     own node lists. The admin for, say, California will not be
     responsible for the SoCal net; the sysops down there will
     be.

             This arrangement has all sorts of nice side effects.
     I'll give examples of some of them here.

             Regions are such that there aren't more than 15 or
     so independent nodes (indies, yet another new word) to keep
     track of; a 15 node node list is pretty easy.

             One region includes Northern California and Nevada.
     While it sounds like a big area with a lot of work, it
     isn't.  All the admin for that area has to do is maintain
     the node list for a fairly small number of nodes. If a local
     net starts to form, say in San Francisco, they get a Net
     Number from Fido 51, and they become a seperate Net, totally
     self contained. The admin no longer need worry about them.

             Since nodes tend to pop up in metropolitan areas,
     therefore in clusters, the admins work increases with each
     node; at some point a net forms, and much of it goes away.

             The complete node list and other files will be kept
     at the admin's node; for many systems this will be a local
     call instead of to St. Louis.

             One major and wonderful change is what happens when
     you go to enter a message. Instead of being confronted with
     a huge, meaningless list of 250+ nodes, Fido lets you list
     either the Regions or the nodes within a region. For
     example, to send a message to a node in SoCal, instead of
     having to list the whole node list, you list the regions
     first. There will be about 30 regions. When you see
     "Southern California", you pick it. Now you list the nodes;
     you get only the nodes in SoCal. There is also a "shorthand"
     for when you know the exact net/node you want to send to.
     It's easier to use than describe.

             National routing as we know it is no longer needed;
     Fido will automatically route mail to the host of a net.
     (Routing is still needed inside the net.) By definition, the
     admin will not need to ever keep any routing information; as
     soon as one node acts as host for another, they become a
     seperate net.

     IN CLOSING ...

             You are getting this as things are being detailed,
     and hard data will be passed around as soon as it's
     complete.

             We need some volunteers for admins in some areas,
     and very soon, before this goes into effect. Sorry, but I
     can't give you the list of regions, I don't have it yet, but
     somehow it will get out, maybe by mass mailing. I realize
     this probably opens more questions than it answers, but we
     need the admins to be able to pass out the information!

             Some funny coincidences: Fido 10G has a limit of 250
     nodes maximum ... so does NODELIST.EXE. Don't worry, it's
     not fatal, it will just ignore the 251st and higher nodes.
     (Sorry, new sysops ...) 10H will have a limit of 1000, and
     something for beyond that as well.

             There will be new NODELIST.EXE and ROUTEGEN.EXE
     programs. They will be required.

             Fido 10H has many improvements. the bugs are fixed,
     or at least, the obvious ones. Reading FidoNet messages is
     FASTER.


     Ref: FidoNews 2-10 (22-April-1985)
     http://195.226.109.55/jhassler/wif/doks/fnews/fido210.txt
     By: Tom Jennings