479 lines
20 KiB
Plaintext
479 lines
20 KiB
Plaintext
/************************************************************************
|
|
* IRC - Internet Relay Chat, 2.4.notes
|
|
* Copyright (C) 1990 Markku Savela
|
|
*
|
|
* This program is free software; you can redistribute it and/or modify
|
|
* it under the terms of the GNU General Public License as published by
|
|
* the Free Software Foundation; either version 1, or (at your option)
|
|
* any later version.
|
|
*
|
|
* This program is distributed in the hope that it will be useful,
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
* GNU General Public License for more details.
|
|
*
|
|
* You should have received a copy of the GNU General Public License
|
|
* along with this program; if not, write to the Free Software
|
|
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
*/
|
|
|
|
IRC 2.4 release notes 6 May 1990/msa (Markku.Savela@vtt.fi)
|
|
============================================================
|
|
|
|
This document explains the changes I have done up to this
|
|
point. Some additional changes and packaging has been made by
|
|
Chelsea (chelsea@earth.cchem.berkeley.edu). This is personal
|
|
view of the changes.
|
|
|
|
CHANGES TO LAST THE OFFICIAL RELEASE (2.2PL1)
|
|
|
|
This release of irc2.4 is based to 2.2PL1 release (see the
|
|
HISTORY chapter later in this document). Aside from fixing the
|
|
bugs, this version is in many ways different from the 2.2PL1.
|
|
The purpose of the most changes is to make it easier to run an
|
|
IRC server. Normal users benefit from these changes indirectly
|
|
by getting a better maintained server.
|
|
|
|
1. Changes visible to normal users
|
|
|
|
Even while mainly fixing bugs, some user visible changes have
|
|
crept in too.
|
|
|
|
1.1 General note on wildcards
|
|
|
|
Many commands accept now wildcard matching where applicable. All
|
|
compares are case insensitive (e.g. "a" == "A"). The wild cards are
|
|
|
|
? matches any single character
|
|
|
|
* matches any number of characters, also empty
|
|
string. [PL1 had a bug, which caused "*du*"
|
|
not match "....edu"].
|
|
|
|
1.2 Server supported wildcards for "/who mask" command.
|
|
|
|
Protocol message is "WHO mask", where mask can be
|
|
|
|
empty
|
|
0 List all users [No change from PL1]
|
|
|
|
* List all users on the same channel where the user is
|
|
(or all, if user is on 0) [No change from PL1].
|
|
|
|
number List all users on the specified channel [No change
|
|
from PL1]. Note, if the "mask" begings with a digit,
|
|
this form is assumed, and the remainder of mask is
|
|
ignored, e.g. "/who 12*.fi" gives all people from
|
|
channel 12 and ignores the "*.fi" part.
|
|
|
|
mask If the mask is any string, it will be compared
|
|
*separately* to each information field of the user
|
|
and if a match is found in any field, that user
|
|
is included into the list. The fields searched
|
|
are
|
|
|
|
nickname
|
|
loginname (account name)
|
|
real name (text shown in parenthesis)
|
|
hostname (users machine)
|
|
servername (server he/she is using)
|
|
|
|
Note: servername is not usually shown on WHO output,
|
|
but is included in anyway. Example: finding all users
|
|
somehow connected with Finnish sites, can be achieved
|
|
with mask "*.fi".
|
|
|
|
1.3 Changes to /whois command
|
|
|
|
As WHO, also /whois accepts wild cards as a parameters. WHOIS
|
|
returns information for all users whose nickname matches the specified
|
|
mask.
|
|
|
|
WHOIS automaticly calls WHOWAS [see below], if the attempted nickname
|
|
is not found.
|
|
|
|
1.4 Short term "WHOWAS" history
|
|
|
|
The server has a short in memory cache of the recent nickname changes
|
|
(the current default is set to 200 last changes). The design goal of
|
|
this is that it remembers changes in last few minutes, there is no
|
|
intention of this to be a long term history. That must be a separate
|
|
project, although it could use the hooks provided by this service.
|
|
|
|
"WHOWAS nickname" queries this cache and returns about the same
|
|
information that WHOIS would do, if the nickname is found. Wildcards
|
|
are not accepted here, this is a specifically designed feature. If
|
|
the name is not found, WHOWAS doesn't reply anything. This is because
|
|
the most useful use of WHOWAS is implicitly through "WHOIS".
|
|
|
|
This history is also implicitly utilized by KILL command.
|
|
|
|
1.5 New SERVER-SERVER/SERVER-CLIENT protocol message WALLOPS
|
|
|
|
The message ":source WALLOPS :Message" sends the message text
|
|
to all operators that are currently online. Any user can use this
|
|
command, it's not restricted. How this function is activated, depends
|
|
on the client, but if nothing else works, "/quote wallops text" should.
|
|
|
|
NOTE:This function will not be fully operational until *ALL*
|
|
servers have upgraded to version 2.4. Also, operators
|
|
must be using a client that recognizes this command.
|
|
|
|
This is really a hasty addition. But, done this way it follows
|
|
the general IRC message philosophy, where messages are sent only
|
|
to links where they are needed (e.g. WALLOPS goes only to servers
|
|
that have opers online--it's not broadcast to every server).
|
|
|
|
1.6 General use of wildcarding in server queries
|
|
|
|
All commands that previously took a servername as a parameter,
|
|
now accept also a wildcarded mask. The mask is replaced with
|
|
the first matching servername. The following user level commands
|
|
are affected
|
|
|
|
/admin server -- administrative info
|
|
/time server -- local time
|
|
/version server -- the server version
|
|
/motd server -- "the message of the day"
|
|
/info server -- info (usually same on same server version)
|
|
/stat f server -- statistics information
|
|
/users server -- users logged on server machine
|
|
|
|
Note: Remote capability is a new feature for "info" and "stat"
|
|
commands. Until all servers have upgraded, these commands may not
|
|
reach the intended target and may return the information from some
|
|
intermediate server.
|
|
|
|
1.7 Marking user AWAY
|
|
|
|
v2.2PL1 version and earlier showed the AWAY-state (G) only for
|
|
the local users of the same server. AWAY status could be queried
|
|
only by sending a message to a user. This release (or since msa.4)
|
|
broadcasts the away status to every server and the commands /WHO and
|
|
/WHOIS give this information reliably.
|
|
|
|
A side effect of this change is: when a user marks himself/herself
|
|
as AWAY, all pre-msa.4 servers that are reached will send back an
|
|
acknowlegde message. Until all servers are upgraged, use of AWAY
|
|
is somewhat inconvenient. If you get extra messages from AWAY,
|
|
they also contain the server information. Use /admin command and
|
|
send a *friendly* request for the admin to upgrage his/her server
|
|
to a working version, namely 2.4 :)
|
|
|
|
1.8 Servers don't restrict characters within messages
|
|
|
|
The parameter fields of the messages can now contain any characters
|
|
in range 1-255, except '\r', '\n' and '\0'. The client programs should
|
|
by default filter away the "dangerous" control characters, but intelligent
|
|
clients can utilize this change and allow exchanges with foreign
|
|
8-bit (or wider) charactersets. (The actual command parts must still be
|
|
represented with the ordinary 7-bit characters.)
|
|
|
|
2. Changes visible to the server administrator
|
|
|
|
2.1 Identifying servers
|
|
|
|
Servers/clients have now always two names (it was this way in
|
|
PL1, but I think this version makes the idea more clear):
|
|
|
|
Announced Name:
|
|
|
|
The official name of the server (the name you use in
|
|
/time, /quote connect, etc) or users nickname. Servers
|
|
name is usually the hostname, but can actually be almost
|
|
any string of characters resembling hostname. This one
|
|
is given in M-line of ircd.conf.
|
|
|
|
Socket hostname:
|
|
|
|
Socket hostname of the server or client. This is the hostname
|
|
of the connecting server/client and this is resolved from the
|
|
connection. If resolve cannot be done, ircd defaults to using
|
|
numeric IP-address. *ALL* access checks are based on this
|
|
name, especially noteworthy fact, if your resolver cannot find
|
|
hostnames by IP-address, you must allow the access by IP-numbers
|
|
in your ircd.conf.
|
|
|
|
In many places, where servers name is shown, actually both are
|
|
shown. The general format of the displayed name is
|
|
|
|
AnnouncedName[SocketHostName]
|
|
|
|
When a connection is yet unkown, there is no AnnouncedName, and if the
|
|
AnnouncedName is the same as SocketHostName, the "[..]"-part is omitted.
|
|
|
|
2.2 Many notices to local operators
|
|
|
|
If an oper is signed on the server, he/she will receive many
|
|
notices about exceptional conditions and servers actions. When
|
|
something goes wrong, it should be much easier to fix the problems.
|
|
|
|
Few often occurring, inportant error messages are
|
|
|
|
"Write error to SERVERNAME, closing link"
|
|
|
|
write() to socket returned with an error. Server is
|
|
closing the link. This means usually network problems
|
|
which you can do nothing about.
|
|
|
|
"Max buffering limit exceeded for SERVERNAME"
|
|
|
|
This is the situation where old server would have been
|
|
"frozen". The socket buffers in your OS have been filled and
|
|
even servers own predefined internal buffering MAX for a link
|
|
has been exceeded. Exceeding this limit most likely means
|
|
that the link is really dead, so the server closes the link
|
|
and scratches all queued output for it. If the limit is
|
|
set high ( > 20000 bytes), you won't usually see this, but
|
|
just "No responce from SERVERNAME, closing link" as the
|
|
server does not reply to PING as it should.
|
|
|
|
"Link SERVERNAME cancelled, server SERVERNAME already exits"
|
|
|
|
Two different servers from your net fragment attempted
|
|
to connect same other net fragment about the same time
|
|
and this collision is detected at your server. IRC routing
|
|
does not allow loops, the link causing the loop is closed.
|
|
(Which of the two links gets closed is mostly determined
|
|
by pure chance and timing--you may lose a better link this
|
|
way. Collisions should be rare in normal operation, if
|
|
the timers in "config.h" are not messed up too much...)
|
|
|
|
Of course, you get this too, if you try to connect to a
|
|
server that is already connected by some other route. In
|
|
that case your attempted connection is just safely cancelled.
|
|
|
|
The notices attempt to be self explaining.
|
|
|
|
2.3 Links statistics collecting
|
|
|
|
IRCD now counts the bytes and messages transmitted to each open
|
|
link. This information can be output with a command "/stats l"
|
|
("/stats" or "/stat m" will give the old message count statistics).
|
|
|
|
Sample output
|
|
|
|
Link SendQ SendM SendBytes RcveM RcveBytes Open since
|
|
oddjob.uchicago 0 203 8067 772 34321 Sun May 6 02:15:45 1990
|
|
cs.hut.fi[sauna 0 1916 79798 94 3082 Sun May 6 01:51:25 1990
|
|
otax.tky.hut.fi 0 3722 151511 426 22690 Sun May 6 00:25:54 1990
|
|
nada.kth.se 0 8775 355811 5333 223853 Sat May 5 14:11:49 1990
|
|
vehka.cs.uta.fi 0 23816 882000 901 41156 Fri May 4 22:50:23 1990
|
|
lut.fi 0 25145 943765 1068 35020 Fri May 4 22:34:16 1990
|
|
kreeta.helsinki 0 24286 899191 957 47085 Fri May 4 22:33:28 1990
|
|
naakka.tut.fi 0 27754 1067302 8288 362960 Fri May 4 22:33:14 1990
|
|
joyx.joensuu.fi 0 30003 1172949 2300 80053 Fri May 4 22:33:05 1990
|
|
tel4.tel.vtt.fi 04083771 167473890 863475 35022755 Mon Apr 23 00:15:17 1990
|
|
| | | | | |
|
|
| | | | | Link established
|
|
| | | | The number of bytes received
|
|
| | | The number protocol messages received
|
|
| | The number of bytes transmitted
|
|
| The number of protocol messages transmitted
|
|
The amount of queued data in bytes (if socket is hung)
|
|
|
|
The last row (with the local servername) contains the total
|
|
cumulative counts for all connections since the server was started.
|
|
|
|
One can query the statistics of a remote server by adding the servers
|
|
name to the command "/stat l servername". Of course, this only works,
|
|
if all intermediate servers have upgraged. The first "old" server
|
|
will stop the propagation and return the message counts by default.
|
|
|
|
2.4 Connecting servers
|
|
|
|
An oper can manually activate a connection phase to any server
|
|
defined in ircd.conf C-lines (to successfully complete the connection,
|
|
the N-line must be present too). The message achieving this is
|
|
|
|
CONNECT servername portnumber
|
|
|
|
where servername may be a mask string containing wildcards. This
|
|
name is matched against entries in ircd.conf (notice: the testing
|
|
is made in reverse order, e.g. the last C-line in ircd.conf is tested
|
|
first). If portnumber is omitted, the ircd uses the one given in the
|
|
found C-line. If the C-line does not have the portnumber, the compiled
|
|
default will be used (PORTNUM from config.h).
|
|
|
|
This release allows also for remote connecting. An oper can send
|
|
a connect request to remote server with
|
|
|
|
CONNECT servername portnumber remoteserver
|
|
|
|
This command is passed to the 'remoteserver' and it then tries to
|
|
execute it like it was given locally. (If there are opers online on
|
|
that server, they will get a notice about this happening.) Note, that
|
|
one can remotely connect only what is defined in ircd.conf. Usually
|
|
one needs and should use this only for immediate your neighbours. Nobody
|
|
should randomly go and give connect requests to distant servers, unless
|
|
one knows it's absolutely necessary and is very familiar about the
|
|
linking setup there.
|
|
|
|
2.4 Terminating connections
|
|
|
|
The SQUIT command in PL1 was not intended to be used manually and
|
|
was very dangerous to use (it also created so called "ghost servers").
|
|
Since msa.4, the SQUIT has been safer to use manually.
|
|
|
|
|
|
"SQUIT z" s a
|
|
\ /
|
|
\ /
|
|
------- x ------- y --| |-- z ------- b
|
|
/ ^ \
|
|
/ | \
|
|
p c
|
|
|
|
"SQUIT z" will break the link between "y" and "z" if injected
|
|
into system from "s". After that the net will be in two fragmets,
|
|
broken between "y" and "z". Server "z" never sees the actual
|
|
SQUIT, all it observers is that the link to "y" suddenly closes
|
|
(opers on z would see it as "Server y closed the connection"
|
|
notice. Opers on y would see it as "Received remote SQUIT from
|
|
x", note that the actual source "s" is not identified in the
|
|
current version--for reasons too complicated to be explained
|
|
here).
|
|
|
|
*WARNING* *WARNING* If the server "y" is still running pre-msa.4
|
|
(like PL1), don't *EVER* issue a SQUIT for its links (unless the
|
|
link is to a leaf node or verifiably a "ghost server").
|
|
|
|
Note, that when the link between "y" and "z" breaks, y will spit
|
|
out SQUIT's for "z", "a", "b" and "c" to "x". At same time "z"
|
|
is sending SQUIT's for "x", "s", "p", etc to "a", "b" and "c".
|
|
SQUIT is normally generated by servers automaticly, it's just
|
|
a later modification (msa.4) that allows an OPER to use this
|
|
same message to "simulate" a link break at certain point.
|
|
|
|
*IMPORTANT* If server "z" has configuration "C:y::y:6667", it
|
|
automaticly attempts to reconnect after a short delay (currently
|
|
10 seconds), but only *if* the connection has been up long enough
|
|
reliably (currently set to 10 minutes). If the thus formed link is
|
|
squit another time, it will not attempt to come back immeatedly.
|
|
This gives an oper time to reconfigure the links if that first
|
|
short delay is not enough.
|
|
|
|
As in all commands, also SQUIT accepts wildcards, but be careful to
|
|
give sufficient identification. SQUIT of wrong server is not nice...
|
|
|
|
2.5 KILL message
|
|
|
|
KILL will implicitly use the history database. If a KILL is
|
|
issued for a nick that has been changed to another, the server
|
|
will automaticly re-issue the kill with the new nickname, if
|
|
the change has happened recently (current value should be 90
|
|
seconds). If a "terrorist" is clearly distrupting channel by
|
|
bombarding it with garbage from negative channels and changing
|
|
nick all time, there is no need to consult the "WHOWAS" data
|
|
base, just use the nickname that was used to send the garbage
|
|
and ircd hunts the culprit down. When this change of target
|
|
happens, the oper issuing the kill is notified.
|
|
|
|
NOTE: With automatic, kill-proof-reconnecting clients, the
|
|
value of KILL is becoming insignificant...
|
|
|
|
2.6 Changing the server defaults from the command line
|
|
|
|
The servers activation command is now
|
|
|
|
ircd[ -f configfile][ -h servername][ -p portnumber][ -x debuglevel]
|
|
|
|
where parameters can be given in any order. If the "configfile"
|
|
is defined, it will override the default specified in the file
|
|
"config.h". If "servername" is defined, it will override the
|
|
one defined in the M-line on the configuration line. "portnumber"
|
|
will override the compiled default (from "config.h") or the
|
|
one from the M-line of the configuration file. The "debuglevel"
|
|
will determine the amout of logging the server does into a
|
|
log file that has been define in "config.h". The "debuglevel"
|
|
should never be defined for a server running normally, it can
|
|
quickly generate megabytes of trace. Usually needed only when
|
|
the server is incapable of starting properly at all, then one
|
|
run with "-x9" usually is enough to reveal the problem.
|
|
|
|
3. General cleaning up and commenting the code
|
|
|
|
This issue is controversial. My way of fixing bugs is not just
|
|
fix them, I also want to program defensively, make it difficult to
|
|
make new errors. Thus I have heavily reformatted and reorganized
|
|
those files that I have had to touch. Some functions have been
|
|
renamed intentionally to catch all uses of those functions [because
|
|
the functions semantics or calling sequences have been changed].
|
|
|
|
This release (2.4) will be the last IRC version I'm contributing
|
|
to. If you have any wishes or complains about the code or functioining
|
|
of IRC, use the source or ask whomever it happens to be the current
|
|
developer.
|
|
|
|
HISTORY
|
|
|
|
There have been many different versions of IRC and many of those
|
|
versions are still in use. The following attempt to bring some
|
|
clarification to the versions. This starts from 2.01.6, hopefully
|
|
no servers are running older versions...
|
|
|
|
...
|
|
...
|
|
2.01.6 A version from WiZ in summer 1989
|
|
...
|
|
2.01t6 A series of releases, which contained minor
|
|
2.01T6 adjustements and bug fixes to the base version.
|
|
2.01u6 Some of those fixes caused extra errors, of
|
|
2.01U6 this series versions 2.01U6 and 2.01v6 are at
|
|
2.01v6 least known to be rather stable.
|
|
|
|
2.1.0 Mike Bolotski created these versions from the sources
|
|
2.1.1 of 2.01U6, but unfortunale some devious bug crept in
|
|
and caused a lots of linking problems (the nasty "ghost
|
|
server problem" splintered the net constantly). These
|
|
versions must be deleted on sight :) [Autumn 1989]
|
|
|
|
2.2 This version is the 2.01v6 sources repackaged into
|
|
multiple directories by Mike again. Probably nobody
|
|
is running this base version, because is was promptly
|
|
followed by two patch releases [Autumn 1989]
|
|
|
|
2.2PL0 These two are the last major "official" releases
|
|
2.2PL1 and most of the servers upgraged to either of
|
|
these.
|
|
|
|
2.2msa Unfortunately 2.2PL1 version had a tendency to die
|
|
mysteriously very often. So, I started to look into the
|
|
code from March 1990 and that resulted a series of
|
|
patches to the 2.2PL1 server code, but finally
|
|
decided to release full server code releases of which
|
|
few have got wider distribution
|
|
|
|
2.2msa.4
|
|
Has most of the known PL1 bugs fixed and seems
|
|
to be very reliable. But once servers started
|
|
staying up, a new problem appeared: socket
|
|
buffers started getting full and servers tended
|
|
to freeze very often for long intervals.
|
|
|
|
2.3alpha
|
|
2.3 Is an attempt to make an official release from 2.2msa.4
|
|
code, but hassles with changed copyrights make this
|
|
version unacceptable. Besides, 2.3alpha or 2.2msa.4 are
|
|
now obsolete, old versions :)
|
|
|
|
2.2msa.x
|
|
To solve the freezing problems, the server code is changed
|
|
to use non-blocking sockets.
|
|
|
|
2.2msa.7
|
|
2.2msa.9
|
|
Are intermediate test versions, of which .9 seems
|
|
to have most of the problems solved.
|
|
|
|
2.2msa.10
|
|
Never released. This is slightly improved version
|
|
of msa.9, some new features.
|
|
|
|
2.4 Is a release which combines 2.2msa.10 and Chelsea's
|
|
modifications to the server. Also, this release has
|
|
once again reorganized the directories and makefiles.
|
|
|
|
|
|
-- msa (Markku.Savela@vtt.fi)
|