X-Git-Url: http://git.pk910.de/?a=blobdiff_plain;f=doc%2Fp10.html;h=fbbc4fe82fd1070295130e093343f2f76d847204;hb=refs%2Fheads%2Fupstream-ssl;hp=eafab9f8e6be05fb828263659a169adfa3b96e91;hpb=3fcdeb593e083a65b8d3d1a34edf65afd03d433b;p=ircu2.10.12-pk.git
diff --git a/doc/p10.html b/doc/p10.html
index eafab9f..fbbc4fe 100644
--- a/doc/p10.html
+++ b/doc/p10.html
@@ -12,7 +12,7 @@
(As of ircu 2.10.11)
Undernet Coder-com, coder-com@undernet.org
-$Id: p10.html,v 1.4 2000-04-11 05:51:25 gte Exp $
+$Id: p10.html,v 1.6 2002-02-14 00:20:40 ghostwolf Exp $
This document aims to be a practical
guide for implementing and maintaining the protocol, not just a reference
@@ -552,6 +552,12 @@ by reducing the length of common message identifiers.
CM |
+
+
+| ACCOUNT |
+
+AC |
+
[Back]
@@ -623,7 +629,13 @@ This token is formatted exactly the same as a client numeric is formatted.
The first 2 characters identify the server's numeric, whilst in this situation,
the final 3 characters define the maximum number of clients that this server
can hold (and more importantly, the maximum number of numerics it will
-generate).
+generate). This is always one less than a power of two, because the server
+uses this as a bitmask. A server can give out a higher numeric than this,
+however it will be "anded" with this number to find it's entry slot. The
+reason for this is so a server which is near the maximum number of clients
+can give out more numerics than it's using to prevent a new client getting a
+numeric that was used only seconds ago and maybe get messages destined to
+the old user.
The example "AA]]]" shows that this is a server with numeric 0, which
@@ -633,7 +645,8 @@ will generate client numerics up to 262,143.
This final parameter simply consists of a textual description of the server
prefixed by a colon. This is displayed in a clients WHOIS line, aswell
-as in the LINKS reply.
+as in the LINKS reply. By convention, if this is a leaf server it contains
+the servers IP in square brackets at the beginning of the string,
3.2 Network Database resyncronisation
After the connection has been established and verified, the next step
@@ -652,7 +665,8 @@ the originally recieved server message, with the only exception being that
the message is numeric prefixed, to indicate which server sent this message
(and also therefore, which hub this new server is linked too). There is
also a fixed "0" present before the Description field, this is a placeholder
-for future use and currently unused.
+for future use and currently unused. [Isomer: Question, what IS this
+reserved for?]
3.2.2 - NICK Messages
Client information is transmitted via "NICK" messages, of the
@@ -695,7 +709,8 @@ the "Host" part of the user@host mask.
[Optional]: User modes. If present, this is always +<user modes
-for this client>.
+for this client>. Note that the special +r usermode is followed by the
+client's account name; see the documentation for ACCOUNT.
The real IP address of this client, a Base64 encoded 32bit int.
@@ -1086,7 +1101,7 @@ succeed never the less.
4.1.4 - PART
4.1.5 - KICK
4.1.6 - TOPIC
-
4.1.4 - CLEARMODE
+
4.1.7 - CLEARMODE
AZAAA CM #coder-com ovpsmikbl
@@ -1095,6 +1110,12 @@ succeed never the less.
AZAAA N Nick2 955423230
4.2.2 - MODE
AZAAA M Nick2 :+odi
+4.2.3 - ACCOUNT
+AX AC AZAAA oper
+The ACCOUNT message provides a way for servers, such as the channel service
+server, to set the account name information that is associated with a client.
+Once set, it cannot be unset or changed, and will be propagated in NICK during
+net bursts using the special user mode +r followed by the account name.
4.3 Channel/Client Messaging.
4.3.1 - PRIVMSG
@@ -1137,6 +1158,9 @@ from msg.h. -Gte.
[2000-04-10]: Added information about OPMODE and CLEARMODE tokens.
-Kev
[2000-04-11]: Started work on chapter 4. -Gte
+
[2000-06-01]: Changed some info about the max number of clients -Isomer
+
[2002-01-11]: Wrote a specification for ACCOUNT and noted that a usermode
+in a NICK message may have an argument. -Kev
8.1 TODO