2003-01-04 13:07:54 +00:00
|
|
|
|
|
|
|
ngIRCd - Next Generation IRC Server
|
|
|
|
|
|
|
|
(c)2001,2002 by Alexander Barton,
|
|
|
|
alex@barton.de, http://www.barton.de/
|
|
|
|
|
|
|
|
ngIRCd ist freie Software und steht unter
|
|
|
|
der GNU General Public License.
|
|
|
|
|
|
|
|
-- Protocol.txt --
|
|
|
|
|
|
|
|
|
|
|
|
I. Kompatibilitaet
|
|
|
|
~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
Der ngIRCd haelt sich an das IRC-Protokoll Version 2.10, wie es in den RFCs
|
|
|
|
1459 und 2810-2813 beschrieben ist. Diese (und ggf. weitere fuer den ngIRCd
|
|
|
|
relevante) RFCs sind in RFC.txt aufgefuehrt.
|
|
|
|
|
|
|
|
Leider verhaelt sich aber schon der "Originalserver" nicht immer genau so,
|
|
|
|
wie es in den RFCs beschrieben ist. Da der ngIRCd aber ein Ersatz fuer
|
|
|
|
eben diesen Server sein soll, werden diese Abweichungen in der Regel vom
|
|
|
|
ngIRCd emuliert um die Kompatibilitaet zu wahren.
|
|
|
|
|
|
|
|
Sollte dieses Verhalten nicht erwuenscht sein, so kann mit der configure-
|
|
|
|
Option "--enable-strict-rfc" der ngIRCd so compiliert werden, dass er sich
|
|
|
|
strikt an die entsprechenden RFCs haelt.
|
|
|
|
|
|
|
|
ACHTUNG: an einem so compilierten Server koennen sich andere Server und
|
|
|
|
Clients, die sich nicht genau an das Protokoll halten, u.U. nicht mehr
|
|
|
|
anmelden oder alle Funktionen nutzen! In der Regel ist diese Option daher
|
|
|
|
nicht erwuenscht.
|
|
|
|
|
|
|
|
|
|
|
|
II. Das IRC+-Protokoll
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
Der ngIRCd unterstuetzt als Erweiterung zum IRC-Protokoll wie es in den RFCs
|
|
|
|
2810-2813 beschrieben ist, das IRC+-Protokoll. Dieses Protokoll ist dabei
|
|
|
|
kompatibel zum IRC-Protokoll und wird nur verwendet, wenn der ngIRCd fest-
|
|
|
|
stellt, dass ein connectierter Server ebenfalls dieses erweiterte Protokoll
|
|
|
|
unterstuetzt.
|
|
|
|
|
|
|
|
Die Protokoll- und Server-Erkennung wird mit dem "PASS"-Befehl durchgefuehrt
|
|
|
|
(vgl. RFC 2813, Sektion 4.1.1):
|
|
|
|
|
|
|
|
|
|
|
|
II.1 neuen Server-Link registrieren
|
|
|
|
|
|
|
|
Befehl: PASS
|
|
|
|
Parameter: <password> <version> <flags> [<options>]
|
|
|
|
Fuer: mit dieser Syntax nur Server
|
|
|
|
|
|
|
|
<password> enthaelt das Passwort fur den neu aufzubauenden Server-Link,
|
|
|
|
so wie es in der Konfigurationsdatei definiert wurde.
|
|
|
|
|
|
|
|
<version> setzt sich aus zwei Teilen zusammen und ist mindestens 4, maximal
|
|
|
|
14 Zeichen lang: die ersten vier Bytes enthalten die Versionsnummer des
|
|
|
|
unterstuetzten IRC-Protokolls, wobei die ersten zwei Bytes die Major-, die
|
|
|
|
letzten beiden die Minor-Revision angeben. Der String "0210" steht also
|
|
|
|
fuer Protokollversion 2.10.
|
|
|
|
Die folgenden (optionalen!) 10 Bytes enthalten eine von der jeweiligen
|
|
|
|
Implementation abhaengige Versionsnummer. Server, die das IRC+-Protokoll
|
|
|
|
unterstuetzen, liefern hier "-IRC+".
|
|
|
|
|
|
|
|
<flags> setzt sich ebenfalls aus zwei Bestandteilen zusammen und ist
|
|
|
|
maximal 100 Bytes lang. Getrennt werden die beiden Teile mit dem Zeichen
|
|
|
|
"|". Der erste Teil enthaelt den Namen der Implementation, der ngIRCd
|
|
|
|
liefert hier z.B. "ngIRCd", der Originalserver "IRC". Anhand dieser "ID"
|
|
|
|
kann zwischen Serverimplementationen unterschieden werden. Der zweite Teil
|
|
|
|
(nach dem "|") ist implementationsabhaengig und wird nur ausgewertet,
|
|
|
|
wenn die Gegenseite das IRC+-Protokoll unterstuetzt. In diesem Fall wird
|
|
|
|
folgende Syntax erwartet: "<serverversion>[:<serverflags>]".
|
|
|
|
|
|
|
|
<serverversion> ist hier eine ASCII-Klartext-Darstellung der Versionsnummer,
|
|
|
|
<serverflags> zeigt die vom Server unterstuetzten Erweiterungen an (und
|
|
|
|
kann die leere Menge sein).
|
|
|
|
|
|
|
|
Mit dem optionalen Parameter <options> werden Server-Optionen uebermittelt,
|
|
|
|
wie sie in RFC 2813, Sektion 4.1.1 definiert sind.
|
|
|
|
|
|
|
|
Folgende <serverflags> sind zur Zeit definiert:
|
|
|
|
|
|
|
|
- o: IRC-Operatoren duerfen auch dann Channel- und Channel-User-Modes
|
|
|
|
aendern, wenn sie kein Channel-Operator im betroffenen Channel sind.
|
|
|
|
|
|
|
|
- C: der Server unterstuetzt den CHANINFO-Befehl.
|
|
|
|
|
|
|
|
|
|
|
|
II.2 Channel-Modes, persistente Channel und Topic austauschen
|
|
|
|
|
|
|
|
Befehl: CHANINFO
|
2003-01-15 13:45:59 +00:00
|
|
|
Parameter: <channel> +<modes> [[<key> <maxusers>] <topic>]
|
2003-01-04 13:07:54 +00:00
|
|
|
Fuer: Server
|
|
|
|
|
|
|
|
Mit CHANINFO Informiert ein Server den anderen ueber einen Channel: dessen
|
2003-01-15 13:45:59 +00:00
|
|
|
Modes, Channel-Key, User-Limit und dessen Topic. <topic> ist optional.
|
2003-01-04 13:07:54 +00:00
|
|
|
|
|
|
|
Existiert auf dem Server, der das CHANINFO empfaengt, der Channel bereits,
|
|
|
|
so uebernimmt er die Werte jeweils nur dann, wenn er selber noch keine
|
|
|
|
Modes bzw. kein Topic definiert hat. Ansonsten wird der jeweilige Parameter
|
|
|
|
ignoriert.
|
|
|
|
|
|
|
|
Existiert der Channel noch nicht, so wird er mit den entsprechenden Angaben
|
|
|
|
erzeugt.
|
|
|
|
|
2003-01-15 13:45:59 +00:00
|
|
|
Hat ein Channel keinen Key (in <modes> ist der Mode "k" nicht vorhanden),
|
|
|
|
so muss der Parameter <key> ignoriert werden (da <key> vorhanden sein muss,
|
|
|
|
sollte in diesem Fall "*" uebergeben werden). Hat er kein User-Limit (kein
|
|
|
|
"l" in <modes>), so muss <limit> ignoriert werden (<limit> sollte hierbei
|
|
|
|
als "0" uebergeben werden).
|
|
|
|
|
2003-01-04 13:07:54 +00:00
|
|
|
|
|
|
|
--
|
2003-01-15 13:45:59 +00:00
|
|
|
$Id: Protocol.txt,v 1.2 2003/01/15 13:45:59 alex Exp $
|