--- /dev/null
+/************************************************************************
+ * 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)
projects / ircu2.10.12-pk.git / blobdiff