





                                      KINGDOMS

                         NETWORK COORDINATOR DOCUMENTATION


                                    Version 2.18



                  Programming & Design : Dave Chapman : The Web BBS

                     Copyright c 1993, 94, 95, 96 - Dave Chapman
                                 All Rights Reserved





















                                 3:712/523@FidoNet
                                61:9600/350@WorldNet
                                69:1171/200@AdultNet
                                169:3005/2@BattleNet
                                151:6121/823@EzyNet
                          InterNet - dave.chapman@ibm.net

                             - Kingdoms Support Page -
                     http://www.magna.com.au/~davec/kingdom.htm



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________


                                TABLE OF CONTENTS



          SECTION 1 : COORDINATOR OVERVIEW                             3

          1.1. Document Purpose                                        3

          1.2. So you want to be a Coordinator?                        3

          1.3. Network Overview                                        3
          1.3.1. Technical                                             3

          1.4. Terms and Definitions                                   4
          1.4.1. The Index                                             4
          1.4.2. Routing Rules                                         5
          1.4.3. Default Outbound                                      5
          1.4.4. Network Id                                            5


          SECTION 2.0. UP & RUNNING                                    6

          2.1. Overview                                                6

          2.2. Choosing a Network ID                                   6

          2.3. Creating An Index                                       8

          2.4. Adding Nodes                                            9

          2.5. Modifying Nodes                                        11

          2.6. Deleting Nodes                                         12

          2.7. Reactivating Nodes                                     12

          2.8. Index File Dump                                        13

          2.9. Resetting the Game                                     13
          2.9.1. Overview                                             13
          2.9.2. Issuing a Reset                                      13
          2.9.3. How It's Done                                        14

          2.10. Coordinator Log                                       15

          2.15. Link Diagram                                          15

          2.12. Net Connections                                       15


          SECTION 3.0. TRACKING PROBLEMS                              16


          APPENDIX A : NEW NODE APPLICATION                           17

          APPENDIX B : KNOWN NETWORK ID'S                             18

           ___________________________________________________________

                                        2



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________


          Section 1 : Coordinator Overview


          1.1. Document Purpose


          This document explains what it is to be a Kingdoms Coordinator
          and what tasks a Coordinator does. If you're not a Coordinator
          and are not thinking of becoming one, then there's no need for
          you to read this to run Kingdoms on your BBS.


          1.2. So you want to be a Coordinator?


          A Coordinator is the person who manages a Kingdoms network.
          Kingdoms makes this task pretty easy by automating all network
          management functions, but there's still a lot to do just
          keeping track of new applications on your network and managing
          problems that will arise time to time. The Coordinator carries
          out the following tasks on a Kingdoms network.

       .  Creates and maintains the Index file, which is a list of all
          nodes on the network.
       .  Accepts new applications for BBS's that want to join the
          network.
       .  Issues game resets when required/desired.
       .  Is responsible for monitoring and correcting mail problems in
          the network, via the Coordinator maintenance options.
       .  Delete old or inactive nodes on the network.
       .  Generally keep things flowing as they should!

          That's only an overview, but you get the picture! If you think
          you want to get into all this and get a good network going,
          then read on!


          1.3. Network Overview


          1.3.1. Technical

          A Kingdoms Network consists of a series of BBS's running
          Kingdoms and communicating with each other via standard
          Netmail conventions. Each BBS in the Network is known as a
          Realm. Kingdoms directly supports and can address up to 35,000
          Realms connected in one distinct network.

          In each network there is ONE Coordinator node. All other nodes
          are equal in this respect. Limited network diagnostic
          utilities (Worms and Routing Reports) are available to a
          standard Kingdoms node, but only the Coordinator node can
          issue the advanced network management commands to directly
          affect the network as a whole, such as adding or deleting
          individual nodes.

           ___________________________________________________________

                                        3



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

          Each Realm in the Network must have configured an external
          mailer to which Kingdoms can define file-attached netmail
          messages in the .MSG format, such as Front Door supports. A
          switch is available also in the outbound manager to support
          the Blinkey/Squish mailer file attach message format.
          Obviously, a new Realm coming into the game must have a link
          to another Realm for mail transfer and a valid network address
          through which their respective mailers can communicate. It is
          quite permissable for each node in a Kingdoms network to be on
          a different network. Eg, one Realm can use a Fidonet address
          like 3:712/523 and the next an AdultLink address, 69:1171/200.
          As long as the mailers communicate, it doesn't matter to
          Kingdoms what network it's creating outbound and processing
          inbound files for. It will manage each seamlessley.

          Note that the Coordinator node need not be central in terms of
          a network `picture' in any way. As far as connections are
          concerned, it matters only that the Coordinator, through some
          path, is connected to all other nodes. The Coordinator Realm
          may be a central mail hub, or a node way down a mail feed
          line.


          1.4. Terms and Definitions


          To get the most out of this document and run your network at
          it's best, you'll need to understand the following terms :


          1.4.1. The Index

          Each BBS in your network must have an Index file, called
          KIDX.DAT. It must reside in the `Game Directory', as defined
          in the Kingdoms Manager for each BBS. If an Index is not
          found, Kingdoms will refuse to enter the InterBBS options for
          players. The Index is effectively the `nodelist' for your
          network and is created and updated by you, the Kingdoms
          coordinator. The Index has one record for each BBS and holds
          (or is updated with) the following information.

       1. The Game name of each BBS in the network
       2. The Game name of the Sysop running each BBS
       3. The actual BBS address (Zone, Net, Node. Points are not
          supported)
       4. The BBS type, Normal, Default or Routed
       5. A counter for incrementing outbound file names for that BBS
       6. Most recent Recon date
       7. Mail type, Hold or Direct, Crash or No-Crash
       8. Time statistics, to and from, for each BBS
       9. Status : Active, Inactive, Pending or Deleted
       10. Default Connection Zone, Net, Node

          I will discuss fully what these things mean later, but for now
          just be aware that the Index exists and that it is used to
          define to each system what BBS's are in the network and who
          routes data to whom.
           ___________________________________________________________

                                        4



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

          1.4.2. Routing Rules

          Routing Rules are rules specified by each Sysop for their BBS.
          They tell Kingdoms where to send mail to for each node.


          1.4.3. Default Outbound

          When each Sysop in a network defines their node to the Index
          during setup, a Default Outbound is assigned based on the
          network connections you have defined which are held in each
          Index on each Realm. Relative to each node, Kingdoms will set
          the Default Outbound as the outbound which is the shortest (or
          only) available uplink to you, the Coordinator node. The Self
          Correction facilities in Kingdoms 2.15 and later will poll the
          Default Outbound at intervals specified by each Sysop in the
          `Other' section of the Manager. This ensures the integrity of
          the network is maintained by propogating changes that might
          have been missed through the normal update channels when you
          actually make changes to the network.


          1.4.4. Network Id

          Each Kingdoms network must have a unique Id. This is a two
          character code that is used to ensure that the inbound files
          that Kingdoms processes actually belong to the network they're
          in. It also allows an individual BBS to play in two (or more)
          different Kingdoms networks (ie, run two separate Kingdoms
          games) without each getting confused about which mail to
          direct to which game on their BBS.


























           ___________________________________________________________

                                        5



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________


          SECTION 2.0. Up & Running


          2.1. Overview


          Following are the basics of what a Coordinator needs to do to
          get a network up and running and to maintain it. The remainder
          of the document goes into detail about what each of these
          things mean if you want further information. Everything done
          here is achieved using the general and Coordinator functions
          in the Kingdoms Manager :

       .  Select a unique Network ID for your network.
       .  Define your own node using Generate Index.
       .  Add Pending nodes (nodes coming online soon)
       .  Generate Indexes for the Pending Nodes (so they can set
          themselves up)
       .  Release Pending nodes (make them active across the network)
       .  Modify node details (as required)
       .  Deactivate nodes for whatever reason when required.
       .  Reset the game network wide when needed.
       .  Check problems using Routing reports and Worms.

          You may want to wing it from here, but I suggest reading the
          rest if you REALLY want to understand what you're doing as a
          Kingdoms Coordinator.


          2.2. Choosing a Network ID


          In the Manager, you will have seen a place you can enter a
          `Network ID'. If you are playing in an existing network, this
          is normally provided for you. As a Coordinator however, you
          must select your own for your network and make sure everyone
          in your network knows what it is and has entered it correctly.
          If they have it wrong, Kingdoms on their system will not
          process data from your network.

          The Network ID is simply a means of tagging network mail as
          belonging to your game (your network) rather than another.
          That way, data doesn't get processed by nodes outside your
          network and/or using another Kingdoms network as well as
          yours.

          The NetID is used primarily in two places - KNetIn and
          KNetOut. The way these are used will be explained shortly, but
          first it is advisable to understand how file names are created
          by Kingdoms -

          The format of a Kingdoms outbound file name is `
                                                         `KNxxxyyy.zza'
                                                                       '
          where :

               KN   - A fixed prefix, standing for Kingdoms Network.
               xxx  - The BBS index number which created the file.
           ___________________________________________________________

                                        6



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

               yyy  - The BBS index number the file is destined for.
               zz   - The Network ID of the data in the file.
               a    - Check character to avoid duplicate filenames.

          Thus, the file `KN003006.FAC' is a Kingdoms Network file going
                                                      rd      th
          from BBS 3 and destined for BBS 6, ie, the 3   and 6   BBS's
          listed in the Index file. The file contains data for the
          Kingdoms network with ID `FA' and has a unique identifier of
          `C'. The next outbound from BBS 3 would be named
          `KN003006.FAD', & so on.

          The 003 and 006 are really meaningless to Kingdoms itself as
          it does not care who is sending data to whom as far as
          filenames go. This naming convention has been chosen for
          Kingdoms Sysops to be able to see at a glance what data is
          going where without having to edit files and search out origin
          addresses, destination addresses, etc etc.

          The part of the file name we want to talk about here however
          is the Network ID. As discussed, it is part of the filename of
          outbounds created by any Kingdoms system. When you choose the
          ID for your network, you must NOT choose one that has special
          characters in it, or other characters that are not valid
          characters in a DOS file name. To be completely safe, I
          recommend you stay with alphabetic characters and numbers.
          Case is not sensitive thus `Aa', `aa' and `aA' are, to
          Kingdoms, the same Network ID.

          In full, valid characters in a Network ID's are the letters A
          through Z and numbers 0 through 9 inclusive and the characters
          underscore, _, carat, ^, dollar, $, tilde, ~, exclamation, !,
          number, #, percent, %, ampersand, &, hyphen, -, braces, {},
          parenthesis, (), at, @, apostrophe, `, and grave accent, `.
          No other special characters are acceptable and your Network ID
          ***MUST NOT*** contain spaces, commas, backslashes, periods or
          question marks.

          To summarise all that, the network ID is used to generate
          outbound file names. It must therefore be made up of
          characters which are valid in a DOS filename. It must also be
          exactly two characters in length.

          As discussed, the network ID should be unique. This is to stop
          mail from your network getting muddled with mail that should
          be for another network. How you make it unique is a harder
          question when you can't know what everyone else is using, but
          I suggest you check with those nodes that are in and/or
          joining your network. As long as they aren't using the one you
          want already for another network, you're probably OK. A
          complete list of all the NetId's I hear about/know of is
          maintained on the Kingdoms support page on the Net -
          http://www.magna.com.au/~davec/kingdom.htm.

          A file is also available on my BBS for FREQ under the magic
          name `KNETID' which lists all the currently used Network ID's
          that I've been told about. I urge you to FREQ a copy of this
          or check out the Web site and choose a Network ID not already
           ___________________________________________________________

                                        7



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

          in use elsewhere in the world. That done, then mail me (crash,
          net, internet, whatever) the one you've chosen and I'll add it
          to KNETID so others can make sure they don't use yours!


          2.3. Creating An Index

          This is where you'll first use your Coordinator options in the
          Manager. As most people don't need to see them (in fact, only
          the Coordinator can) they're not selectable by the normal
          arrow keys. To get to the Coordinator options, you must
          specifically press Alt-C to bring up the Coordinator menu.

          When selected, you'll have the following options available :

       .  Generate Index
       .  Add a new node
       .  Enable a new Node
       .  Modify a node
       .  Delete a node
       .  Reactivate a Node
       .  Index File Dump
       .  Reset the Game
       .  Cancel a Reset
       .  Coordinator Log
       .  Link Diagram
       .  Net Connections

          To make your Index, choose the first option, `Generate Index'
          by pressing Enter when it is highlighted. It's assumed here
          that you do NOT have an index (KIDX.DAT) file in your Kingdoms
          directory. If you do, you must remove it before trying to
          create a brand new index. If one does exist, the Generate
          Index option behaves differently and will offer you the option
          of generating a Distribution index from the existing one the
          Manager found. Generating a distribution index is discussed
          shortly however - for now, we'll assume there is not one
          there.

          After choosing Generate Index, a window will pop up asking you
          for your node information. You're required to enter your
          network address, BBS name and Sysop name. This data is needed
          and used to create the first entry in your new index file.
          Your entry will also be tagged as the Coordinator node. A
          couple of points to note here :

       .  You MUST give your valid network address. When Kingdoms
          creates outbound packets from your BBS to others, this address
          is used as the originating address. If it's not valid, other
          nodes will proabably reject or misprocess your mail.
       .  The BBS name and Sysop name you give here do NOT have to be
          the same as the ones you entered in the <O>ther submenu of the
          File drop down menu in the Manager. You can enter anything you
          like here. The names you enter here are the names seen by
          players in the game across the network. You are free to make
          them something more interesting (or obscure!) than your real
          BBS/Sysop name for the sake of interest in the game.
           ___________________________________________________________

                                        8



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________


          That's all there is to creating your Index File. Press Esc
          when you've entered all the information correctly and confirm
          the data is correct. Your new index file (KIDX.DAT) will be
          created with one Realm in it, your own, tagged as the
          Coordinator Realm.


          2.4. Adding Nodes


          Once created you will, of course, want to add other nodes to
          it. Adding nodes is a two step process.

          When you first add a new node, it does not actually get
          activated or distributed immediately. Rather, it is placed on
          your index only (not distributed across the network) as a
          PENDING Node. The reason for this is to facilitate the
          creation of Distribution Index files. I shall take a moment
          out to explain this.

          When a new Realm (BBS) comes onto your network, that Realm
          will need an index file in order to set themselves up. Of
          course, that index file must contain their BBS, or they're not
          going to get far. Who wants a nodelist that doesn't list their
          own node? You could just add the new node (without having the
          `Pending' concept) and send them a copy of the Index from your
          own system, but that will cause problems for two reasons :

       1. Firstly, your own Index probably already has your own routing
          rules defined in it. If you give other nodes a copy of your
          own index, the rules will be all wrong for them and it will be
          very confusing for a new Kingdoms sysop!
       2. Also, if the node becomes active immediately rather than being
          a Pending node, then players on your BBS, and others in the
          network when the new node is distributed by Kingdoms, will
          doubtless start sending recons to it and trying to communicate
          with the new node when it appears on the Realms lists in the
          game itself. Most likely, that node is only just setting
          itself up and is not ready to receive mail, if it's linked to
          it's Kingdoms feed at all!

          Instead of causing these problems, the PENDING node is
          created. In PEND status, a Realm does not appear in your game
          Realm listings, nor is the new node distributed to other
          Realms already active in your network. In short, it
          effectively doesn't exist yet to players in your game or to
          other Realms at all, but it IS on YOUR, the Coordinator's,
          Index file. What you can do at this point is use the `Generate
          Index' option again, as you did when you first created the
          Index for your own Coordinator node. Because an Index already
          exists this time, Kingdoms will assume that you do not want to
          generate a completely new index. Instead, it will create for
          you a Distribution Index file, which is a copy of your
          existing Index including PENDING nodes, with all routing
          fields initialised to zero or blanks, as appropriate. This you
          can send to your new nodes and they will have a fully
           ___________________________________________________________

                                        9



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

          initialised, up-to-date Index, which DOES have their node
          listed. They can set themselves up and when they're ready you
          can Enable the Pending node, which will make that Realm active
          (listed and usable by players in the game) on your Realm in
          addition to distributing an Index update to all other Realms,
          making the new Realm active across the net also without
          further action required on your behalf.

          The Distribution Index file is created as KIDX.id, where nn is
          the Network ID as defined in the <O>ther section of the
          Manager. It is not, of course, called KIDX.DAT, as that would
          overwrite your existing Index file!

          So, to summarise the process of generating and Index and
          adding nodes to your network:

       .  Create an new Index (using Generate Index) with your node
          information. Obviously, this only ever needs to be done once!
       .  Add a node (using Add Node) which will be set to Pend status.
       .  Create a distribution index file for your new node(s) (using
          Generate Index).
       .  Get the distribution index to the new node, or have them pick
          it up.
       .  When the new node is ready, release the Pending node to the
          network (using Enable Node).


          When you choose Add Node, you'll need to provide the following
          information for each node you want to add :

       .  The new BBS address (Zone:Net/Node)
       .  The Game BBS Name
       .  The Game Sysop Name
       .  The `Connect To' site.

          Items 1 thru 3 should be obvious, but item 4 requires some
          explanation. The `Connect To' site is simply the BBS who the
          new BBS is going to pick up mail from. As Coordinator you
          should have this information already as anyone joining your
          network will need to have already decided a point they'll pick
          up Kingdoms mail from and informed you where their pickup is
          during their application.

          As discussed, this info will be retained as a Pending node on
          your Index. Once you Enable the node, the following will take
          place, all internally (automatically) through your Kingdoms
          network.

       1.  An outbound record will be generated for each ACTIVE BBS in
          your Index. When each outbound arrives at it's destination,
          each destination's Index files will be updated automatically
          with the new node during Kingdoms inbound processing. The
          routing rules defined for new new node on each BBS are
          evaluated intelligently based on the `Connect To' node you
          specified originally, ensuring mail is routed to the new node
          properly by each BBS in the network. This information (and any
          changes you make to it later) are saved in the Index on each
           ___________________________________________________________

                                        10



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

          Realm. This data can be used later by the Sysop's to restore
          your `Default' configuration should they need to do so. The
          Sysop on each of these BBS's need not even know that a new
          node has been added, yet the game will know of it, recognise
          it and route to it seamlessley. An entry will also appear in
          the game news files informing players of the arrival of the
          new Realm.
       2.  Your local index file will be updated to reflect the change.
          Ie, the Pending status on the node in your Index will be
          changed to Active.
             
          A few safety nets and warning systems exist here for you :

       1.  If for some reason the `Connect To' node is not listed on a
          BBS's index, the new node will have it's information routed to
          the Default Outbound node, as defined for that BBS. While not
          as sure as a `Connect To' node, it is a likely bet that this
          will adequately route the mail to where it should be going.
       2.  As well as 1 above if the `Connect To' isn't found, a netmail
          message is sent back to you, the Coordinator, informing you of
          a problem with that node. The problem is, of course, that they
          don't have a node on their Index that should be there. In such
          cases, you may want to get them to pick up another copy or
          your distribution Index or distribute another node addition to
          make sure they're up-to-date in case a previous addition got
          lost or misprocessed for some reason.
       3.  If the node already exists, the add will be aborted and a
          netmail message returned to the Coordinator informing him or
          her of the situation. This perhaps isn't a problem, but that
          is best determined by yourself should you find it has
          happened.


          2.5. Modifying Nodes

          Modifying nodes is also a simple matter under Kingdoms.  For
          any node in your Index, you can distribute changes to any
          node's Sysop Name, BBS Name and/or address.

          As you may be aware, a system's real Sysop & BBS names are
          used to match up with Kingdoms registration numbers.  You may
          think therefore that you shouldn't change a Sysop name & BBS
          name or a registered node will suddenly find it's rego key no
          longer matches these fields. This is not the case. What you
          are modifying if you do this are those names in the INDEX
          file, not in the remote Realm's configuration file. Index file
          searches are based on address only, not Sysop/BBS name, so
          anything really can be placed in this field without affecting
          Kingdoms adversley.  For example, `Dave Chapman' on `The Web
          BBS' in the Web's configuration could be called `Draken Noir'
          on `Dragons Lair' on the Index (and thus have the Realm known
          as DragonsLair, network wide) without a problem.

          These name fields can be changed as often and as much as you
          like, but try to minimise use of the facility, particularly
          for the BBS name. It can get confusing to players if a Realm
          they're used to seeing there changes name all the time.
           ___________________________________________________________

                                        11



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

          Changing the BBS Address is done in much the same way. You
          simply choose the C>hange N>ode functions in the manager, then
          type in the modified address.  When you confirm your changes,
          the modifications are automatically distributed to the network
          for you. The address change on all Realms, including your own,
          will automatically set up an Alias for the old address on each
          node so mail in transit - even though it's destination may be
          the old address when the change takes place on each Realm - is
          smoothly routed to the correct (new) address.




          2.6. Deleting Nodes

          Similar to adding a new node, there are two steps to deleting
          a node on your network. The first delete you issue for a
          particular node does not actually delete the node. Instead, it
          marks it `Inactive'. This way you can `turn someone off'
          without having to re-add them at a later stage should you
          change your mind. The node will stay Inactive until another
          Delete order is issued by the coordinator, or until it is
          returned to normal operation, again by the coordinaor. Of
          course, setting a node Inactive will set it Inactive on ALL
          Realms, not just on your own.

          If at some stage you decide you really do want to delete the
          node, simply issue a second Delete Node request for that node.
          On all realms in the network, the node will be irrevocably
          deleted. If you want to bring it back at this stage, you will
          have to go through the Add Node procedure.

          A few notes on deleting a node :

       .  An Inactive node is simply ignored by Kingdoms completely for
          all things. Maintenance will not request recons from it,
          Inbounds from it (eg, Invasions) will be ignored and not
          processed, Players will not see it and will not be able to
          select it for activity.

       .  It doesn't matter how long you leave an Inactive node inactive
          for.

       .  The options `Enable a new node' and `Reactivate a node' are
          different. You `Enable' a Pending node to make it active. You
          `Reactivate' an Inactive (deleted once) node to bring it back
          up on the Network.



          2.7. Reactivating Nodes

          It is quite possible that you've deleted a node for whatever
          reason and find later (before you've issued another delete and
          removed it permanently!) that you want to make it active
          again. This option will do that for you. When selected, it
          will give you a list of all Realms in  your Index that are
           ___________________________________________________________

                                        12



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

          marked `Inactive'. Simply highlight the node you want to
          reactivate and press Enter. Upon confirming this is what you
          want to do, the node will be reactivated on your Index file,
          and an instruction will be sent to all other nodes to do the
          same.

          Unless you do something further to the node, it will again be
          an active Realm, just like any other.



          2.8. Index File Dump

          This option is there simply so that, should you want to, you
          can get a `raw' dump of your Index file. All info pertinent to
          each node is provided nicely formatted and can be printed or
          used as you wish. Obviously, this is a dump of the file only -
          changing data here will NOT be reflected back in the real
          Index file in any way.


          2.9. Resetting the Game


          2.9.1. Overview
          As you may be aware, any individual Sysop can reset their
          Kingdoms game at any time by using the /RESET parameter on
          KMNT. As the Coordinator Realm you can do this also, but you
          also have the power to issue a Reset on a NETWORK WIDE basis.
          The reset can take place on a certain day anywhere between
          five and 100 days (inclusive) in the future.


          2.9.2. Issuing a Reset
          When you choose the `rEset the Game' option, you will be asked
          the date you want a reset to take place. Because this is such
          an important option, you must give the date in very precise
          format - dd-mm/ccyy (day/month/century-year), including zeros
          where appropriate. The first of March, 1996 then would be
          entered as 01-03-1996. NO other format will be permissable and
          the date entry routine checks for leap years as well to ensure
          no invalid dates are accepted.

          Having chosen a date, you will be asked if you want nodes to
          return a message to you to acknowledge receipt of the reset
          instruction. It's a good idea to do so as this will allow you
          to make sure everyone received it properly, but you don't have
          to request receipts if you don't want them. If you do, all
          nodes that receive the reset command and process the
          instruction will send a message back to you which will appear
          in your Coordinator's log (NOT in the game logs), telling you
          it was accepted and confirming the appropriate date.

          Lastly, the reset info will be redisplayed to ensure you have
          it right and responding `yes' to the final confirm will issue
          the Reset instruction network wide.

           ___________________________________________________________

                                        13



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

          Two things will happen to let Kingdoms players on all realms
          know of the impending Reset. Firstly, a message will be placed
          in the game news files when the reset command is received. On
          your local realm, of course, this will appear in the news
          immediately. On each day when there are five days or less
          remaining before the reset, another message will appear in the
          `Todays News' file for the players stating it's due, and how
          many days remain before the Reset takes place. This should
          give players ample notice that it's coming!


          2.9.3. How It's Done
          As you may have gathered, KMNT is the vehicle by which a Reset
          is achieved. When it runs, KMNT will always check for a
          pending reset (you can always look yourself at F)ile->O)ther
          in the Manager for a reset date if one is due) and when the
          day comes around, it will Reset the game rather than running
          the normal maintenance process.

          The process is fairly simple on the local Realm. The User file
          is initialised, the message base trashed etc etc. All Outbound
          packets are also deleted to get rid of network traffic
          belonging to the `old' game. A few problems and issues are
          evident here however, which will now be examined/explained :

       .  In a Reset situation, Sysop's on individual boards may
          override a Coordinator's Reset by using the /NORESET parameter
          in KMNT. Also, the system may simply be down or have some
          error on the day the Reset is due and for that reason it may
          simply not run. For this reason, KMNT will continue to attempt
          to honor a Coordinator Reset indefinately each time
          maintenance runs after the reset is due, if the reset has not
          already been done. This should give ample time for those
          systems with problems to correct them, run maintenance, and
          have the Reset processed as it should be. In the case where a
          Sysop overrides the Reset, Kingdoms will send a message back
          to the Coordinator (which will appear in the Coordinator log)
          informing him or her of the situation. You may have wanted
          that to happen, in which case you can deal with it as you see
          fit. Otherwise, you can contact the Sysop directly to find out
          why this has happened and to request them to remove the
          override. If they still won't do it for some reason, it is
          perfectly within the Coordinator's power to disable the Realm
          network wide as incencitve. A Sysop can't override that
          command. :-)

       .  Due to time zone differences and such also, it is quite
          possible for data to be floating around the network that is
          not removed during the Reset. To solve this, no data will be
          accepted by inbound processing excluding Recon and Network
          Timing requests/responses for 20 days after the reset date on
          any Realm. Any such data will simply be deleted as it arrives,
          thus clearing the network of old traffic.




           ___________________________________________________________

                                        14



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________

          2.10. Coordinator Log

          This option gives you immediate access to your Coordinator
          Log. All Coordinator Activity is recorded in this log and time
          stamped so you can keep track of what changes you've made to
          the network and when. Because you may want to keep this some
          time to maintain an historical record of past events,
          maintenance will NEVER trim or roll over this log as it does
          the newsfiles. You can, of course, delete it or rename it
          (KCOORD.LOG) at any time if you wish - Kingdoms will just
          recreate it when it needs to write something to it if it isn't
          already there.


          2.15. Link Diagram

          Particularly useful for the Coordinator, though it's also
          available to Sysops on their Network menu as well, the Link
          Diagram creates a `picture' of your network, based on the
          Default network links specified in the Index. This is a very
          handy means of both seeing at a glance who you have connected
          to who on the network and verifying all links are as they
          should be. More information, as it pertains to the Sysop's
          point of view, is available in the Manager documentation under
          the section titled `Link Diagram' which may be of interest.


          2.12. Net Connections

          This option allows you to change the default connections of
          any node in the network. This change is propogated to ALL
          Index files on all Realms in your network of course, not just
          your own. While very simple to use, it is an extremely
          powerful function as it is the crux of automating network
          routing in Kingdoms. When you change a network connection
          (simply by selecting the new node a realm connects to), the
          change data will be propogated to all nodes in the network.
          Upon receipt of the change, the inbound processor on each node
          will apply it and re-evaluate ALL connections to optimize the
          routing definitions on the node and bring into effect any
          changes required by the new connection rules.
















           ___________________________________________________________

                                        15



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________


          SECTION 3.0. TRACKING PROBLEMS

          To you, the Kingdoms Coordinator, it is particularly important
          that you are able to track network problems. Realms may go
          offline for any number of reasons that may not even be their
          own fault. For example, a Realm feeding another Kingdoms data
          may simply set their routing incorrectly, meaning that realm
          never gets its data. Both Worms and Routing Rules are powerful
          options that can help you track these types of errors. They
          are covered fully in the Sysop documentation, KSYSOP.DOC, so I
          won't talk about them again here. Please refer to that
          document if you need to know more about them.












































           ___________________________________________________________

                                        16



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________


          Appendix A : New Node Application

          You may use the form below as your formal `application' form
          for joining your Kingdoms network. All people need to is fill
          it in then send it to you. It contains all the information you
          need to add a BBS to your Index.



          ----------------------------------------------------------


          Kingdoms Network Node Addition Application


          BBS Name            : ____________________________________


          Sysop Name          : ____________________________________


          Address             : ________ : ________ / ________


          Connect To          : ________ : ________ / ________


          NetID (if known)    : __________

          This form is used to gain access to a Kingdoms network. You
          should crash it through to your Coordinator who will process
          your addition and see it is added to all nodes in the index.

          ----------------------------------------------------------





















           ___________________________________________________________

                                        17



            KINGDOMS v2.18           Network Coordinator Documentation
           ___________________________________________________________


           Appendix B : Known Network ID's.

           Kingdoms was first released on March 13st, 1996. Since that
           time it has gained considerable popularity which shows no
           sign of abating! With it of course, the number of networks
           running the game also continues to rise! In order to assist
           you in selecting unique NetId's for your league, the NetIDs
           which are known at the time of writing are supplied here.
           When you choose one for yourself, PLEASE take the time to let
           me know so I can add it to the list and help you keep your id
           unique in the world!

           Known Kingdoms NetId's as at October 15th, 1996


NetId 11:Beta Test League, Sydney, Australia. Dave Chapman, 61-2-9528-5941
NetId 69:BattleNet League, Glossodia, NSW, Australia. Rob Wilson, 61-45-76-6185
NetId 01:Dead Zone League, Cincinnati, Ohio. Michael Baker, 1-513-521-0705
NetId GL:Gollums League, Ontario, Canada. Ray Smith, 1-613-634-6160
NetId RF:RaysFire League, Kansas City, Kansas. Ray Juliano, 1-913-299-6552
NetId MC:LinearNet League, Dallas, Texas. Marty Crum, 1-214-275-5040
NetId 88:Adventurealm League, Hong Kong. Royden Lui, 852-2402-3162
NetId 75:PowerPlay League, Brisbane, Australia. Steve Lancaster, 61-7-3245-3689
NetId 99:WorldWide Games, Dayville, CT. Mark Pringle, 1-860-774-2889


           For a fully up-to-date list, please visit our web page at
                 http://www.magna.com.au/~davec/kingdom.htm.



                  * End of Coordinator Documentation *
























           ___________________________________________________________

                                        18


