From 35b8492a1079022cfa5dc0c427220ae4ce5577f8 Mon Sep 17 00:00:00 2001 From: brain Date: Sun, 12 Feb 2006 21:25:09 +0000 Subject: Renamed inspire.* inspircd.* Removed obsolete server_tokens.txt git-svn-id: http://svn.inspircd.org/repository/trunk/inspircd@3173 e03df62e-2008-0410-955e-edbf42e46eb7 --- docs/server_tokens.txt | 397 ------------------------------------------------- 1 file changed, 397 deletions(-) delete mode 100644 docs/server_tokens.txt (limited to 'docs') diff --git a/docs/server_tokens.txt b/docs/server_tokens.txt deleted file mode 100644 index 6efbf9bd7..000000000 --- a/docs/server_tokens.txt +++ /dev/null @@ -1,397 +0,0 @@ -This is a list of all tokens used by InspIRCd at the time of writing for server to server communication. Module coders may find this information -useful when syncronising module data between different servers on the mesh. All tokens are case sensitive. Token names are given, however these are -just a way of identifying the token, so if you hear developers talking of the 'CHGNAME token' you can be sure they are talking about the 'a' symbol. - -Modules should try to avoid low ascii values. The only illegal token characters are ASCII 0, ASCII 13, and ASCII 10. - --------------------------------------------------------------------------------- -Compatibility Translations - -InspIRCd will translate some RFC-style commands into mesh tokens, to maintain compatibility with some services packages. This only occurs if the -server is a U-type link (see the tokens below for an explaination). The translated commands are: - - * 433 - Translated to * - * 432 - Translated to * - * PING - Translated to * - * NOTICE - Translated to V - * PRIVMSG - Translatd to P - * QUIT - Translated to Q - * SQUIT - Translated to & - * SVSMODE - Translated to m - * SVS2MODE - Translated to m - * MODE - Translated to m - * KICK - Translated to k - * KILL - Translated to K - * SVSJOIN - Translated to J - -IMPORTANT NOTE: Where the prefix on these commands is confused with a uniqueness sum (see below) the uniqueness sum for the command is set to '*' -which is a wildcard sum and is always accepted by all servers. - --------------------------------------------------------------------------------- -Uniqueness Sums - -Each command on the mesh is prefixed by a 'uniqueness sum' which is a random sequence (usually of 7 or 8 characters) which identifies that command. -Each server should keep a queue of the most recent commands sums, and should store up to 128 of the sums. When there are 128 sums in the list the -oldest should be removed from the list and the newest put into the list in its place, keeping constant 'rotation' of sums. The current implementation -simply generates the sums via the rand() function, there is no documented system for creating these uniqueness values, it is up to the person -implementing the system how these fields are generated, so long as there is minimal chance of a collision with other active sums on the network. - -If any server receives a command with a sum which is already in its list (no matter what the source of the command within the mesh is, to compensate -for redirect tokens, see below in the command specification) then the entire command is to be silently dropped without any attempt at processing. - -The sum value '*' should not be used, and is a special value which should cause all connected servers to always allow the command. Services servers -which do not directly support the mesh protocol, and must have their commands rewritten, may generate commands which have this sum. - -To avoid confusing parsers which are designed to process 'standard' irc server to server communication, each uniqueness sum is prefixed with a : -symbol. For example: - -:uniqueness-sum TOKEN param param :final param - -This makes it a simple matter to fetch the uniqueness sum from the 'source' field in the software's API, and process the rest of the data within the -parameters array, or however your software passes its data. - --------------------------------------------------------------------------------- -Mesh Tokens --------------------------------------------------------------------------------- -AuthCookie: - Token - -Syntax: - : - -When a server links into the mesh, it passes an Auth Cookie with its link request (in an S token). All other servers on the mesh respond by connecting -back to the initiating server and issuing this token with a valid auth cookie. If the auth cookie is valid, the server accepts their mesh link, -otherwise it rejects it. --------------------------------------------------------------------------------- -Inbound Server: S Token - -Syntax: S : - -To initiate a mesh link, a server must connect to the port given in its tag, and issue this command. The port number is the port number the -initiator is listening on for incoming server connections, it must be provided so that other servers in the mesh can link back and issue auth cookies. -This is known as an 'active' connect, e.g. the initiator always uses the uppercase S token. --------------------------------------------------------------------------------- -Set version reply: v Token - -Syntax: v - -This token indicates the version string of a server on the mesh. Rather than send it each time it is requested, inspircd simply updates the mesh with -its details either on bursting or if/when the data changes. --------------------------------------------------------------------------------- -Outbound Server: s Token - -Syntax: s : - -Upon receiving a valid S token, if the password and servername are accepted, the receiving server replies with this token. It is a different token to -S to avoid loops, and diffrentiate between initiator and receiver in the linking process. Once the initiator accepts the s token, the link is -established and the burst begins. --------------------------------------------------------------------------------- -Non-Mesh Server: U Token - -Syntax: U : - -The U token is similar to the S token in that it initiates a server to server link, but it is designed primarily to link systems which are not able to -become a fully meshed node, for example IRC Services packages. Upon a successful "U type" (as this is known) authentication, the other servers are -informed of the introduction of the server via means of a H token, but will never connect back to it, they will route all messages via its uplink -(messier than meshing it, but if the application is physically incapapable of joining the mesh, this is what must be done). --------------------------------------------------------------------------------- -Error: E Token - -Syntax: E : - -The E token indicates a protocol error, or invalid credentials etc, and immediately after an E token the connection is dropped. Failure to -authenticate during a link is usually the cause of such tokens being sent. --------------------------------------------------------------------------------- -Begin Netburst: Y Token - -Syntax: Y