]>
Commit | Line | Data |
---|---|---|
189935b1 | 1 | /************************************************************************ |
2 | * IRC - Internet Relay Chat, 2.4.notes | |
3 | * Copyright (C) 1990 Markku Savela | |
4 | * | |
5 | * This program is free software; you can redistribute it and/or modify | |
6 | * it under the terms of the GNU General Public License as published by | |
7 | * the Free Software Foundation; either version 1, or (at your option) | |
8 | * any later version. | |
9 | * | |
10 | * This program is distributed in the hope that it will be useful, | |
11 | * but WITHOUT ANY WARRANTY; without even the implied warranty of | |
12 | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
13 | * GNU General Public License for more details. | |
14 | * | |
15 | * You should have received a copy of the GNU General Public License | |
16 | * along with this program; if not, write to the Free Software | |
17 | * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | |
18 | */ | |
19 | ||
20 | IRC 2.4 release notes 6 May 1990/msa (Markku.Savela@vtt.fi) | |
21 | ============================================================ | |
22 | ||
23 | This document explains the changes I have done up to this | |
24 | point. Some additional changes and packaging has been made by | |
25 | Chelsea (chelsea@earth.cchem.berkeley.edu). This is personal | |
26 | view of the changes. | |
27 | ||
28 | CHANGES TO LAST THE OFFICIAL RELEASE (2.2PL1) | |
29 | ||
30 | This release of irc2.4 is based to 2.2PL1 release (see the | |
31 | HISTORY chapter later in this document). Aside from fixing the | |
32 | bugs, this version is in many ways different from the 2.2PL1. | |
33 | The purpose of the most changes is to make it easier to run an | |
34 | IRC server. Normal users benefit from these changes indirectly | |
35 | by getting a better maintained server. | |
36 | ||
37 | 1. Changes visible to normal users | |
38 | ||
39 | Even while mainly fixing bugs, some user visible changes have | |
40 | crept in too. | |
41 | ||
42 | 1.1 General note on wildcards | |
43 | ||
44 | Many commands accept now wildcard matching where applicable. All | |
45 | compares are case insensitive (e.g. "a" == "A"). The wild cards are | |
46 | ||
47 | ? matches any single character | |
48 | ||
49 | * matches any number of characters, also empty | |
50 | string. [PL1 had a bug, which caused "*du*" | |
51 | not match "....edu"]. | |
52 | ||
53 | 1.2 Server supported wildcards for "/who mask" command. | |
54 | ||
55 | Protocol message is "WHO mask", where mask can be | |
56 | ||
57 | empty | |
58 | 0 List all users [No change from PL1] | |
59 | ||
60 | * List all users on the same channel where the user is | |
61 | (or all, if user is on 0) [No change from PL1]. | |
62 | ||
63 | number List all users on the specified channel [No change | |
64 | from PL1]. Note, if the "mask" begings with a digit, | |
65 | this form is assumed, and the remainder of mask is | |
66 | ignored, e.g. "/who 12*.fi" gives all people from | |
67 | channel 12 and ignores the "*.fi" part. | |
68 | ||
69 | mask If the mask is any string, it will be compared | |
70 | *separately* to each information field of the user | |
71 | and if a match is found in any field, that user | |
72 | is included into the list. The fields searched | |
73 | are | |
74 | ||
75 | nickname | |
76 | loginname (account name) | |
77 | real name (text shown in parenthesis) | |
78 | hostname (users machine) | |
79 | servername (server he/she is using) | |
80 | ||
81 | Note: servername is not usually shown on WHO output, | |
82 | but is included in anyway. Example: finding all users | |
83 | somehow connected with Finnish sites, can be achieved | |
84 | with mask "*.fi". | |
85 | ||
86 | 1.3 Changes to /whois command | |
87 | ||
88 | As WHO, also /whois accepts wild cards as a parameters. WHOIS | |
89 | returns information for all users whose nickname matches the specified | |
90 | mask. | |
91 | ||
92 | WHOIS automaticly calls WHOWAS [see below], if the attempted nickname | |
93 | is not found. | |
94 | ||
95 | 1.4 Short term "WHOWAS" history | |
96 | ||
97 | The server has a short in memory cache of the recent nickname changes | |
98 | (the current default is set to 200 last changes). The design goal of | |
99 | this is that it remembers changes in last few minutes, there is no | |
100 | intention of this to be a long term history. That must be a separate | |
101 | project, although it could use the hooks provided by this service. | |
102 | ||
103 | "WHOWAS nickname" queries this cache and returns about the same | |
104 | information that WHOIS would do, if the nickname is found. Wildcards | |
105 | are not accepted here, this is a specifically designed feature. If | |
106 | the name is not found, WHOWAS doesn't reply anything. This is because | |
107 | the most useful use of WHOWAS is implicitly through "WHOIS". | |
108 | ||
109 | This history is also implicitly utilized by KILL command. | |
110 | ||
111 | 1.5 New SERVER-SERVER/SERVER-CLIENT protocol message WALLOPS | |
112 | ||
113 | The message ":source WALLOPS :Message" sends the message text | |
114 | to all operators that are currently online. Any user can use this | |
115 | command, it's not restricted. How this function is activated, depends | |
116 | on the client, but if nothing else works, "/quote wallops text" should. | |
117 | ||
118 | NOTE:This function will not be fully operational until *ALL* | |
119 | servers have upgraded to version 2.4. Also, operators | |
120 | must be using a client that recognizes this command. | |
121 | ||
122 | This is really a hasty addition. But, done this way it follows | |
123 | the general IRC message philosophy, where messages are sent only | |
124 | to links where they are needed (e.g. WALLOPS goes only to servers | |
125 | that have opers online--it's not broadcast to every server). | |
126 | ||
127 | 1.6 General use of wildcarding in server queries | |
128 | ||
129 | All commands that previously took a servername as a parameter, | |
130 | now accept also a wildcarded mask. The mask is replaced with | |
131 | the first matching servername. The following user level commands | |
132 | are affected | |
133 | ||
134 | /admin server -- administrative info | |
135 | /time server -- local time | |
136 | /version server -- the server version | |
137 | /motd server -- "the message of the day" | |
138 | /info server -- info (usually same on same server version) | |
139 | /stat f server -- statistics information | |
140 | /users server -- users logged on server machine | |
141 | ||
142 | Note: Remote capability is a new feature for "info" and "stat" | |
143 | commands. Until all servers have upgraded, these commands may not | |
144 | reach the intended target and may return the information from some | |
145 | intermediate server. | |
146 | ||
147 | 1.7 Marking user AWAY | |
148 | ||
149 | v2.2PL1 version and earlier showed the AWAY-state (G) only for | |
150 | the local users of the same server. AWAY status could be queried | |
151 | only by sending a message to a user. This release (or since msa.4) | |
152 | broadcasts the away status to every server and the commands /WHO and | |
153 | /WHOIS give this information reliably. | |
154 | ||
155 | A side effect of this change is: when a user marks himself/herself | |
156 | as AWAY, all pre-msa.4 servers that are reached will send back an | |
157 | acknowlegde message. Until all servers are upgraged, use of AWAY | |
158 | is somewhat inconvenient. If you get extra messages from AWAY, | |
159 | they also contain the server information. Use /admin command and | |
160 | send a *friendly* request for the admin to upgrage his/her server | |
161 | to a working version, namely 2.4 :) | |
162 | ||
163 | 1.8 Servers don't restrict characters within messages | |
164 | ||
165 | The parameter fields of the messages can now contain any characters | |
166 | in range 1-255, except '\r', '\n' and '\0'. The client programs should | |
167 | by default filter away the "dangerous" control characters, but intelligent | |
168 | clients can utilize this change and allow exchanges with foreign | |
169 | 8-bit (or wider) charactersets. (The actual command parts must still be | |
170 | represented with the ordinary 7-bit characters.) | |
171 | ||
172 | 2. Changes visible to the server administrator | |
173 | ||
174 | 2.1 Identifying servers | |
175 | ||
176 | Servers/clients have now always two names (it was this way in | |
177 | PL1, but I think this version makes the idea more clear): | |
178 | ||
179 | Announced Name: | |
180 | ||
181 | The official name of the server (the name you use in | |
182 | /time, /quote connect, etc) or users nickname. Servers | |
183 | name is usually the hostname, but can actually be almost | |
184 | any string of characters resembling hostname. This one | |
185 | is given in M-line of ircd.conf. | |
186 | ||
187 | Socket hostname: | |
188 | ||
189 | Socket hostname of the server or client. This is the hostname | |
190 | of the connecting server/client and this is resolved from the | |
191 | connection. If resolve cannot be done, ircd defaults to using | |
192 | numeric IP-address. *ALL* access checks are based on this | |
193 | name, especially noteworthy fact, if your resolver cannot find | |
194 | hostnames by IP-address, you must allow the access by IP-numbers | |
195 | in your ircd.conf. | |
196 | ||
197 | In many places, where servers name is shown, actually both are | |
198 | shown. The general format of the displayed name is | |
199 | ||
200 | AnnouncedName[SocketHostName] | |
201 | ||
202 | When a connection is yet unkown, there is no AnnouncedName, and if the | |
203 | AnnouncedName is the same as SocketHostName, the "[..]"-part is omitted. | |
204 | ||
205 | 2.2 Many notices to local operators | |
206 | ||
207 | If an oper is signed on the server, he/she will receive many | |
208 | notices about exceptional conditions and servers actions. When | |
209 | something goes wrong, it should be much easier to fix the problems. | |
210 | ||
211 | Few often occurring, inportant error messages are | |
212 | ||
213 | "Write error to SERVERNAME, closing link" | |
214 | ||
215 | write() to socket returned with an error. Server is | |
216 | closing the link. This means usually network problems | |
217 | which you can do nothing about. | |
218 | ||
219 | "Max buffering limit exceeded for SERVERNAME" | |
220 | ||
221 | This is the situation where old server would have been | |
222 | "frozen". The socket buffers in your OS have been filled and | |
223 | even servers own predefined internal buffering MAX for a link | |
224 | has been exceeded. Exceeding this limit most likely means | |
225 | that the link is really dead, so the server closes the link | |
226 | and scratches all queued output for it. If the limit is | |
227 | set high ( > 20000 bytes), you won't usually see this, but | |
228 | just "No responce from SERVERNAME, closing link" as the | |
229 | server does not reply to PING as it should. | |
230 | ||
231 | "Link SERVERNAME cancelled, server SERVERNAME already exits" | |
232 | ||
233 | Two different servers from your net fragment attempted | |
234 | to connect same other net fragment about the same time | |
235 | and this collision is detected at your server. IRC routing | |
236 | does not allow loops, the link causing the loop is closed. | |
237 | (Which of the two links gets closed is mostly determined | |
238 | by pure chance and timing--you may lose a better link this | |
239 | way. Collisions should be rare in normal operation, if | |
240 | the timers in "config.h" are not messed up too much...) | |
241 | ||
242 | Of course, you get this too, if you try to connect to a | |
243 | server that is already connected by some other route. In | |
244 | that case your attempted connection is just safely cancelled. | |
245 | ||
246 | The notices attempt to be self explaining. | |
247 | ||
248 | 2.3 Links statistics collecting | |
249 | ||
250 | IRCD now counts the bytes and messages transmitted to each open | |
251 | link. This information can be output with a command "/stats l" | |
252 | ("/stats" or "/stat m" will give the old message count statistics). | |
253 | ||
254 | Sample output | |
255 | ||
256 | Link SendQ SendM SendBytes RcveM RcveBytes Open since | |
257 | oddjob.uchicago 0 203 8067 772 34321 Sun May 6 02:15:45 1990 | |
258 | cs.hut.fi[sauna 0 1916 79798 94 3082 Sun May 6 01:51:25 1990 | |
259 | otax.tky.hut.fi 0 3722 151511 426 22690 Sun May 6 00:25:54 1990 | |
260 | nada.kth.se 0 8775 355811 5333 223853 Sat May 5 14:11:49 1990 | |
261 | vehka.cs.uta.fi 0 23816 882000 901 41156 Fri May 4 22:50:23 1990 | |
262 | lut.fi 0 25145 943765 1068 35020 Fri May 4 22:34:16 1990 | |
263 | kreeta.helsinki 0 24286 899191 957 47085 Fri May 4 22:33:28 1990 | |
264 | naakka.tut.fi 0 27754 1067302 8288 362960 Fri May 4 22:33:14 1990 | |
265 | joyx.joensuu.fi 0 30003 1172949 2300 80053 Fri May 4 22:33:05 1990 | |
266 | tel4.tel.vtt.fi 04083771 167473890 863475 35022755 Mon Apr 23 00:15:17 1990 | |
267 | | | | | | | | |
268 | | | | | | Link established | |
269 | | | | | The number of bytes received | |
270 | | | | The number protocol messages received | |
271 | | | The number of bytes transmitted | |
272 | | The number of protocol messages transmitted | |
273 | The amount of queued data in bytes (if socket is hung) | |
274 | ||
275 | The last row (with the local servername) contains the total | |
276 | cumulative counts for all connections since the server was started. | |
277 | ||
278 | One can query the statistics of a remote server by adding the servers | |
279 | name to the command "/stat l servername". Of course, this only works, | |
280 | if all intermediate servers have upgraged. The first "old" server | |
281 | will stop the propagation and return the message counts by default. | |
282 | ||
283 | 2.4 Connecting servers | |
284 | ||
285 | An oper can manually activate a connection phase to any server | |
286 | defined in ircd.conf C-lines (to successfully complete the connection, | |
287 | the N-line must be present too). The message achieving this is | |
288 | ||
289 | CONNECT servername portnumber | |
290 | ||
291 | where servername may be a mask string containing wildcards. This | |
292 | name is matched against entries in ircd.conf (notice: the testing | |
293 | is made in reverse order, e.g. the last C-line in ircd.conf is tested | |
294 | first). If portnumber is omitted, the ircd uses the one given in the | |
295 | found C-line. If the C-line does not have the portnumber, the compiled | |
296 | default will be used (PORTNUM from config.h). | |
297 | ||
298 | This release allows also for remote connecting. An oper can send | |
299 | a connect request to remote server with | |
300 | ||
301 | CONNECT servername portnumber remoteserver | |
302 | ||
303 | This command is passed to the 'remoteserver' and it then tries to | |
304 | execute it like it was given locally. (If there are opers online on | |
305 | that server, they will get a notice about this happening.) Note, that | |
306 | one can remotely connect only what is defined in ircd.conf. Usually | |
307 | one needs and should use this only for immediate your neighbours. Nobody | |
308 | should randomly go and give connect requests to distant servers, unless | |
309 | one knows it's absolutely necessary and is very familiar about the | |
310 | linking setup there. | |
311 | ||
312 | 2.4 Terminating connections | |
313 | ||
314 | The SQUIT command in PL1 was not intended to be used manually and | |
315 | was very dangerous to use (it also created so called "ghost servers"). | |
316 | Since msa.4, the SQUIT has been safer to use manually. | |
317 | ||
318 | ||
319 | "SQUIT z" s a | |
320 | \ / | |
321 | \ / | |
322 | ------- x ------- y --| |-- z ------- b | |
323 | / ^ \ | |
324 | / | \ | |
325 | p c | |
326 | ||
327 | "SQUIT z" will break the link between "y" and "z" if injected | |
328 | into system from "s". After that the net will be in two fragmets, | |
329 | broken between "y" and "z". Server "z" never sees the actual | |
330 | SQUIT, all it observers is that the link to "y" suddenly closes | |
331 | (opers on z would see it as "Server y closed the connection" | |
332 | notice. Opers on y would see it as "Received remote SQUIT from | |
333 | x", note that the actual source "s" is not identified in the | |
334 | current version--for reasons too complicated to be explained | |
335 | here). | |
336 | ||
337 | *WARNING* *WARNING* If the server "y" is still running pre-msa.4 | |
338 | (like PL1), don't *EVER* issue a SQUIT for its links (unless the | |
339 | link is to a leaf node or verifiably a "ghost server"). | |
340 | ||
341 | Note, that when the link between "y" and "z" breaks, y will spit | |
342 | out SQUIT's for "z", "a", "b" and "c" to "x". At same time "z" | |
343 | is sending SQUIT's for "x", "s", "p", etc to "a", "b" and "c". | |
344 | SQUIT is normally generated by servers automaticly, it's just | |
345 | a later modification (msa.4) that allows an OPER to use this | |
346 | same message to "simulate" a link break at certain point. | |
347 | ||
348 | *IMPORTANT* If server "z" has configuration "C:y::y:6667", it | |
349 | automaticly attempts to reconnect after a short delay (currently | |
350 | 10 seconds), but only *if* the connection has been up long enough | |
351 | reliably (currently set to 10 minutes). If the thus formed link is | |
352 | squit another time, it will not attempt to come back immeatedly. | |
353 | This gives an oper time to reconfigure the links if that first | |
354 | short delay is not enough. | |
355 | ||
356 | As in all commands, also SQUIT accepts wildcards, but be careful to | |
357 | give sufficient identification. SQUIT of wrong server is not nice... | |
358 | ||
359 | 2.5 KILL message | |
360 | ||
361 | KILL will implicitly use the history database. If a KILL is | |
362 | issued for a nick that has been changed to another, the server | |
363 | will automaticly re-issue the kill with the new nickname, if | |
364 | the change has happened recently (current value should be 90 | |
365 | seconds). If a "terrorist" is clearly distrupting channel by | |
366 | bombarding it with garbage from negative channels and changing | |
367 | nick all time, there is no need to consult the "WHOWAS" data | |
368 | base, just use the nickname that was used to send the garbage | |
369 | and ircd hunts the culprit down. When this change of target | |
370 | happens, the oper issuing the kill is notified. | |
371 | ||
372 | NOTE: With automatic, kill-proof-reconnecting clients, the | |
373 | value of KILL is becoming insignificant... | |
374 | ||
375 | 2.6 Changing the server defaults from the command line | |
376 | ||
377 | The servers activation command is now | |
378 | ||
379 | ircd[ -f configfile][ -h servername][ -p portnumber][ -x debuglevel] | |
380 | ||
381 | where parameters can be given in any order. If the "configfile" | |
382 | is defined, it will override the default specified in the file | |
383 | "config.h". If "servername" is defined, it will override the | |
384 | one defined in the M-line on the configuration line. "portnumber" | |
385 | will override the compiled default (from "config.h") or the | |
386 | one from the M-line of the configuration file. The "debuglevel" | |
387 | will determine the amout of logging the server does into a | |
388 | log file that has been define in "config.h". The "debuglevel" | |
389 | should never be defined for a server running normally, it can | |
390 | quickly generate megabytes of trace. Usually needed only when | |
391 | the server is incapable of starting properly at all, then one | |
392 | run with "-x9" usually is enough to reveal the problem. | |
393 | ||
394 | 3. General cleaning up and commenting the code | |
395 | ||
396 | This issue is controversial. My way of fixing bugs is not just | |
397 | fix them, I also want to program defensively, make it difficult to | |
398 | make new errors. Thus I have heavily reformatted and reorganized | |
399 | those files that I have had to touch. Some functions have been | |
400 | renamed intentionally to catch all uses of those functions [because | |
401 | the functions semantics or calling sequences have been changed]. | |
402 | ||
403 | This release (2.4) will be the last IRC version I'm contributing | |
404 | to. If you have any wishes or complains about the code or functioining | |
405 | of IRC, use the source or ask whomever it happens to be the current | |
406 | developer. | |
407 | ||
408 | HISTORY | |
409 | ||
410 | There have been many different versions of IRC and many of those | |
411 | versions are still in use. The following attempt to bring some | |
412 | clarification to the versions. This starts from 2.01.6, hopefully | |
413 | no servers are running older versions... | |
414 | ||
415 | ... | |
416 | ... | |
417 | 2.01.6 A version from WiZ in summer 1989 | |
418 | ... | |
419 | 2.01t6 A series of releases, which contained minor | |
420 | 2.01T6 adjustements and bug fixes to the base version. | |
421 | 2.01u6 Some of those fixes caused extra errors, of | |
422 | 2.01U6 this series versions 2.01U6 and 2.01v6 are at | |
423 | 2.01v6 least known to be rather stable. | |
424 | ||
425 | 2.1.0 Mike Bolotski created these versions from the sources | |
426 | 2.1.1 of 2.01U6, but unfortunale some devious bug crept in | |
427 | and caused a lots of linking problems (the nasty "ghost | |
428 | server problem" splintered the net constantly). These | |
429 | versions must be deleted on sight :) [Autumn 1989] | |
430 | ||
431 | 2.2 This version is the 2.01v6 sources repackaged into | |
432 | multiple directories by Mike again. Probably nobody | |
433 | is running this base version, because is was promptly | |
434 | followed by two patch releases [Autumn 1989] | |
435 | ||
436 | 2.2PL0 These two are the last major "official" releases | |
437 | 2.2PL1 and most of the servers upgraged to either of | |
438 | these. | |
439 | ||
440 | 2.2msa Unfortunately 2.2PL1 version had a tendency to die | |
441 | mysteriously very often. So, I started to look into the | |
442 | code from March 1990 and that resulted a series of | |
443 | patches to the 2.2PL1 server code, but finally | |
444 | decided to release full server code releases of which | |
445 | few have got wider distribution | |
446 | ||
447 | 2.2msa.4 | |
448 | Has most of the known PL1 bugs fixed and seems | |
449 | to be very reliable. But once servers started | |
450 | staying up, a new problem appeared: socket | |
451 | buffers started getting full and servers tended | |
452 | to freeze very often for long intervals. | |
453 | ||
454 | 2.3alpha | |
455 | 2.3 Is an attempt to make an official release from 2.2msa.4 | |
456 | code, but hassles with changed copyrights make this | |
457 | version unacceptable. Besides, 2.3alpha or 2.2msa.4 are | |
458 | now obsolete, old versions :) | |
459 | ||
460 | 2.2msa.x | |
461 | To solve the freezing problems, the server code is changed | |
462 | to use non-blocking sockets. | |
463 | ||
464 | 2.2msa.7 | |
465 | 2.2msa.9 | |
466 | Are intermediate test versions, of which .9 seems | |
467 | to have most of the problems solved. | |
468 | ||
469 | 2.2msa.10 | |
470 | Never released. This is slightly improved version | |
471 | of msa.9, some new features. | |
472 | ||
473 | 2.4 Is a release which combines 2.2msa.10 and Chelsea's | |
474 | modifications to the server. Also, this release has | |
475 | once again reorganized the directories and makefiles. | |
476 | ||
477 | ||
478 | -- msa (Markku.Savela@vtt.fi) |