270 lines
10 KiB
Plaintext
270 lines
10 KiB
Plaintext
$Id: ts6.txt 6 2005-09-10 01:02:21Z nenolod $
|
|
|
|
TS6 Proposal (v7)
|
|
Written by Lee H <lee@leeh.co.uk>
|
|
Ideas borrowed heavily from ircnet (Beeth, jv, Q)
|
|
|
|
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.
|
|
|