This document was last modified on June 12th, 1996.
This document attempts to describe both the TS and Delay concepts in an objective manner. Since I am known to not like TS, I have asked several people to read this document and help me making it as objective as possible.
Why?
Both concepts (TS and Delay) attempt to solve two widely
known problems with IRC 2:
TS
TS stands for TimeStamp.
The protocol
is fully described by Roger Espel Llima, its author. It has
been added by Chris Behrens and Shrihari Pandit to their own
server versions.
Note:The nickname delay concept was first introduced in the so-called E1 patch (for 2.8.21) and is NOT the one implemented in the 2.9 version.
The following descriptions do not pretend to be complete.
The purpose of this document is to offer enough material for
someone to be able to decide which method is better, if any.
It is important to note that there are two very different
aspects of the problem:
This simple comparaison explains why Delay is often said to
be annoying while TS is said to be transparent, but I find
this to be a poor objection:
Both are 'transparent' to UserA, because he didn't know
anything odd happened.
Neither are 'transparent' to UserB, because in both cases,
something unexpected happened as a result of trying to use
NickA. For TimeStamp, the user was Killed. For Nickname
Delay, the user was not allowed to take the nick.
Depending on the situation:
(Nickname) Delay tries to protect everyone, while TimeStamp
tries to protect only the "rightful" users.
Note: A similar example can be made with channels.
In the example above, TimeStamp broadcasts more information
than Nickname Delay: nick change and the eventual nickname
collision on every server on one side of the split.
The net that we know has a long history, and many ``well
known rules''. As far as I can remember, it has always been
said that "nicknames and channels are not owned".
This state of things is easy to notice on a net where
collisions and takeovers are a common thing. With TimeStamp
or Delay, things change, and what was clear before is not
that clear anymore.
The problem is that TimeStamp decides who the rightful
user is and the logic used for this is far to be approved by
everyone (read below, long splits and TS for one
example). With the delay patches, no choice thus no mistake
is ever done, but sometimes, it will let a conflict happens.
It is now easy to understand that when TimeStamp makes the
'wrong' decision, the user who has been "punished" and who was
"right" will require or at least expect
someone/something to correct the situation. It is what leads
to the need for ``services''.
A channel service, as known on other IRC networks is
something that goes against the long established
"channels are not owned" and would be a big change
on the net. This is one of the main reasons why people are
opposed to TS, because, as stated above, it easily leads to
"Now that we have TS, we need a channel service".
Quoting Doug McLaren talking about nickname delay:
There's nothing to stop the `lag-killer bot'. This bot
keeps two connections open - one on your server, one on a
remote server. It also sits on a channel that you are on.
As soon as it sees you change nick with it's local
connection, it signals the remote connection to take the
same nick. The two nick changes meet somewhere in the
middle, and you get killed.
TimeStamping does not really solve this either. It limits
the abuse because the `lag-killer bot' has to be fast, but
this is not really a problem.
Roger Espel Llima says: neither solution deals with them
completely; TS leaves them with a success rate of about 50%;
with ND they're always successful
Vesa Ruokonen answers: Nickname Delay doesn't make abuse
always successful. With it, the kill can happen only
once (on a given nickname), after that the
nickname gets locked, and the bot cannot continue looping
like with TS.
Quoting Doug McLaren talking about nickname delay:
The same goes for a server that has just been /restarted
or started. That case is a little better, because, if the
server's C/N lines are set up right, it will start
connecting immediately, only giving the colliders a few
seconds to connect before it gets connected and processes
the connect burst.
I guess client connections could be delayed, in these
conditions. But I don't really see any easy way to do it,
nor to know that the server has processed the whole connect
burst.
Quoting Doug McLaren talking about nickname delay:
There's nothing to stop a server that has been split for
more than 15 minutes from being used to nick collide. If
one client on this server starts cycling through all the
nicks it wants to kill as soon as the server reconnects to
the net, it can be used to cause lots of nick collisions.
This is quite true. But as you will read below, servers
should not be split that long (at least not on a regular
basis). Of course, it happens.
Quoting Doug McLaren talking about channel delay:
If a server is split for more than fifteen minutes, all
channel delays will have expired, and they'll be able to
hack ops on any channel they want to, assuming nobody on
this server is already on this channel.
Network and machine outages often last more than 15 minutes
...
There are three things to answers to these two statements.
First, in its current version, channel delay does not expire
after fifteen minutes on a server which is ``completely''
split. In such case, it will take longer.
Second, I don't really know how you plan to abuse a server
which is unreachable. If there's a network outage, only
local users should be able to abuse, given that they won't
see the other part of the net, they will only be able to
act against known ``targets''.
Finally, if a server, or part of the net is used to have
long splits, my very personal opinion is that it should not
be linked at all.
According to me, TimeStamp also has problems with long
splits. I will take the example of TimeStamp on nicknames,
but a similar comment can be made for channels.
Let's assume two servers are split for a long time. Then,
two users can use the same nick for an important amount of
time, and only one will be killed on reconnect. I believe
that there is no way to choose the right one.
This can lead to have someone who usually uses a nickname to
be killed (if he restarted his client recently, or changed
nicknames at some point).
You should probably read this again, because there are many
important points which are rather hidden because of the
length. I tried to address all issues, they all have
different importance, but this is quite subjective.
The most important thing to know and remember, is that
either concept is only FULLY effective if the whole
IRC net is running it.
Thanks to the following people for reviewing this document,
and commenting it:
Christophe Kalt <kalt@stealth.net>
Both aspects are different and should not be
confused.
The TS concept
Nicknames
A TS server knows which of two nickname clients is the most
recent. Thus it is possible for it to decide to kill only
one of the clients.
This protects the older user from intentional
nickname collisions.
Channels
As for channels, a TS server is able to decide which
channel operator is the youngest (for each channel). This
makes the removal of channel operator status for users who
are riding splits possible.
Technical notes
The Delay concept
Nicknames
A server with nickname delay keeps users from using a
nickname recently used, if the nickname has either split
away or being killed.
Channels
A server with channel delay does not allow users to join
channels which have recently lost their channel op because
of split and which are empty. (e.g. joins are always allowed
if a channel is not empty).
Technical notes
A simple technical comparison
Delay uses memory for Nickname Delay (close to 400Kb for 25K
users). Channel Delay memory use is close to 0.
The political issues
The problems
Also, it makes the number of potential abusers really
limited.
Last note
I believe this document gives quite a complete overview of
both concepts. The purpose now is for you to think
and may be decide which one you prefer. But you should be at
least able to make up your mind, on your own (forgetting all
what you have heard so far).