Protocol changes for +TSora
---------------------------
Note:
The protocols described here implement TimeStamps on IRC channels and
nicks. The idea of IRC TimeStamps was started on Undernet, and first
implemented by Run <carlo@runaway.xs4all.nl>. The protocols used here
are not exactly the same as the ones used on Undernet; the nick-kill
handling is very similar and must be credited to Run, while the
"TimeStamped channel description" protocol is quite different.
TSora servers keep track of which version of the TS protocol (if any)
their neighboring servers are using, and take it into account when
sending messages to them. This allows for seamless integration of TS
servers into a non-TS net, and for upgrades of the protocol.
Each server knows which is the lowest and the highest version of the
TS protocol it can interact with; currently both of these are set to 1:
#define TS_CURRENT 1 /* the highest TS ver we can do */
#define TS_MIN 1 /* the lowest TS ver we can do */
Timings and TS versions:
========================
. Keep a 'delta' value to be added to the result of all calls to time(),
initially 0.
. Send a second argument to the PASS command, ending in the 'TS' string.
. Send a
SVINFO <TS_CURRENT> <TS_MIN> <STANDALONE> :<UTC-TIME>
just after "SERVER", where <STANDALONE> is 1 if we're connected to
more TSora servers, and 0 if not, and <UTC-TIME> is our idea of the
current UTC time, fixed with the delta.
. When we receive a "SVINFO <x> <y> <z> :<t>" line from a connecting
server, we ignore it if TS_CURRENT<y or x<TS_MIN, otherwise we
set a flag remembering that that server is TS-aware, remember the TS
version to use with it (min(TS_CURRENT, x)). Additionally, if this is
our first connected TS server, we set our delta to t-<OUR_UTC> if
z==0, and to (t-<OUR_UTC>)/2 if z!=0. The SVINFO data is kept around
until the server has effectively registered with SERVER, and used
*after* sending our own SVINFO to that server.
Explanations:
Servers will always know which of their directly-linked servers can do
TS, and will use the TS protocol only with servers that do understand
it. This makes it possible to switch to full TS in just one
code-replacement step, without incompatibilities.
As long as not all servers are TS-aware, the net will be divided into
"zones" of linked TS-aware servers. Channel modes will be kept
synchronized at least within the zone in which the channel was
created, and nick collisions between servers in the same zone will
result in only one client being killed.
Time synchronization ensures that servers have the same idea of the
current time, and achieves this purpose as long as TS servers are
introduced one by one within the same 'zone'. The merging of two zones
cannot synchronize them completely, but it is to be expected that
within each zone the effective time will be very close to the real
time.
By sending TSINFO after SERVER rather than before, we avoid the extra
lag created by the identd check on the server. To be able to send
immediately a connect burst of either type (TS or not), we need to
know before that if the server does TS or not, so we send that
information with PASS as an extra argument. And to avoid being
incompatible with 2.9 servers, which check that this second argument
begins with "2.9", we check that it *ends* with "TS".
The current time is only used when setting a TS on a new channel or
nick, and once such a TS is set, it is never modified because of
synchronization, as it is much more important that the TS for a
channel or nick stays the same across all servers than that it is
accurate to the second.
Note that Undernet's 2.8.x servers have no time synchronization at
all, and have had no problems because of it - all of this is more to
catch the occasional server with a way-off clock than anything.
NICK handling patches (anti-nick-collide + shorter connect burst):
==================================================================
. For each nick, store a TS value = the TS value received if any, or our
UTC+delta at the time we first heard of the nick. TS's are propagated
to TS-aware servers whenever sending a NICK command.
. Nick changes reset the TS to the current time.
. When sending a connect burst to another TS server, replace the
NICK/USER pair with only one NICK command containing the nick, the
hopcount, the TS, the umode, and all the USER information.
The format for a full NICK line is:
NICK <nick> <hops> <TS> <umode> <user> <host> <server> :<ircname>
The umode is a + followed by any applying usermodes.
The format for a nick-change NICK line is:
:<oldnick> NICK <newnick> :<TS>
. When a NICK is received from a TS server, that conflicts with an
existing nick:
+ if the userhosts differ or one is not known:
* if the timestamps are equal, kill ours and the old one if it
was a nick change
* if the incoming timestamp is older than ours, kill ours and
propagate the new one
* if the incoming timestamp is younger, ignore the line, but kill
the old nick if it was a nick change
+ if the userhosts are the same:
* if the timestamps are equal, kill ours and the old one if it
was a nick change
* if the incoming timestamp is younger, kill ours and propagate
the new one
* if the incoming timestamp is older, ignore the line but kill
the old nick if it was a nick change
. When a NICK is received from a non-TS server that conflicts with
an existing nick, kill both.
. Do not send "Fake Prefix" kills in response to lines coming from TS
servers; the sanitization works anyway, and this allows the "newer
nick overruled" case to work.
Explanations:
The modified nick-introduction syntax allows for a slightly shorter
connect-burst, and most importantly lets the server compare
user@host's when determining which nick to kill: if the user@host
is the same, then the older nick must be killed rather than the
newer.
When talking to a non-TS server, we need to behave exactly like one
because it expects us to. When talkign to a TS server, we don't kill
the nicks it's introducing, as we know it'll be smart enough to do it
itself when seeing our own introduced nick.
When we see a nick arriving from a non-TS server, it won't have a TS,
but it's safe enough to give it the current time rather than keeping
it 0; such TS's won't be the same all across the network (as long as
there is more than one TS zone), and when there's a collision, the TS
used will be the one in the zone the collision occurs in.
Also, it is important to note that by the time a server sees (and
chooses to ignore) a nick introduction, the introducing server has
also had the time to put umode changes for that nick on its queue, so
we must ignore them too... so we need to ignore fake-prefix lines
rather than sending kills for them. This is safe enough, as the rest
of the protocol ensures that they'll get killed anyway (and the
Undernet does it too, so it's been more than enough tested). Just for
an extra bit of compatibility, we still kill fake prefixes coming from
non-TS servers.
This part of the TS protocol is almost exactly the same as the
Undernet's .anc (anti-nick-collide) patches, except that Undernet
servers don't add usermodes to the NICK line.
TimeStamped channel descriptions (avoiding hacked ops and desynchs):
====================================================================
. For each channel, keep a timestamp, set to the current time when the
channel is created by a client on the local server, or to the received
value if the channel has been propagated from a TS server, or to 0
otherwise. This value will have the semantics of "the time of creation
of the current ops on the channel", and 0 will mean that the channel
is in non-TS mode.
A new server protocol command is introduced, SJOIN, which introduces
a full channel description: a timestamp, all the modes (except bans),
and the list of channel members with their ops and voices. This
command will be used instead of JOIN and of (most) MODEs both in
connect bursts and when propagating channel creations among TS
servers. SJOIN will never be accepted from or sent to users.
The syntax for the command is:
SJOIN <TS> #<channel> <modes> :[@][+]<nick_1> ... [@][+]<nick_n>
The fields have the following meanings:
* <TS> is the timestamp for the channel
* <modes> is the list of global channel modes, starting with a +
and a letter for each of the active modes (spmntkil), followed
by an argument for +l if there is a limit, and an argument for
+k if there's a key (in the same order they were mentioned in
the string of letters).
A channel with no modes will have a "+" in that field.
A special value of "0" means that the server does not specify the
modes, and will be used when more than one SJOIN line is needed
to completely describe a channel, or when propagating a SJOIN
the modes of which were rejected.
* Each nick is preceded by a "@" if the user has ops, and a "+" if
the user has a voice. For mode +ov, both flags are used.
SJOINs will be propagated (when appropriate) to neighboring TS
servers, and converted to JOINs and MODEs for neighboring non-TS
servers.
To propagate channels for which not all users fit in one
SJOIN line, several SJOINs will be sent consecutively, only the first
one including actual information in the <mode> field.
An extra ad-hoc restriction is imposed on SJOIN messages, to simplify
processing: if a channel has ops, then the first <nick> of the first
SJOIN sent to propagate that channel must be one of the ops.
Servers will never attempt to reconstruct a SJOIN from JOIN/MODE
information being received at the moment from other servers.
. For each user on a channel, keep an extra flag (like ops and voice)
that is set when the user has received channel ops from another
server (in a SJOIN channel description), which we rejected (ignored).
Mode changes (but NOT kicks) coming from a TS server and from someone
with this flag set will be ignored. The flag will be reset when the
user gets ops from another user or server.
. On deops done by non-local users, coming from TS servers, on channels
with a non-zero TS, do not check that the user has ops but check that
their 'deopped' flag is not set. For kicks coming from a TS server, do
not check either. This will avoid desynchs, and 'bad' modechanges are
avoided anyway. Other mode changes will still only be taken into
account and propagated when done by users that are seen as having ops.
. When a MODE change that ops someone is received from a server for a
channel, that channel's TS is set to 0, and the mode change is
propagated.
. When a SJOIN is received for a channel, deal with it in this way:
* received-TS = 0:
+ if we have ops or the SJOIN doesn't op anyone, SJOIN propagated
with our own TS.
+ otherwise, TS set to 0 and SJOIN propagated with 0.
* received-TS > 0, own-TS = 0:
+ if the SJOIN ops someone or we don't have ops, set our TS to the
received TS and propagate.
+ otherwise, propagate with TS = 0.
* received-TS = own-TS: propagate.
* received-TS < own-TS:
+ if the SJOIN ops someone, remove *all* modes (except bans) from
the channel and propagate these mode changes to all neighboring
non-TS servers, and copy the received TS and propagate the SJOIN.
+ if the SJOIN does not op anyone and we have ops, propagate
with our own TS.
+ otherwise, copy the received TS and propagate the SJOIN.
* received-TS > own-TS:
+ if the SJOIN does not introduce any ops, process and propagate
with our own TS.
+ if we have ops: for each person the mode change would op, set the
'deopped' flag; process all the JOINs ignoring the '@' and '+'
flags; propagate without the flags and with our TS.
+ if we don't have ops: set our TS to the received one, propagate
with the flags.
Explanations:
This part of the protocol is the one that is most different (and
incompatible) with the Undernet's: we never timestamp MODE changes,
but instead we introduce the concept of time-stamped channel
descriptions. This way each server can determine, based on its state
and the received description, what the correct modes for a channel
are, and deop its own users if necessary. With this protocol, there is
*never* the need to reverse and bounce back a mode change. This is
both faster and more bandwith-effective.
The end goal is to have a protocol will eventually protect channels
against hacked ops, while minimizing the impact on a mixed-server net.
In order to do this, whenever there is a conflict between a TS server
and a non-TS one, the non-TS one's idea of the whole situation
prevails. This means that channels will only have a TS when they have
been created on a TS-aware server, and will lose it whenever a server
op comes from a non-TS server. Also, at most one 'zone' will have a TS
for any given channel at any given time, ensuring that there won't be
any deops when zones are merged. However, when TS zones are merged, if
the side that has a TS also has ops, then the TS is kept across the
whole new zone. Effective protection will only be ensured once all
servers run TS patches and channels have been re-created, as there is
no way servers can assign a TS to a channel they are not creating
(like they do with nicks) without having unwanted deops later.
The visible effects of this timestamped channel-description protocol
are that when a split rejoins, and one side has hacked ops, the other
side doesn't see any server mode changes (just like with Undernet's
TS), but the side that has hacked ops sees:
* first the first server on the other side deopping and devoicing
everyone, and fixing the +spmntkli modes
* then other users joining, and getting server ops and voices
The less obvious part of this protocol is its behavior in the case
that the younger side of a rejoin has servers that are lagged with
each other. In such a situation, a SJOIN that clears all modes and
sets the legitimate ones is being propagated from one server, and
lagged illegitimate mode changes and kicks are being propagated in the
opposite direction. In this case, a kick done by someone who is being
deopped by the SJOIN must be taken into account to keep the name list
in sync (and since it can only be kicking someone who also was on the
younger side), while a deop does not matter (and will be ignored by
the first server on the other side), and an opping *needs* to be
discareded to avoid hacked ops.
The main property of timestamped channel descriptions that makes them
a very stable protocol even with lag and splits, is that they leave a
server in the same final state, independently of the order in which
channel descriptions coming from different servers are received. Even
when SJOINs and MODEs for the same channel are being propagated in
different direction because of several splits rejoining, the final
state will be the same, independently of the exact order in which each
server received the SJOINs, and will be the same across all the
servers in the same zone.
fd552b946a