diff options
Diffstat (limited to 'doc/technical/ts6.txt')
| -rw-r--r-- | doc/technical/ts6.txt | 267 |
1 files changed, 267 insertions, 0 deletions
diff --git a/doc/technical/ts6.txt b/doc/technical/ts6.txt new file mode 100644 index 0000000..d1e29e8 --- /dev/null +++ b/doc/technical/ts6.txt @@ -0,0 +1,267 @@ +$Id$ + +TS6 Proposal (v7) +Written by Lee H <lee@leeh.co.uk> + +Introduction +------------ + +This document aims to fix some of the flaws that are still present in the +current TS system. + +Whilst only one person may use a nickname at any one time, they are not +a reliable method of directing commands between servers. Clients can change +their nicknames, which can create desyncs. A reliable method of directing +messages between servers is required so that a message will always reach the +intended destination, even if the client changes nicks in between. + +UID solves this problem by ensuring that a client has a unique ID for the +duration of his connection. + +This document also aims to solve the lack of TS rules to channel 'bans' on +a netburst. Bans from both sides of a TS war (losing/winning) are kept. +Bursting the bans with a TS solves this problem. + +There is also a race condition in the current TS system, where a user can +issue a mode during a netburst and the mode will be set on the server +we are bursting to. + + +Definitions +----------- + +Throughout this document, the following terms are used: + +SID - A servers unique ID. This is three characters long and must be in + the form [0-9][A-Z0-9][A-Z0-9] +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 - An ID concateneted to a SID. This forms the clients UID. +TS6 - The TS version 6. + + +Support +------- + +Support for this document is given by the TS version 6. + +Wherever a destination parameter or source parameter is used, it must use +the SID or UID if the server/client has one. A TS6 capable server must +translate any SIDs/UIDs back into the server/clients name when communicating +with a server that does not support TS6. + +A TS6 server must also support the QS (quitstorm) system, and the encap +specification found here: +http://www.leeh.co.uk/ircd/encap.txt + +The TS6 protocol does not supports masked entities. + + +Nick TS rules +------------- + +A server receiving a command that requires nick TS rules must check for a +collision between an existing user, and the nick in the received message. +(the "new user"). The collisions must obey the rules specified in Nick TS +collisions. + +If the TS received is lower than the TS of the existing user the server will +collide the existing user if the clients user@host are different, if the +clients user@hosts are identical it will collide the new user. + +If the TS received is equal to the TS of the existing user both clients are +collided. + +If the TS received is higher than the TS of the existing user, the server +will collide the existing user if the user@hosts are identical, if the +clients user@host are different it will collide the new user and drop the +message. + + +Nick TS collisions +------------------ + +If both users are to be collided, we must issue a KILL for the existing +user to all servers. If the new user has a UID then we must also issue a +KILL for that UID back to the server sending us data causing the collision. + +If only the existing user is being collided, we must issue a KILL for the +existing user to all servers except the server sending us data. If the +existing user has a UID and the server sending us data supports TS6 then +we must also issue a KILL for the existing users UID to the server sending +us data. + +If only the new user is being collided, we must issue a KILL for the new user +back to the server sending us data if the new user has a UID. + + +Channel TS rules +---------------- + +A server receiving a command that requires normal channel TS rules must +apply the following rules to the command. + +If the TS received is lower than our TS of the channel a TS6 server must +remove status modes (+ov etc) and channel modes (+nt etc). If the +originating server is TS6 capable (ie, it has a SID), the server must +also remove any ban modes (+b etc). The new modes and statuses are then +accepted. + +If any bans are removed, the server must send to non-TS6, directly connected +servers mode changes removing the bans after the command is propagated. +This prevents desync with banlists, and has to be sent after as clients are +still able to send mode changes before the triggering command arrives. + +If the TS received is equal to our TS of the channel the server should keep +its current modes and accept the received modes and statuses. + +If the TS received is higher than our TS of the channel the server should keep +its current modes and ignore the received modes and statuses. Any statuses +given in the received message will be removed. A server must mark clients +losing their op (+o) status who do not have a UID as 'deopped'. A server must +ignore any "MODE" commands from a user marked as 'deopped'. + + +Simple channel TS rules +----------------------- + +A server receiving a command that requires simple channel TS rules must +apply the following rules to the command. + +If the TS received is lower, or equal to our TS of the channel the modes are +accepted. If the TS received is higher than our TS of the channel the modes +are ignored and dropped. + +Simple channel TS rules do not affect current modes in the channel except +for the modes we are accepting. + + +The following commands are defined here as the TS6 protocol +----------------------------------------------------------- + +PASS: +PASS <PASSWORD> TS <TS_CURRENT> :<SID> + +This command is used for password verification with the server we are +connecting to. + +Due to the burst being sent on verification of the "SERVER" command, and +"SVINFO" being sent after "SERVER", we need to be aware of the TS version +earlier to decide whether to send a TS6 burst or not. + +The <PASSWORD> field is the password we have stored for this server, +<TS_CURRENT> is our current TS version. If this field is not present then +the server does not support TS6. <SID> is the SID of the server. + +UID: +:<SID> UID <NICK> <HOPS> <TS> +<UMODE> <USERNAME> <HOSTNAME> <IP> <UID> :<GECOS> + +This command is used for introducing clients to the network. + +The <SID> field is the SID of the server the client is connected to. +The <NICK> field is the nick of the client being introduced. The <HOPS> +field is the amount of server hops between the server being burst to and +the server the client is on. The <TS> field is the TS of the client, either +the time they connected or the time they last changed nick. The <UMODE> +field contains the clients usermodes that need to be transmitted between +servers. The <USERNAME> field contains the clients username/ident. The +<HOSTNAME> field contains the clients host. + +The <IP> field contains the clients IP. If the IP is not to be sent +(due to a spoof etc), the field must be sent as "0". The <UID> field is the +clients UID. The <GECOS> field is the clients gecos. + +A server receiving a UID command must apply nick TS rules to the nick. + +SID: +:<SID> SID <SERVERNAME> <HOPS> <SID> :<GECOS> + +This command is used for introducing servers to the network. + +The first <SID> field is the SID of the new servers uplink. The +<SERVERNAME> field is the new servers name. The <HOPS> field is the hops +between the server being introduced nd the server being burst to. + +The second <SID> field is the SID of the new server. The <GECOS> field i +is the new servers gecos. + +Upon receiving the SID command servers must check for a SID collision. +Two servers must not be allowed to link to the network with the same SID. +If a server detects a SID collision it must drop the link to the directly +connected server through which the command was received. + +Client and servers which do not have a UID/SID must be introduced by old +methods. + +SJOIN: +:<SID> SJOIN <TS> <CHANNAME> +<CHANMODES> :<UIDS> + +This command is used for introducing users to channels. + +The <SID> field is the SID of the server introducing users to the channel. +The <TS> field is the channels current TS, <CHANNAME> is the channels +current name, <CHANMODES> are the channels current modes. <UIDS> is a +space delimited list of clients UIDs to join to the channel. Each clients +UID is prefixed with their status on the channel, ie "@UID" for an opped +user. Multiple prefixes are allowed, "peons" (clients without a status) are +not prefixed. + +A server receiving an SJOIN must apply normal channel TS rules to the SJOIN. + +A TS6 server must not use the SJOIN command outside of a netburst +to introduce a single user to an existing channel. It must instead +use the "JOIN" command defined in this specification. A TS6 server must +still use SJOIN for creating channels. + +JOIN: +:<UID> JOIN <TS> <CHANNAME> +<CHANMODES> + +This command is used for introducing one user unopped to an existing channel. + +The <UID> field is the UID of the client joining the channel. The +<TS> field is the channels current TS, <CHANNAME> is the channels +current name, <CHANMODES> are the channels current modes. + +A server receiving a JOIN must apply normal channel TS rules to the JOIN. + +It should be noted that whilst JOIN would not normally create a +channel, during specific race conditions it can. This can create +a ban desync that this specification does not rectify. + +BMASK: +:<SID> BMASK <TS> <CHANNAME> <TYPE> :<MASKS> + +This command is used for bursting channel bans to a network. + +The <SID> field is the SID of the server bursting the bans. The +<TS> field is the channels current TS, <CHANNAME> is the channels +name. <TYPE> is a single character identifying the mode type (ie, +for a ban 'b'). <MASKS> is a space delimited list of masks of the +given mode,limited only in length to the size of the buffer as defined +by RFC1459. + +A server receiving a BMASK must apply simple channel TS rules to the BMASK. + +A TS6 server must translate BMASKs into raw modes for non-TS6 +capable servers. This command must be used only after SJOIN has +been sent for the given channel. + +It should be noted however, that a BMASK with a lower TS should +not be possible without a desync, due to it being sent after +SJOIN. + +TMODE: +:<UID> TMODE <TS> <CHANNAME> <MODESTRING> + +This command is used for clients issuing modes on a channel. + +<UID> is the UID of the client setting the mode. <TS> is the +current TS of the channel, <CHANNAME> is the channels name. +<MODESTRING> is the raw mode the client is setting. + +A server receiving a TMODE must apply simple channel TS rules to the TMODE. + +A TS6 server must translate MODEs issued by a local client into TMODE +to send to other TS6 capable servers. |