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
20IRC 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
24point. Some additional changes and packaging has been made by
25Chelsea (chelsea@earth.cchem.berkeley.edu). This is personal
26view of the changes.
27
28CHANGES TO LAST THE OFFICIAL RELEASE (2.2PL1)
29
30   This release of irc2.4 is based to 2.2PL1 release (see the
31HISTORY chapter later in this document). Aside from fixing the
32bugs, this version is in many ways different from the 2.2PL1.
33The purpose of the most changes is to make it easier to run an
34IRC server. Normal users benefit from these changes indirectly
35by getting a better maintained server.
36
371. Changes visible to normal users
38
39   Even while mainly fixing bugs, some user visible changes have
40crept in too.
41
421.1 General note on wildcards
43
44   Many commands accept now wildcard matching where applicable. All
45compares 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
531.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
861.3 Changes to /whois command
87
88   As WHO, also /whois accepts wild cards as a parameters. WHOIS
89returns information for all users whose nickname matches the specified
90mask.
91
92   WHOIS automaticly calls WHOWAS [see below], if the attempted nickname
93is not found.
94
951.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
99this is that it remembers changes in last few minutes, there is no
100intention of this to be a long term history. That must be a separate
101project, although it could use the hooks provided by this service.
102
103   "WHOWAS nickname" queries this cache and returns about the same
104information that WHOIS would do, if the nickname is found. Wildcards
105are not accepted here, this is a specifically designed feature. If
106the name is not found, WHOWAS doesn't reply anything. This is because
107the most useful use of WHOWAS is implicitly through "WHOIS".
108
109   This history is also implicitly utilized by KILL command.
110
1111.5 New SERVER-SERVER/SERVER-CLIENT protocol message WALLOPS
112
113   The message ":source WALLOPS :Message" sends the message text
114to all operators that are currently online. Any user can use this
115command, it's not restricted. How this function is activated, depends
116on 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
123the general IRC message philosophy, where messages are sent only
124to links where they are needed (e.g. WALLOPS goes only to servers
125that have opers online--it's not broadcast to every server).
126
1271.6 General use of wildcarding in server queries
128
129   All commands that previously took a servername as a parameter,
130now accept also a wildcarded mask. The mask is replaced with
131the first matching servername. The following user level commands
132are 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"
143commands. Until all servers have upgraded, these commands may not
144reach the intended target and may return the information from some
145intermediate server.
146
1471.7 Marking user AWAY
148
149   v2.2PL1 version and earlier showed the AWAY-state (G) only for
150the local users of the same server. AWAY status could be queried
151only by sending a message to a user. This release (or since msa.4)
152broadcasts 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
156as AWAY, all pre-msa.4 servers that are reached will send back an
157acknowlegde message. Until all servers are upgraged, use of AWAY
158is somewhat inconvenient. If you get extra messages from AWAY,
159they also contain the server information. Use /admin command and
160send a *friendly* request for the admin to upgrage his/her server
161to a working version, namely 2.4 :)
162
1631.8 Servers don't restrict characters within messages
164
165   The parameter fields of the messages can now contain any characters
166in range 1-255, except '\r', '\n' and '\0'. The client programs should
167by default filter away the "dangerous" control characters, but intelligent
168clients can utilize this change and allow exchanges with foreign
1698-bit (or wider) charactersets. (The actual command parts must still be
170represented with the ordinary 7-bit characters.)
171
1722. Changes visible to the server administrator
173
1742.1 Identifying servers
175
176   Servers/clients have now always two names (it was this way in
177PL1, 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
198shown. The general format of the displayed name is
199
200	AnnouncedName[SocketHostName]
201
202When a connection is yet unkown, there is no AnnouncedName, and if the
203AnnouncedName is the same as SocketHostName, the "[..]"-part is omitted.
204
2052.2 Many notices to local operators
206
207   If an oper is signed on the server, he/she will receive many
208notices about exceptional conditions and servers actions. When
209something 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
2482.3 Links statistics collecting
249
250   IRCD now counts the bytes and messages transmitted to each open
251link. 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
256Link           SendQ  SendM SendBytes  RcveM RcveBytes Open since
257oddjob.uchicago    0    203      8067    772     34321 Sun May  6 02:15:45 1990
258cs.hut.fi[sauna    0   1916     79798     94      3082 Sun May  6 01:51:25 1990
259otax.tky.hut.fi    0   3722    151511    426     22690 Sun May  6 00:25:54 1990
260nada.kth.se        0   8775    355811   5333    223853 Sat May  5 14:11:49 1990
261vehka.cs.uta.fi    0  23816    882000    901     41156 Fri May  4 22:50:23 1990
262lut.fi             0  25145    943765   1068     35020 Fri May  4 22:34:16 1990
263kreeta.helsinki    0  24286    899191    957     47085 Fri May  4 22:33:28 1990
264naakka.tut.fi      0  27754   1067302   8288    362960 Fri May  4 22:33:14 1990
265joyx.joensuu.fi    0  30003   1172949   2300     80053 Fri May  4 22:33:05 1990
266tel4.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
276cumulative counts for all connections since the server was started.
277
278   One can query the statistics of a remote server by adding the servers
279name to the command "/stat l servername". Of course, this only works,
280if all intermediate servers have upgraged. The first "old" server
281will stop the propagation and return the message counts by default.
282
2832.4 Connecting servers
284
285   An oper can manually activate a connection phase to any server
286defined in ircd.conf C-lines (to successfully complete the connection,
287the 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
292name is matched against entries in ircd.conf (notice: the testing
293is made in reverse order, e.g. the last C-line in ircd.conf is tested
294first).  If portnumber is omitted, the ircd uses the one given in the
295found C-line. If the C-line does not have the portnumber, the compiled
296default will be used (PORTNUM from config.h).
297
298   This release allows also for remote connecting. An oper can send
299a connect request to remote server with
300
301	CONNECT servername portnumber remoteserver
302
303This command is passed to the 'remoteserver' and it then tries to
304execute it like it was given locally. (If there are opers online on
305that server, they will get a notice about this happening.) Note, that
306one can remotely connect only what is defined in ircd.conf. Usually
307one needs and should use this only for immediate your neighbours. Nobody
308should randomly go and give connect requests to distant servers, unless
309one knows it's absolutely necessary and is very familiar about the
310linking setup there.
311
3122.4 Terminating connections
313
314   The SQUIT command in PL1 was not intended to be used manually and
315was very dangerous to use (it also created so called "ghost servers").
316Since 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
357give sufficient identification. SQUIT of wrong server is not nice...
358
3592.5 KILL message
360
361    KILL will implicitly use the history database. If a KILL is
362issued for a nick that has been changed to another, the server
363will automaticly re-issue the kill with the new nickname, if
364the change has happened recently (current value should be 90
365seconds). If a "terrorist" is clearly distrupting channel by
366bombarding it with garbage from negative channels and changing
367nick all time, there is no need to consult the "WHOWAS" data
368base, just use the nickname that was used to send the garbage
369and ircd hunts the culprit down. When this change of target
370happens, the oper issuing the kill is notified.
371
372NOTE:	With automatic, kill-proof-reconnecting clients, the
373	value of KILL is becoming insignificant...
374
3752.6 Changing the server defaults from the command line
376
377    The servers activation command is now
378
379ircd[ -f configfile][ -h servername][ -p portnumber][ -x debuglevel]
380
381where parameters can be given in any order. If the "configfile"
382is defined, it will override the default specified in the file
383"config.h". If "servername" is defined, it will override the
384one defined in the M-line on the configuration line. "portnumber"
385will override the compiled default (from "config.h") or the
386one from the M-line of the configuration file. The "debuglevel"
387will determine the amout of logging the server does into a
388log file that has been define in "config.h". The "debuglevel"
389should never be defined for a server running normally, it can
390quickly generate megabytes of trace. Usually needed only when
391the server is incapable of starting properly at all, then one
392run with "-x9" usually is enough to reveal the problem.
393
3943. General cleaning up and commenting the code
395
396   This issue is controversial. My way of fixing bugs is not just
397fix them, I also want to program defensively, make it difficult to
398make new errors. Thus I have heavily reformatted and reorganized
399those files that I have had to touch. Some functions have been
400renamed intentionally to catch all uses of those functions [because
401the functions semantics or calling sequences have been changed].
402
403   This release (2.4) will be the last IRC version I'm contributing
404to. If you have any wishes or complains about the code or functioining
405of IRC, use the source or ask whomever it happens to be the current
406developer.
407
408HISTORY
409
410   There have been many different versions of IRC and many of those
411versions are still in use. The following attempt to bring some
412clarification to the versions. This starts from 2.01.6, hopefully
413no 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)
479