The Lag And Netsplit FAQ
This FAQ is aimed at answering questions that are asked about lag and netsplits as part of the Undernet User Committee's Document Project. If you have any queries or comments, please email email@example.com.
The first thing to look at is server structure. Consider a basic series of IRC servers:
A - B - C - D
This network is extremely basic. A large network such as the
Undernet would look like the diagram below.
G H I J K - L M N \| | / \ / | A - B - C - D - E - F \ / \ \ \ O P Q R S - T | / \ U V W
For the purposes of this explanation, however, we will remain with
the original four servers in the series to make things easier. By
looking at the diagram, we can see that for data to get anywhere,
there is only one route of travel. So if someone sends data from
server A to server D, it can only go from A to B, to C, and then on
to its destination at D. The point is that it has to travel and travel
takes time. If there is a bad connection between B and C, it would
slow the data down, and as a result, the whole journey would take longer.
Now, let's look at lag itself. Say you ping someone (/ctcp nickname
PING) and it returns with the following:
[SweetNes PING reply]: 37 secs....
We would assume that SweetNes is lagging by 37 seconds; that is, it
takes 37 seconds for data to reach SweetNes and return. Let's also
assume that on a day where lag is particularly bad, the time difference
between the servers may look like this:
A ------- B -------- C -------- D
9 sec 6 sec 10 sec
Since lag is only proportional, someone pinging someone on server D
from server A would get a ping reply of 50 seconds. This is the total
of all the time differences multiplied by 2. So it would take 50
seconds for data (the ping) sent to server D to reach its destination
and return, and someone pinging someone on server B from server D would
get a reply of 32 seconds. The point is that lag is proportional, and
therefore no one really lags, except to each other.
Let's look at this in an example:
A ------- B -------- C -------- D
1 2 3 4
If we have one person on each of our servers, and you, on server
A, ping them all, the ping replies would look like this:
[1 PING reply]: 0 seconds
Now, let's look at where the problems arise. We have two channel ops,
one on server A (op 1) and one on server D (op 2).
A ----- B ------ C ------ D
A user joins the channel from Server B. 9 seconds after the user joins,
channel op 1 on server A sees the user and ops him. Then 7 seconds later,
channel op 2 on server D sees the user join and ops him. So all the users on
server A think that channel op 1 opped the user, and all the users on server D
think that channel op 2 opped the user. The user himself would, of course,
think that channel op 1 opped him because that channel op is closer time-wise.
A -------- B ------- C ------- D before
A --- --- B ------- C ------- D after
>From the point of view of the people on servers B, C, and D, the people
on server A have left IRC, and vice versa for the people on server A.
A typical quit message during a netsplit will look something like this:
[18:40] *** Quits: WHIZZARD *netsplit
This illustrates that the 2 servers have split apart. But remember:
it's all relative. To the rest of the network, it looks as if everyone
on server A and server B have quit, and to those users on server A
and server B everyone else has quit.
Many of the "less intelligent" users try to look for netsplits
when they occur. They try to move to the side with the fewest people
and join a channel, which is empty on one side of the netsplit but very
busy on the other. This way they think they automatically gain ops.
When the servers do join after a split, the servers they connect to
will not necessarily be the ones they were connected to before the split.
Looking at the example again, they might now look like this:
B ---- C ---- D ---- A
Now all the tables are turned, because the people that were lagging to
you are not any longer and vice versa. That's the nature of lag:
sometimes it's bad, but usually you never have to worry about it.
It is not very wise, however, to start up DCCs with people you donít
know. Most people will reject them, since on some clients they are
hard to manage. When you send a file by DCC, it follows the same
method as the above to reduce server workload and make the whole
operation more efficient.
Copyright © 2002 Undernet User Committee