ViewVC Help
View File | Revision Log | Show Annotations | View Changeset | Root Listing
root/svn/ircd-hybrid/doc/technical/ts3.txt
Revision: 31
Committed: Sun Oct 2 20:34:05 2005 UTC (18 years, 5 months ago) by knight
Content type: text/plain
File size: 15643 byte(s)
Log Message:
- Fix svn:keywords

File Contents

# Content
1 $Id$
2 Protocol changes for +TSora
3 ---------------------------
4
5 Note:
6
7 The protocols described here implement TimeStamps on IRC channels and
8 nicks. The idea of IRC TimeStamps was started on Undernet, and first
9 implemented by Run <carlo@runaway.xs4all.nl>. The protocols used here
10 are not exactly the same as the ones used on Undernet; the nick-kill
11 handling is very similar and must be credited to Run, while the
12 "TimeStamped channel description" protocol is quite different.
13
14 TSora servers keep track of which version of the TS protocol (if any)
15 their neighboring servers are using, and take it into account when
16 sending messages to them. This allows for seamless integration of TS
17 servers into a non-TS net, and for upgrades of the protocol.
18
19 Each server knows which is the lowest and the highest version of the
20 TS protocol it can interact with; currently both of these are set to 1:
21
22 #define TS_CURRENT 1 /* the highest TS ver we can do */
23 #define TS_MIN 1 /* the lowest TS ver we can do */
24
25 Timings and TS versions:
26 ========================
27
28 . Keep a 'delta' value to be added to the result of all calls to time(),
29 initially 0.
30
31 . Send a second argument to the PASS command, ending in the 'TS' string.
32
33 . Send a
34
35 SVINFO <TS_CURRENT> <TS_MIN> <STANDALONE> :<UTC-TIME>
36
37 just after "SERVER", where <STANDALONE> is 1 if we're connected to
38 more TSora servers, and 0 if not, and <UTC-TIME> is our idea of the
39 current UTC time, fixed with the delta.
40
41 . When we receive a "SVINFO <x> <y> <z> :<t>" line from a connecting
42 server, we ignore it if TS_CURRENT<y or x<TS_MIN, otherwise we
43 set a flag remembering that that server is TS-aware, remember the TS
44 version to use with it (min(TS_CURRENT, x)). Additionally, if this is
45 our first connected TS server, we set our delta to t-<OUR_UTC> if
46 z==0, and to (t-<OUR_UTC>)/2 if z!=0. The SVINFO data is kept around
47 until the server has effectively registered with SERVER, and used
48 *after* sending our own SVINFO to that server.
49
50 Explanations:
51
52 Servers will always know which of their directly-linked servers can do
53 TS, and will use the TS protocol only with servers that do understand
54 it. This makes it possible to switch to full TS in just one
55 code-replacement step, without incompatibilities.
56
57 As long as not all servers are TS-aware, the net will be divided into
58 "zones" of linked TS-aware servers. Channel modes will be kept
59 synchronized at least within the zone in which the channel was
60 created, and nick collisions between servers in the same zone will
61 result in only one client being killed.
62
63 Time synchronization ensures that servers have the same idea of the
64 current time, and achieves this purpose as long as TS servers are
65 introduced one by one within the same 'zone'. The merging of two zones
66 cannot synchronize them completely, but it is to be expected that
67 within each zone the effective time will be very close to the real
68 time.
69
70 By sending TSINFO after SERVER rather than before, we avoid the extra
71 lag created by the identd check on the server. To be able to send
72 immediately a connect burst of either type (TS or not), we need to
73 know before that if the server does TS or not, so we send that
74 information with PASS as an extra argument. And to avoid being
75 incompatible with 2.9 servers, which check that this second argument
76 begins with "2.9", we check that it *ends* with "TS".
77
78 The current time is only used when setting a TS on a new channel or
79 nick, and once such a TS is set, it is never modified because of
80 synchronization, as it is much more important that the TS for a
81 channel or nick stays the same across all servers than that it is
82 accurate to the second.
83
84 Note that Undernet's 2.8.x servers have no time synchronization at
85 all, and have had no problems because of it - all of this is more to
86 catch the occasional server with a way-off clock than anything.
87
88 NICK handling patches (anti-nick-collide + shorter connect burst):
89 ==================================================================
90
91 . For each nick, store a TS value = the TS value received if any, or our
92 UTC+delta at the time we first heard of the nick. TS's are propagated
93 to TS-aware servers whenever sending a NICK command.
94
95 . Nick changes reset the TS to the current time.
96
97 . When sending a connect burst to another TS server, replace the
98 NICK/USER pair with only one NICK command containing the nick, the
99 hopcount, the TS, the umode, and all the USER information.
100
101 The format for a full NICK line is:
102 NICK <nick> <hops> <TS> <umode> <user> <host> <server> :<ircname>
103
104 The umode is a + followed by any applying usermodes.
105
106 The format for a nick-change NICK line is:
107 :<oldnick> NICK <newnick> :<TS>
108
109 . When a NICK is received from a TS server, that conflicts with an
110 existing nick:
111 + if the userhosts differ or one is not known:
112 * if the timestamps are equal, kill ours and the old one if it
113 was a nick change
114 * if the incoming timestamp is older than ours, kill ours and
115 propagate the new one
116 * if the incoming timestamp is younger, ignore the line, but kill
117 the old nick if it was a nick change
118 + if the userhosts are the same:
119 * if the timestamps are equal, kill ours and the old one if it
120 was a nick change
121 * if the incoming timestamp is younger, kill ours and propagate
122 the new one
123 * if the incoming timestamp is older, ignore the line but kill
124 the old nick if it was a nick change
125
126 . When a NICK is received from a non-TS server that conflicts with
127 an existing nick, kill both.
128
129 . Do not send "Fake Prefix" kills in response to lines coming from TS
130 servers; the sanitization works anyway, and this allows the "newer
131 nick overruled" case to work.
132
133 Explanations:
134
135 The modified nick-introduction syntax allows for a slightly shorter
136 connect-burst, and most importantly lets the server compare
137 user@host's when determining which nick to kill: if the user@host
138 is the same, then the older nick must be killed rather than the
139 newer.
140
141 When talking to a non-TS server, we need to behave exactly like one
142 because it expects us to. When talkign to a TS server, we don't kill
143 the nicks it's introducing, as we know it'll be smart enough to do it
144 itself when seeing our own introduced nick.
145
146 When we see a nick arriving from a non-TS server, it won't have a TS,
147 but it's safe enough to give it the current time rather than keeping
148 it 0; such TS's won't be the same all across the network (as long as
149 there is more than one TS zone), and when there's a collision, the TS
150 used will be the one in the zone the collision occurs in.
151
152 Also, it is important to note that by the time a server sees (and
153 chooses to ignore) a nick introduction, the introducing server has
154 also had the time to put umode changes for that nick on its queue, so
155 we must ignore them too... so we need to ignore fake-prefix lines
156 rather than sending kills for them. This is safe enough, as the rest
157 of the protocol ensures that they'll get killed anyway (and the
158 Undernet does it too, so it's been more than enough tested). Just for
159 an extra bit of compatibility, we still kill fake prefixes coming from
160 non-TS servers.
161
162 This part of the TS protocol is almost exactly the same as the
163 Undernet's .anc (anti-nick-collide) patches, except that Undernet
164 servers don't add usermodes to the NICK line.
165
166 TimeStamped channel descriptions (avoiding hacked ops and desynchs):
167 ====================================================================
168
169 . For each channel, keep a timestamp, set to the current time when the
170 channel is created by a client on the local server, or to the received
171 value if the channel has been propagated from a TS server, or to 0
172 otherwise. This value will have the semantics of "the time of creation
173 of the current ops on the channel", and 0 will mean that the channel
174 is in non-TS mode.
175
176 A new server protocol command is introduced, SJOIN, which introduces
177 a full channel description: a timestamp, all the modes (except bans),
178 and the list of channel members with their ops and voices. This
179 command will be used instead of JOIN and of (most) MODEs both in
180 connect bursts and when propagating channel creations among TS
181 servers. SJOIN will never be accepted from or sent to users.
182
183 The syntax for the command is:
184
185 SJOIN <TS> #<channel> <modes> :[@][+]<nick_1> ... [@][+]<nick_n>
186
187 The fields have the following meanings:
188
189 * <TS> is the timestamp for the channel
190
191 * <modes> is the list of global channel modes, starting with a +
192 and a letter for each of the active modes (spmntkil), followed
193 by an argument for +l if there is a limit, and an argument for
194 +k if there's a key (in the same order they were mentioned in
195 the string of letters).
196
197 A channel with no modes will have a "+" in that field.
198
199 A special value of "0" means that the server does not specify the
200 modes, and will be used when more than one SJOIN line is needed
201 to completely describe a channel, or when propagating a SJOIN
202 the modes of which were rejected.
203
204 * Each nick is preceded by a "@" if the user has ops, and a "+" if
205 the user has a voice. For mode +ov, both flags are used.
206
207 SJOINs will be propagated (when appropriate) to neighboring TS
208 servers, and converted to JOINs and MODEs for neighboring non-TS
209 servers.
210
211 To propagate channels for which not all users fit in one
212 SJOIN line, several SJOINs will be sent consecutively, only the first
213 one including actual information in the <mode> field.
214
215 An extra ad-hoc restriction is imposed on SJOIN messages, to simplify
216 processing: if a channel has ops, then the first <nick> of the first
217 SJOIN sent to propagate that channel must be one of the ops.
218
219 Servers will never attempt to reconstruct a SJOIN from JOIN/MODE
220 information being received at the moment from other servers.
221
222 . For each user on a channel, keep an extra flag (like ops and voice)
223 that is set when the user has received channel ops from another
224 server (in a SJOIN channel description), which we rejected (ignored).
225 Mode changes (but NOT kicks) coming from a TS server and from someone
226 with this flag set will be ignored. The flag will be reset when the
227 user gets ops from another user or server.
228
229 . On deops done by non-local users, coming from TS servers, on channels
230 with a non-zero TS, do not check that the user has ops but check that
231 their 'deopped' flag is not set. For kicks coming from a TS server, do
232 not check either. This will avoid desynchs, and 'bad' modechanges are
233 avoided anyway. Other mode changes will still only be taken into
234 account and propagated when done by users that are seen as having ops.
235
236 . When a MODE change that ops someone is received from a server for a
237 channel, that channel's TS is set to 0, and the mode change is
238 propagated.
239
240 . When a SJOIN is received for a channel, deal with it in this way:
241 * received-TS = 0:
242 + if we have ops or the SJOIN doesn't op anyone, SJOIN propagated
243 with our own TS.
244 + otherwise, TS set to 0 and SJOIN propagated with 0.
245 * received-TS > 0, own-TS = 0:
246 + if the SJOIN ops someone or we don't have ops, set our TS to the
247 received TS and propagate.
248 + otherwise, propagate with TS = 0.
249 * received-TS = own-TS: propagate.
250 * received-TS < own-TS:
251 + if the SJOIN ops someone, remove *all* modes (except bans) from
252 the channel and propagate these mode changes to all neighboring
253 non-TS servers, and copy the received TS and propagate the SJOIN.
254 + if the SJOIN does not op anyone and we have ops, propagate
255 with our own TS.
256 + otherwise, copy the received TS and propagate the SJOIN.
257 * received-TS > own-TS:
258 + if the SJOIN does not introduce any ops, process and propagate
259 with our own TS.
260 + if we have ops: for each person the mode change would op, set the
261 'deopped' flag; process all the JOINs ignoring the '@' and '+'
262 flags; propagate without the flags and with our TS.
263 + if we don't have ops: set our TS to the received one, propagate
264 with the flags.
265
266 Explanations:
267
268 This part of the protocol is the one that is most different (and
269 incompatible) with the Undernet's: we never timestamp MODE changes,
270 but instead we introduce the concept of time-stamped channel
271 descriptions. This way each server can determine, based on its state
272 and the received description, what the correct modes for a channel
273 are, and deop its own users if necessary. With this protocol, there is
274 *never* the need to reverse and bounce back a mode change. This is
275 both faster and more bandwith-effective.
276
277 The end goal is to have a protocol will eventually protect channels
278 against hacked ops, while minimizing the impact on a mixed-server net.
279 In order to do this, whenever there is a conflict between a TS server
280 and a non-TS one, the non-TS one's idea of the whole situation
281 prevails. This means that channels will only have a TS when they have
282 been created on a TS-aware server, and will lose it whenever a server
283 op comes from a non-TS server. Also, at most one 'zone' will have a TS
284 for any given channel at any given time, ensuring that there won't be
285 any deops when zones are merged. However, when TS zones are merged, if
286 the side that has a TS also has ops, then the TS is kept across the
287 whole new zone. Effective protection will only be ensured once all
288 servers run TS patches and channels have been re-created, as there is
289 no way servers can assign a TS to a channel they are not creating
290 (like they do with nicks) without having unwanted deops later.
291
292 The visible effects of this timestamped channel-description protocol
293 are that when a split rejoins, and one side has hacked ops, the other
294 side doesn't see any server mode changes (just like with Undernet's
295 TS), but the side that has hacked ops sees:
296
297 * first the first server on the other side deopping and devoicing
298 everyone, and fixing the +spmntkli modes
299 * then other users joining, and getting server ops and voices
300
301 The less obvious part of this protocol is its behavior in the case
302 that the younger side of a rejoin has servers that are lagged with
303 each other. In such a situation, a SJOIN that clears all modes and
304 sets the legitimate ones is being propagated from one server, and
305 lagged illegitimate mode changes and kicks are being propagated in the
306 opposite direction. In this case, a kick done by someone who is being
307 deopped by the SJOIN must be taken into account to keep the name list
308 in sync (and since it can only be kicking someone who also was on the
309 younger side), while a deop does not matter (and will be ignored by
310 the first server on the other side), and an opping *needs* to be
311 discareded to avoid hacked ops.
312
313 The main property of timestamped channel descriptions that makes them
314 a very stable protocol even with lag and splits, is that they leave a
315 server in the same final state, independently of the order in which
316 channel descriptions coming from different servers are received. Even
317 when SJOINs and MODEs for the same channel are being propagated in
318 different direction because of several splits rejoining, the final
319 state will be the same, independently of the exact order in which each
320 server received the SJOINs, and will be the same across all the
321 servers in the same zone.

Properties

Name Value
svn:eol-style native
svn:keywords "Id Revision"