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 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 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 NetID’s 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