TS - Delay comparsion »
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.
1. What is the purpose of these concepts?
2. Summary of the two concepts
+ TS
+ Delay
3. Technical comparison
4. Policital issues
5. The ``problems''
6. Last note
_________________________________________________________________
Why?
Both concepts (TS and Delay) attempt to solve two widely known
problems with IRC 2:
* nickname collisions
* channel op riding
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.
Delay
The delay concept is implemented in the version 2.9 of the official IRC server. This version is still a beta release. It has not been documented yet (as of 96/06/06).
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:
* a technical aspect
* a political aspect
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
* it associates a TimeStamp to entities (nicknames and channels)
which are used later to decide how to react when a conflict occurs
(collision, or op riding).
* it is only functional between directly linked TS servers.
* when a conflict occurs, a TS server relies on the server which
created the conflict to take exactly the same decision to solve
the conflict.
_________________________________________________________________
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 "nickname recently used" is defined by a nickname which has recently
(up to 15 minutes) split. * "recently lost channel op" is defined
by a channel op splitting recently (up to 15 minutes in normal conditions).
_________________________________________________________________
A simple technical comparison
- As a first note, neither of the two methods stops nickname
collisions, nor channel takeovers. But they both have a different
way to handle them:
+ TS will let users do whatever they want, and attempt to fix
later when a conflict occurs.
+ With the delay concept, users aren't allowed actions which
would possibly lead to a conflict later.
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:
+ With TimeStamp:
- UserA with NickA and UserB with NickB are on IRC on
different servers.
- There is a split inbetween the servers UserA and UserB
are on.
- UserB nicks to NickA.
- The servers reconnect.
- There is a nick collision and the Timestamp says UserA's
NickA is older so UserB's NickA is killed.
- UserA with NickA doesn't know the difference, but UserB
does (because he got killed in step 5).
- UserA with NickA and UserB with NickB are on IRC on
different servers.
- There is a split inbetween the servers UserA and UserB
are on.
- UserB tries to change to NickA, but cannot because of
Nickname Delay.
- The servers reconnect.
- nothing happens.
- UserA with NickA doesn't know the difference, but UserB
does (because he was not able to get NickA in step 3).
Both are 'transparent' to UserA, because he didn't know anything
odd happened.
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:
+ TimeStamp can be found more annoying than Nickname Delay: If
UserB is not trying to collide UserA, UserB will later get
disconnected (killed) which is rather annoying.
+ Nickname Delay can be found more annoying than TimeStamp: If
UserB is also UserA and switching from servers to get around
the split, the user cannot user NickA (his/her own nickname)
for a while.
(Nickname) Delay tries to protect everyone, while TimeStamp tries
to protect only the "rightful" users.
Note: A similar example can be made with channels.
- UserA with NickA and UserB with NickB are on IRC on
- One big difference between the two concepts is the way to handle problems.
TS will always rely on the net, while Delay will never. This means that TS can
cause havoc on the whole net (as seen on some occasions), while Delay will never
affect remote entities.
- TimeStamp can handle splits of an abritrary length, Delay for only 15 minutes.
- Delay does not broadcast any extra info, TimeStamp does (mostly stamps).
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.
- TimeStamp uses memory for stamps (100Kb for 25K users, 24Kb for 6K channels), Delay uses memory for Nickname Delay (close to 400Kb for 25K users). Channel Delay memory use is close to 0.
- TimeStamp requires a homogenous network to work effectively, Delay does,
but not as much.
The political issues
- The net has a spirit (also read an operlist post by M. D.
Yesowitch)
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''.
- Channel service 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".
The problems
- lag-killer bots 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.
- restarted servers 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.
- long splits + nickname delay 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.
- channel delay 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''. Also, it makes the number of potential abusers really limited. 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.
- TimeStamp 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).
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).
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:
* Vegard Engen
* Doug McLaren
* Roger Espel Llima
* Tom Hopkins
* Per Persson
* Vesa Ruokonen
* Alex Samonte
* M. D. Yesowitch
Christophe Kalt