mirror of
https://github.com/unrealircd/unrealircd.git
synced 2026-07-03 14:13:12 +02:00
Bram Matthys
dddc8f07e4
- Server protocol: added PROTOCTL EATH=servername, which allows us to
authenticate the server very early in the handshake process. That way,
certain commands and PROTOCTL tokens can 'trust' the server.
See doc/technical/protoctl.txt for details.
- Server protocol: between new Unreal servers we now do the handshake a
little bit different, so it waits with sending the SERVER command until
the first PROTOCTL is received. Needed for next.
- Server protocol: added PROTOCTL SERVERS=1,2,3,4,etc by which a server can
inform the other server which servers (server numeric, actually) it has
linked. See doc/technical/protoctl.txt and next for details.
- When our server was trying to link to some server, and at the same time
another server was also trying to link with us, this would lead to a
server collision: the server would link (twice) ok at first, but then a
second later or so both would quit with 'Server Exists' with quite some
mess as a result. This isn't unique to Unreal, btw.
This happened more often when you had a low connfreq in your link blocks
(aka: quick reconnects), or had multiple hubs on autoconnect (with same
connfreq), or when you (re)started all servers at the same time.
This should now be solved by a new server handshake design, which detects
this race condition and solves it by closing one of the two (or more)
connections to avoid the issue.
This also means that it should now be safe to have multiple hubs with low
connfreq's (eg: 10s) without risking that your network falls apart.
This new server handshake (protocol updates, etc) was actually quite some
work, especially for something that only happened sporadically. I felt it
was needed though, because (re)linking stability is extremely important.
This new feature/design/fix requires extensive testing.
This feature can be disabled by: set { new-linking-protocol 0; };
157 lines
9.6 KiB
Plaintext
157 lines
9.6 KiB
Plaintext
PROTOCTL Documentation (c) 2002 codemastr (Dominick Meglio) [codemastr@unrealircd.com]
|
|
(As of Unreal3.2-beta11)
|
|
|
|
The PROTOCTL command allows servers to negotiate protocol specific features when a link
|
|
occurs. The PROTOCTL command is sent during a link before the SERVER and PASS commands. The
|
|
command contains tokens that list what protocols the server supports.
|
|
|
|
PROTOCTL SPACE <token> SPACE ...
|
|
|
|
UnrealIRCd supports several tokens that add additional protocol support to the server. A
|
|
list of all supported tokens and their function listed below.
|
|
|
|
Token Description
|
|
------------------------------------------------------------------------------------------------
|
|
NOQUIT Informs the server it need not send out a QUIT for each user on the server
|
|
when an SQUIT occurs. Instead an SQUIT is sent out for each server that has
|
|
been disconnected from the network and the server can then assume all users
|
|
that were on those servers have left as well.
|
|
|
|
TOKEN Informs the server that it may send "tokenized commands", that is a shortened
|
|
name for the commands. This allows the server to save bandwidth by sending
|
|
less information to other servers. See doc/technical/token.txt for a list of
|
|
all commands and their respective token.
|
|
|
|
NICKv2 Notifies the server that it supports the extended NICK command (version 2),
|
|
this command allows the server to specify more information in the NICK
|
|
command rather than having to send out a NICK, MODE, and CHGHOST
|
|
command. This token only affects a NICK command introducing a client, not one
|
|
in which a client is changing his/her nickname. The format for a NICKv2 NICK
|
|
command is:
|
|
|
|
:<sender> NICK <nickname> <hops> <TS> <username> <host> <server>
|
|
<servicestamp> <umodes> <vhost> :<info>
|
|
|
|
If the user has no modes set the umodes parameter is a +, if the user has no
|
|
vhost set the vhost parameter is an *.
|
|
|
|
SJOIN SJOIN is an obsolete token that is only supported for backwards
|
|
compatibility. It should not be used.
|
|
|
|
SJOIN2 SJOIN2 is an obsolete token that is only supported for backwards
|
|
compatibility. It should not be used.
|
|
|
|
UMODE2 Informs the server that support for the UMODE2 command exists. The UMODE2
|
|
command is a shortened form of the MODE command but only applys to
|
|
usermodes. In a normal MODE command, when applied to usermodes, the nickname
|
|
is specified two times. Both as the sender prefix and as the first parameter,
|
|
UMODE2 solves this problem in order to save bandwidth, the format for UMODE2
|
|
is as follows:
|
|
|
|
:<sender> UMODE2 <modes>
|
|
|
|
VL Notifies the server that Vline information is included in the info field of
|
|
the SERVER command. Vline information consists of the protocol number of the
|
|
server and compiletime options supported. This allows denial of a server
|
|
based on version and/or features supported. The VL information is passed only
|
|
during connection, it is not filtered to other servers on the network, only
|
|
the uplink. The syntax for a VL supporting SERVER command is:
|
|
|
|
SERVER <servername> <hops> :U<protocol>-<versionflags> <info>
|
|
|
|
If an * appears for either protocol and/or versionflags no Vline checking is
|
|
done, this is often used by services programs where support for all versions
|
|
is desired. See doc/technical/vl.txt for a list of version flags and protocol
|
|
numbers.
|
|
|
|
SJ3 Notifies the server that the SJOIN command with SJ3 syntax is
|
|
supported. SJOIN is used at link time to inform servers about the channels on
|
|
the server. It is a combination of the JOIN commands, and MODE commands
|
|
associated with distribution of channel information. The syntax for the SJOIN
|
|
command with SJ3 syntax is:
|
|
|
|
:<sender> SJOIN <ts> <chname> [<modes>] [<mode para> ...] :<[[*~@%+]member] ...
|
|
[&"ban/except] ...>
|
|
|
|
The ts parameter is the time at which the channel, chname, was created. The
|
|
modes parameter is only included if modes are set, if not modes and mode para
|
|
are excluded. If modes exists and modes requiring parameters (+klLf) are set,
|
|
one mode para parameter is included for each value. The last parameter
|
|
specifies a list of channel members and the channel ban and except list. The
|
|
members are listed with the prefixes they have. * = +q, ~ = +a, @ = +o, % =
|
|
+h, + = +v. If no prefix is specified for the member then the user is a
|
|
normal user. The & prefix is used to denote a +b, and the " prefix denotes a
|
|
+e. It is important that if a & or " is encountered that you do not continue
|
|
to check that entry for other prefixes as a ban/except may contain *~@
|
|
characters which will intefere with prefixes.
|
|
|
|
When synching, if ts lower than the local value, the information supplied by
|
|
the remote server replaces the local (ie remove local +ohv that are not
|
|
recorded on the remote server). The opposite is true when the ts is
|
|
higher. Bans/excepts do not apply to the previous rule. If the ts is the
|
|
same, information is merged therefore the modes from both servers are added
|
|
together. If +l is set and both servers have different values, the highest is
|
|
choosen, for +f the highest of each param, N:M is chosen, and if one server
|
|
has * set, then it is included. For +k and +L the "highest" in a string
|
|
comparison is used.
|
|
|
|
NS When specified informs the server that numeric server names are
|
|
supported. Numeric server names are a base64 number that is associated with
|
|
each server. This number is used as a shorthand name for the server. It is
|
|
used in the server parameter of the NICK command and can also be used in the
|
|
prefix for a message. In the event that the prefix is an NS, rather than
|
|
using :<sender>, the format is @<ns> the ns should be translated into the
|
|
server name so that the message can be processed. The format for a SERVER
|
|
message (at sync time) that supports NS is:
|
|
|
|
SERVER <servername> <hops> :U<protocol>-<versionflags>-<numeric> <info>
|
|
|
|
The VL protocol must also be supported. The numeric is passed to all servers
|
|
on the network through the SERVER command using the syntax:
|
|
|
|
:<sender> SERVER <servername> <hops> <numeric> :<info>
|
|
|
|
Note: anywhere a :<sender> is expected an @<ns> may be received if the source
|
|
is a server. See doc/technical/base64.txt for information on the base64
|
|
system used.
|
|
|
|
SJB64 This token allows timestamps to be specified in base64 notation to conserve
|
|
bandwidth. When SJB64 is supported, anywhere a timestamp can appear may be in
|
|
base64 notation. A base64 timestamp is preceeded by a ! to identify that it
|
|
is an sjb64 rather than a regular timestamp, if this is the case the
|
|
characters following the ! represent the timestamp in base64. See
|
|
doc/technical/base64.txt for information on the base64 system used.
|
|
|
|
ZIP If both servers have this set then the link will be (zlib) compressed after
|
|
the SERVER message. If one of the servers does not have ZIP in his PROTOCTL
|
|
message then the link stays uncompressed.
|
|
|
|
TKLEXT This allows 10 instead of 8 parameters in TKL's for spamfilter, see s_kline.c
|
|
function m_tkl for more info on this (added in 3.2RC2).
|
|
|
|
NICKIP This token indicates that a (standard) base64 encoded IP address is included
|
|
in the NICK command. The IP is in binary network byte order formated and
|
|
encoded using the standard base64 algorithm. '*' is used if no IP is available.
|
|
|
|
NICKCHARS This specifies a list of language characters that are allowed in nicks.
|
|
USMARC codes are used, with a suffix if needed. See src/charsys.c for the full
|
|
list (ctrl+f, static LangList) of possible languages (2nd column).
|
|
The items in the list sent as NICKCHARS=.. must always be sorted.
|
|
If a server sends NICKCHARS= and if the remote parameters do not match the
|
|
charsets in use locally, then the server link is rejected.
|
|
|
|
CHANMODES Like CHANMODES from the 005 numeric. Useful to see which channel modes are
|
|
supported/used, and can also be used to properly eat parameters in parameter
|
|
modes in the MODE command (for eg: +jk 1:1 a).
|
|
|
|
EAUTH Early Authorization. This makes it possible for servers to authenticate each
|
|
other before the regular SERVER command. Needs to be done prior to using the
|
|
SERVERS token, and possibly other tokens or commands in the future. Hence,
|
|
is recommended to be sent as first (or early) PROTOCTL token. Note also that
|
|
the PASS command should be sent prior to this PROTOCTL token.
|
|
EAUTH=my.server.name[,options]
|
|
|
|
SERVERS Informs the other server about the other servers (numerics) on this network
|
|
(including our own numeric).
|
|
Syntax: SERVERS=numeric1,numeric2,numeric3,etc
|