IACD - Extensions

1. Client communication

1.1 SET command

    All information about the client that is given out by the server to
    other clients can be changed.

    Values possible to change:
      - IRCNAME        real name
      - HOSTNAME       hostname
      - USER           username

1.2 THISTORY command

    THISTORY <channel> [<last>]

    iacd can keep track of the last 10 topics being used. THISTORY will
    send them with a user notice if the command THISTORY is invoked.

1.3 Auto Away

    MODE +A [<time>]  (default=300 seconds)

    You will be marked as away after <time> seconds of inactivity
    (= idle time)


2. Server communication

2.1 Message Cache / Link Loops

    The protocol described in RFC 2813 (IRC Server Protocol) can not be used
    in a network that uses loops or redundant server links. Because message
    would be interpreted multiple times.

    The flag 'C' 0x43 (Cache) as server option in PASS (chapter 4.1.1 RFC
    2813) can be used to solve this problem. This will force using a message
    cache to detect already received and parsed messages. To make this
    possible, each message needs to be prefixed with a message id that is uniqe
    for at least number of servers x MSL.

    Message:
    <server numeric><delim><message id><delim><message>

    <delim> = ':' 0x3a
    <server numeric> = unique like the hostname, also called server token
    <server message> = unique for some time in server numeric namespace

    The server numeric (server token) must be unique for all servers not like
    in the RFC 2813 just for the peer to peer connection.


2.2 Server synchronisation

2.2.1 How does it work

    Server synchronisation is needed to synchronize the server after a
    Server-Server connection dies. There are 2 effects that can be caused
    with the event of interruped server connection: Causes a netsplit, thus
    the network is splitted into 2 parts. Or the network is still one because
    there is another way the messages can go to reach every server.
    The second case does not need any interference but it is hard to decide
    if the network is actually splitted. Thus in both cases a SYNC message is
    produced by BOTH servers. To avoid parallel SYNC processes interfering
    each other the SYNC start procedure should be limited to one per minute.

    The SYNC message will be broadcasted to all servers and each servers markes
    all his server entries (not the server connection entries) and all
    non-local client connections as to be removed. We mark this state as ready
    to sync.

    2 seconds later each server sends out it's own SERVER line and NICK lines
    for each _local_ user. All those messages have to be broadcastet again to
    reach all servers.

    All servers receiving one of these lines must interpret them. SERVER lines
    will create new server entries or unmark entries as to be removed.
    NICK lines will create new users, change nicks, kill nicks forced by a
    nick collision or unmark non-local users as to be removed.

    30 seconds after the read to sync state another timer is called to check
    all server and client entries for entries with the flag to be removed
    still set will be removed.


2.2.1 SYNC message

    format: SYNC

    A SYNC message broadcasted to all server introduces a sever
    synchronisation. The message needs to be forwarded by all servers to reach
    all server as fast as possible.

