DOMAIN IS FOR SALE! MAKE AN OFFER to mail@maytech.ru

CTCP

Client To Client Protocol (CTCP) is something that IRC clients have used for a long time, to use the server as a transport for binary data. This is good because clients can be readily upgraded to new commands and tricks without the server having to be updated.

One way is to use Search for broadcast CTCP and passive SR for directed CTCP. Alternatives are mainchat and private messages, respectively. The problem with them are that if a old non-ctcp client receives ctcp variants of those, there is a risk the user will see garbage on his screen. Neither SR nor Search will produce garbage, and certainly not in the text-portion of any window.

(I realize c-c should be used whenever possible. Adding "$SendCtcp <bytes> <data>|" is possible, or $SendZCtcp for a zblock-compressed version. This is somewhat odd though since the current c-c is a get-only protocol. Also this is only the lowest level of ctcp, the actual transport. Meanings must be given to messages in a standard way between clients for CTCP to work, specifically different encodings should be specified due to the holes in the range of bytevalues allowed)

Contents

Simple one, search-by-hash already uses a equivalent approach. The search string should be

CTCP:<data>


Searchtype should be set to 10, atleast dch++ propagates these searches.

Directed

A normal SR has the format:

\$SR <fromuser> <path\to\file.ext><0x05><filesize> <freeslots>/<openslots><0x05><hubname> (<hubaddress[:port]>)<0x05><touser>|


Ideally, clients which do local filtering of SRs should have a high chance of filtering any CTCP SRs out as to not present garbage results to the user in old clients. The path part is replaced with "\CTCP:V1\". The data is stored in the hub name field, after a "CTCP:" prefix. The data can, of course, not contain byte values that DC doesnt want in these contexts (SR+Search): "|", "\5" and ("\0"), anything else?

The size should be a magic number, negative is good: -8083048

Why use CTCP?

The CTCP mechanism is one way to lay the burden of implementation on those that use the implementation. It is not as effective as specifying a new extension (since some space will have to be sacrificed to specify encoding and to differentiate commands) so it is a bad idea to use CTCP for anything high-volume. Those that do not want to use CTCP has a very easy task of filtering everything-CTCP out.