Some random thoughts on a new protocol:

1) I like the idea about having 2-3 types of commands, type1 -> hubonly,
type2->a specific client, type3->broadcast. This way, new commands can be
added to clients without upgrading the hubs. Each of these commands would
then have a header for the hub, and the rest of the data for the client
(that the hub can check/parse/deny if needed)

2) I don't like XML. We're running short on bandwidth, so a more
conservative encoding would suit us better imho. CPU btw is afaik not an
issue (dch++ uses about 4% cpu on an average 1500 user hub on a decent
computer, don't remember exact specs, but it's so low that well...), so
perhaps we could use XML + compression if you're fanatic about it, but imho
it's a ferarri when all we need is a fiat...

3) I don't like a pure binary protocol for many reasons, ranging for hard to
debug to hard to interpret on different platforms due to different byte
order. The w3c hasn't put out any binary protocols for a reason, and yet,
these are the most successful ones out there serving millions of clients...

4) To maintain some of the binary advantages, I'd suggest going back to the
old FOURCC codes, and have the first letter denote command type. Then BCHA
<from-guid> <text without nick> would be a broadcast chat message, HNIC
<nick> a hub validatenick-type command and CCON <to-guid> <from-guid> be
connecttome. The C type messages would always have to as their first
argument so that the hub could always route them to the correct user even if
it doesn't recognise the command natively (with a setting in the hub which
commands to pass through of course), and parsing is fairly easy as each
command has fixed positions where it can pick up info.

5) I'd go for the space as separator and CR as end of command, escaping
those as needed with for instance \ (a little like a unix shell...). This to
ensure easy debug-ability...most commands could do without the
space-escaping by keeping guids space-free and placing the spaceneeding
parameter last (i e chat message)

6) UTF8 is the encoding of choice for me as well...it should suffice for
now, although we should keep an eye open for 4-byte unicode support once
that becomes popular (don't remember if utf8 can encode that or not)

In fact, I started writing on a spec for this, taking many good ideas from
jan vidar's dctng.html freely =).

Comments?

P S., This is a lot of work, which means that it'll take time. $Supports for
the hubs, using $Key tricks to avoid sending trash (unknown commands) to the
clients/hubs (for which some hubs kick) is a temporary solution, but one
that works fairly well...NONEXTENDEDPROTOCOL is used by dch++ and ptokax
afaik, and does not interfere with EXTENDEDPROTOCOL, only the beginning of
the key should be parsed (for dc++, parsing was fixed in 0.300). C-C
extended protocol is used by more clients than DC++, specifically to get the
bz lists.
/J