Permalink
Browse files

Add docs for m_spanningtree.

  • Loading branch information...
1 parent dc39ffe commit 78aa90cf84edef8258f6c488e80fa0bb5accbef6 @SaberUK SaberUK committed May 23, 2012
View
No changes.
@@ -48,4 +48,4 @@ m_censor.so,m_chanfilter.so,m_chanprotect.so,m_chghost.so,m_chgident.so,m_chgnam
<- :037 ADDLINE Z 66.66.66.66 <Config> 1220196025 0 :This is the devils ip. You cannot use it.
<- :037 ADDLINE Z 69.69.69.69 <Config> 1220196025 0 :No porn here thanks.
<- :037 ENDBURST
-</pre>
+</pre>
@@ -0,0 +1,33 @@
+InspIRCd has four behaviours when it routes a message. These four behaviours are chosen dependent
+upon the message and the target and source of that message individually. These behaviours are:
+
+One To One Routing (Directed)
+-----------------------------
+This is used to route a message from one server directly to another server, taking a route only
+through servers which need to process the message in order to pass it straight to its destination.
+Examples of this are PRIVMSG and NOTICE direct to a user (not to a channel) and any messages
+exchanged during the initial burst and authentication phase.
+
+One to all (Broadcast)
+----------------------
+
+This is used to broadcast a message to all servers, and each server which receives such a message
+will then pass it on to its peers using "one to all-but-one" as shown below. This is used for
+messages which the entire network must see to remain synchronized, e.g. NICK and QUIT.
+
+One to all-but-one
+------------------
+
+This is used to pass on a "one to all" message which has originated from another server. The message
+may not be passed on via a second "one to all" message, because doing so would bounce the message
+back along the network to its source and cause a desync.
+
+One to group
+------------
+
+This is used only by channel PRIVMSG and NOTICE. To cut down on bandwidth, channel PRIVMSG and
+NOTICE are not broadcast. To achieve routing for these types of message, a list is compiled
+consisting only of locally connected servers the PRIVMSG or NOTICE must be sent to in order to
+reach all of its recipients. Each recipient is then responsible for running the message against
+this algorithm again to ensure it eventually reaches all intended recipients, and no extra servers
+which do not have users on the channel will receive the message or act upon it.
@@ -0,0 +1,25 @@
+The InspIRCd 1.2+ spanningtree protocol adopts a TS6-like nickname collision algorithm which
+minimises the impact of nickname collisions and prevents most if not all KILLs when a collision
+does occur.
+
+The rules for nickname collision are as follows:
+
+**If the user@ip of the two colliding users are equal:** Force nick change on OLDER client which
+changed their nickname first (this is to prevent penalizing users who have reconnected, so that
+their 'ghost' does not win the collision).
+
+**If the user@ip of the two colliding users differ:** Force nick change on NEWER client which
+changed their nickname last (this is to help prevent users camping on nicknames, causing a
+collision and stealing that nickname during the resync).
+
+**If the timestamps of the clients are equal**: Force a nick change on both.
+
+Where nickname changes are enforced by this algorithm, the nickname is changed to the users UUID.
+Because the user's UUID contains a leading digit, it is impossible for any user to NICK to their
+UUID or anyone elses UUID and 'camp' on it. Only a server may force a nick change to such an
+'illegal' nickname.
+
+IMPORTANT NOTE: In a vanilla install of InspIRCd, there is no KILL message here for any collision
+scenario. However, it is possible that a third party module may deny the nickname change to UID,
+which will cause a last-resort Nickname collision KILL. Understandably, this is not a desirable
+situation, so care should be taken not to run such modules if this bothers you.
@@ -0,0 +1,25 @@
+InspIRCd has three types of server. Although the same in design, and speaking the same protocol,
+their behaviours are different due to the roles they play in maintaining the network. These are:
+
+Hub
+---
+
+A hub is categorized as any server which has more than one locally connected server. A hub differs
+from normal operation in that the bandwidth passing through a hub is usually much greater than that
+passing through a leaf, and it may expend more computing power to run a hub.
+
+Leaf
+----
+
+A leaf is categorized as any server which has only one, or no connected servers. A leaf does not
+have to route as much information as a hub (see above) but usually because of this is configured to
+hold many more clients as it has the spare computer power to hold the users.
+
+U-Line
+------
+
+A U-lined server is usually a leaf server, however in InspIRCd, a hub may also be U-lined. U-lined
+servers have many extra privileges, which are required for example to operate a services server or
+similar. U-lines must be individually configured on all servers to work, and all servers must be in
+agreement about the names of the U lined servers. If they are not in agreement, mode changes will be
+dropped and commands forbidden which should operate normally.
@@ -0,0 +1,44 @@
+UUIDs (Universally Unique User Identifiers)
+===========================================
+
+Our implementation and definition of SID, ID, and UID closely matches TS6's. That is:
+
+* **SID** - A servers unique ID. This is three characters long and must be in the form
+`[0-9][A-Z0-9][A-Z0-9]`. InspIRCd servers which are automatically generating their server IDs only
+ever use server id's in the range 000-999, leaving server id's with letters as reserved for third
+party servers such as services servers. This can help prevent collisions, as by default the SID is
+automatically generated by InspIRCd whereas in TS6 it is admin-specified.
+
+* ID - A clients unique ID. This is six characters long and must be in the form
+`[A-Z][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9]`. The numbers `[0-9]` at the beginning of an ID are
+legal characters, but reserved for future use.
+
+* UID or UUID - An ID concatenated to a SID. This forms the clients UID.
+
+When allocating a UID, InspIRCd will 'increment' the value, e.g. the ID after 001AAAAAA is
+001AAAAAB, which is followed by 001AAAAAC, etc etc. When the highest UID is reached, InspIRCd will
+"wrap around", starting again at 001AAAAAA. Note that if the ID the server tries to allocate already
+appears to be in use (possible after a wrap-around has occured) then the next ID in the sequence
+will be tried repeatedly, until a free ID is found. This differs from TS6 implementations, some of
+which will restart the server once the UID space has been exhausted.
+
+Server ID (SID) auto generation
+-------------------------------
+
+InspIRCd servers have the capability to automatically generate a server ID. This is done using the
+hash function for the GNU GCC hash_map against the server name and server GECOS. In pseudocode,
+this can be represented as:
+
+ SID := 0
+ FOR EVERY CHARACTER IN SERVER_NAME:
+ BEGIN
+ SID := 5 * SID + VALUE_OF_CHARACTER_IN_SERVER_NAME
+ END
+ FOR EVERY CHARACTER IN SERVER_GECOS
+ BEGIN
+ SID := 5 * SID + VALUE_OF_CHARACTER_IN_SERVER_GECOS
+ END
+ SID := SID MODULUS 999
+
+In the unlikely event that this automatically allocated ID conflicts with other IDs on the network,
+an ID must be manually specified in the configuration file.

0 comments on commit 78aa90c

Please sign in to comment.