KINGDOMS

NETWORK COORDINATOR DOCUMENTATION

Version 2.23

 

Programming & Design - Dave Chapman - The Web BBS

Copyright © 1993-1998, Dave Chapman. All Rights Reserved

3:712/523@FidoNet - 169:3005/2@BattleNet

InterNet - kingdoms@tpgi.com.au

- Kingdoms Support Page -

http://www1.tpgi.com.au/users/kingdoms

 

 

TABLE OF CONTENTS

Section 1 : Coordinator Overview *

1.1. Document Purpose *

1.2. So you want to be a Coordinator? *

1.3. Network Overview *

1.3.1. Technical *

1.4. Terms and Definitions *

1.4.1. The Index *

1.4.2. Routing Rules *

1.4.3. Default Outbound *

1.4.4. Network Id *

SECTION 2.0. Up & Running *

2.1. Overview *

2.2. Choosing a Network ID *

2.3. Creating An Index *

2.4. Adding Nodes *

2.5. Modifying Nodes *

2.6. Deleting Nodes *

2.7. Reactivating Nodes *

2.8. Index File Dump *

2.9. Resetting the Game *

2.9.1. Overview *

2.9.2. Issuing a Reset *

2.9.2.1. Resetting a Realm *

2.9.2.2. Resetting a League *

2.9.3. How It’s Done *

2.10. Coordinator Log *

2.15. Link Diagram *

2.12. Net Connections *

SECTION 3.0. TRACKING PROBLEMS *

Appendix A : New Node Application *

 

Section 1 : Coordinator Overview

1.1. Document Purpose

This document explains what it is to be a Kingdoms Coordinator (known as a League Coordinator, or LC) and what tasks a LC 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.

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, deleting or modifying individual nodes.

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 FrontDoor or Blinkey 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. Unlike many other InterBBS games, 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 or it is empty, 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.

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 the 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 Leagu they’re in. It also allows an individual BBS to play in two (or more) different Kingdoms networks (ie, run two separate Kingdoms games in different Leagues) without each getting confused about which mail to direct to which game on their BBS.

Please note that though any combination of letters and numbers (not special characters) may be used in the Net Id for your League, it is not case sensitive. Thus, Kingdoms will consider Net Id "1a" as being the same league as Net Id "1A’.

 

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 :

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.

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 from BBS 3 and destined for BBS 6, ie, the 3rd and 6th 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://www1.tpgi.com.au/users/kingdoms.

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 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 :

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 :

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 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 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:

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

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. Other than choosing (and confirming) the Enable Node option from your coordinator menu, there is NOTHING more you need to do to make the new node active across your entire League. 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 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/existence 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 by Kingdoms 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.

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 you, the LC. 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 Realm. 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 :

 

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 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.

An example of an Index Dump for the Battlenet League (Netid 59) looks like :

Kingdoms 2.19 Index File Dump for Net 59. 12-08-1996 (1996343) at 13:31:50.

====== ============== ============================== ================ =====

Record BBS Address Realm Name Your Routing Mail

Node Status Realm Sysop Last Recon

Network Connect

====== ============== ============================== ================ =====

1 169:3800/5 RADAR'S wRECk ROOM This Node N/A

Co-Ord Radar No Recon

0:0/0

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

2 169:3800/1 MAX Default Outbound Hold

Active Peter Connerty No Recon

169:3800/5

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

... more nodes ...

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

20 169:3300/6 Enterprise BBS 169:3800/1 N/A

Active Andrew Seeger No Recon

169:3300/1

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

The fields for each Realm include :

 

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 if you want to reset your entire League, or just a specific Realm.

2.9.2.1. Resetting a Realm

Resetting a Specifid Realm is a very powerful function and should be used with caution. It is irreversable once issued, is immediate (when the instruction reaches the Realm in question, it cannot be cancelled and will happen as soon as Maintenance runs on that Realm) and cannot be overridden using the /NORESET switch in KMNT by the remote Sysop. I don’t think further explanation is necessary here - choosing this will fully reset the Kingdoms game running on the Realm chosen once you confirm and issue the instruction. As you may appreciate, this is a good vehicle for bringing errant Sysops into line if all else fails. :-)

2.9.2.2. Resetting a League

Having selected a League reset, 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.

Two things will happen to let Kingdoms players on all realms know of the impending League 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 :

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.

 

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.

Several Coordinators have asked me how to tell what node is running what version of Kingdoms. FYI, as of version 2.19, a Worm report returns current Kingdoms version numbers for all Realms through which they pass. Previously, this information was only available (and still is) by sending a routing report specifically to the node you wanted to know about.

 

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.

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

* End of Coordinator Documentation *