On Tuesday, October 28, 2003, at 10:02  AM, eric wrote:

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.

Why not even use only 2 characters (=>26*26 = 676 possibles alpha word). More
over, if we are using a GUID instead of nickname, we can even remove some
separator because GUID have a constant size. Using this, a private message
can be coded (for example)
PMguid1guid2blah blah blah|
which is rather compact and fast to decode.

Well, if you use only two characters, you really only have 3*26 command types.  Implicit was the idea that the first character is either H (for client to hub), B (for client to broadcast), or C (for client to client).  This way, if you're not validating commands, the logic required to route the request is pretty simple.  So using only two characters is a little bit of a tradeoff between expansion (and readability) and bandwidth.

Eliminating whitespace between some commands with fixed-length parameters is definitely a worthy idea... though how much we need to reduce the protocol's bandwidth usage is something we should bring up again later.  Certainly we should code and measure a typical DC hub against a similar test protocol hub before we roll it out.


I'm interested in seeing Arne's proposal (as well as those of others).

I see our user count is up to 28 normal + 4 digested users... anyone have something to add? :)

 - Todd
DC++ Contributor