diff --git a/doc/technical/serverprotocol.html b/doc/technical/serverprotocol.html index 5dc757b9e..36674c3b2 100644 --- a/doc/technical/serverprotocol.html +++ b/doc/technical/serverprotocol.html @@ -98,7 +98,8 @@
  • TKLEXT : Supports exntended TKL messages for spamfilter support.
  • NICKIP : Adds an IP parameter to the NICK message, which is the base64 encoding of the user's ip address (in network byte order). Requires NICKv2.
  • NICKCHARS : Indicates the set of enabled nickchar options (see the regular documention for info about this).
    • -
  • CHANMODES : (Not required to be sent) This is the same as the CHANMODES value in the 005 for client connections. Useful for autodetecting things like what modes are valid for ChanServ MLOCK, for example.
    • +
  • CHANMODES : (Not required to be sent) This is the same as the CHANMODES value in the 005 for client connections. Useful for autodetecting things like what modes are valid for ChanServ MLOCK, for example.
    • +
  • CLK : Supports an extra field in NICK for sending the cloaked host (not vhost).

    • The syntax examples here follow the conventions for TOKEN and also NS in cases of server-only messages.

    2.3 SERVER - Server Negotiation

    @@ -157,9 +158,12 @@

    Syntax (nick change): :oldnick & newnick :timestamp

    This format of the NICK message indicates an existing user is changing his or her nickname. If a collision occurs, see the section on Nick Collisions below. The timestamp is the new nickname's timestamp.

    Syntax (normal): :source.server & nick hopcount timestamp username hostname server servicestamp :realname

    -

    Syntax (NICKv2): :source.server & nick hopcount timestamp username hostname server servicestamp +usermodes virtualhost :realname

    +

    Syntax (NICKv2): :source.server & nick hopcount timestamp username hostname server servicestamp +usermodes virtualhost :realname

    +

    Syntax (NICKv2+CLK): :source.server & nick hopcount timestamp username hostname server servicestamp +usermodes virtualhost cloakhost :realname

    Syntax (NICKv2+NICKIP): :source.server & nick hopcount timestamp username hostname server servicestamp +usermodes virtualhost nickipaddr :realname

    -

    This format of the NICK message introduces a new user to the network. If PROTOCTL VHP is enabled, the user's cloaked host is put in the virtualhost field, otherwise it'll be * unless the user is +t.

    +

    Syntax (NICKv2+NICKIP+CLK): :source.server & nick hopcount timestamp username hostname server servicestamp +usermodes virtualhost cloakhost nickipaddr :realname +

    Note: Because each server normally does its own cloak generation, Unreal does not expect to receive NICK messages with the CLK info, so do not send it. It will send this info to a server it has received a PROTOCTL CLK from however.

    +

    This format of the NICK message introduces a new user to the network. If PROTOCTL VHP is enabled, the user's cloaked host is put in the virtualhost field, otherwise it'll be * unless the user is +t. With the addition of CLK, VHP is no longer necessary for determining the cloak host.

    3.1.1 Nick Collisions

    A nick collision occurs when a server receives a NICK message (or & token) introducing a user that the server already sees on the network. When a collision occurs, one or both of the colliding clients must be disconnected. The timestamp is examined to determine which client loses. The client with the earlier timestamp remains. If both clients have equal timestamps, both are removed. Currently, Unreal handles NICK collisions both passively and agressively: