P10 Protocol

Revision as of 00:11, 17 February 2009

This document is based on the P10 protocol specification (p10.html) as of ircu 2.10.11. It aims to be a practical guide for implementing and maintaining the protocol, not just a reference manual; therefore, it can be considered a "work in progress," continually being updated.

General Concepts and Background

Concepts

The P10 protocol (as developed by Undernet) uses a scheme of "Numerics" to uniquely identify a client or server within the network. Each server has its own unique numeric (0 -> 4095) and each client has its own numeric within that server (0 -> 262,143).

The numerics are encoded into a Base64 stream to maintain human readable data flow, and to reduce the size of messages. The Base64 character set used in ircd-darenet (ircu) is included below, this defines all valid characters allowed in a Base64 numeric with "A" representing 0 and "]" representing 63.

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789[]

Server numerics consist of 2 characters, with the minimum, 0, being represented by "AA", and the maximum, 4095, being represented by "]]". Client numerics are 3 characters long, with the minimum, 0, being represented by "AAA", and the maximum, 262,143, being represented by "]]]". The unique identifier of a client on the network consists of a combination of both the server and client numeric in the format SSCCC.

As an example, consider a server "irc.darenet.org" which has a numeric of 2, translating to "AC" in Base64. On this server exists a client, whom has been allocated the numeric 63 (which translates to "AA]" in Base64). Therefore, the unique identifier of this client on the network is "ACAA]". From this, we can determine which server the message came from, as well as the client who sent it.

These numerics are used to prefix every message issued on the stream except for the initial "PASS" or "SERVER" message, which are not prefixed. Therefore, every message that can be received from a server will consist of the format:

[NUMERIC PREFIX] [TOKEN] [DATA]

For example:

A[A5j P ABAAA :Foo.

Token Table

The following table lists all the acceptable messages, along with their relevant "Token", which is used in the server<>server protocol. The aim of tokenisation is to reduce the bandwidth used during network communication by reducing the length of common message identifiers.

Registration and Synchronization

Server Registration and Authentication

After a TCP connection has been established, the server initially introduces itself via a "PASS" message as follows:

PASS :[PASSWORD]

"PASSWORD" is simply compared with the password present in the destination servers config file, and is used to confirm credentials after the "SERVER" message has been received, as follows:

SERVER [SERVERNAME] [HOPCOUNT] [START TIME] [LINK TIME] [PROTOCOL] [NUMERIC/MAXCONN] :[DESCRIPTION

For example:

1      2                3 4         5         6   7     8 
SERVER irc.darenet.org  1 933022556 947908144 J10 AA]]] :[127.0.0.1] A DareNET Client Server.

Notes:

1. The SERVER message, indicating this connection wishes to introduce a new server to the network.
2. The name of the server you are introducing, a valid server name consists of [..defn..].
3. The hop count of the server you are introducing, this is always 1 when you are introducing yourself.
4. The epoch timestamp specifying when the ircd was started.
5. The epoch timestamp specifying the time the server initiated the link to the network.
6. The Protocol identifier of this server.
   1. This token informs the network which protocol it is compliant with, eg: If it is a P10 compliant server, then the token will be "P10".
   2. If the server being introduced has not yet successfully synced its database with the network (Completed its net.burst), then the Protocol token should be prefixed with a J, instead of a P (Eg: J10) to indicate it is currently still joining the network.
   3. The protocol token should always be JXX when the server is introducing itself.
7. The numeric, and maximum connections identifier for this server.
   1. 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). 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.
   2. The example "AA]]]" shows that this is a server with numeric 0, which will generate client numerics up to 262,143.
8. This final parameter simply consists of a textual description of the server prefixed by a colon. This is displayed in a clients WHOIS line, as well 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,

Network Database Resynchronization

After the connection (link) has been established and verified, the next step is to synchronize the database of client / server / channel information between the two servers.

SERVER Messages

Server details are transmitted via "SERVER" messages, similar to the initial introduction message, with the following format:

[OWNING SERVER PREFIX] S [SERVERNAME] [HOPCOUNT] [START TIME] [LINK TIME] [PROTOCOL] [NUMERIC/MAXCONN] 0 :[DESCRIPTION]

The syntax of this message is almost identical to the originally received server message, with the exception being that the message is prefixed with a numeric 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, which is just a placeholder for future use and currently unused.

NICK Messages

Client information is transmitted via "NICK" messages, of the following format:

[NUMERIC PREFIX] N [NICK] [HOPCOUNT] [TIMESTAMP] [USERNAME] [HOST] <+modes> [BASE64 IP] [NUMERIC] :[USERINFO]

For example:

1  2 3       4 5         6     7            8     9      10    11
AF N Client1 1 947957573 User userhost.net +oiwg DAqAoB AFAAA :Generic Client.