On Tuesday, October 28, 2003, at 10:02 AM, eric wrote:
4) To maintain some of the binary advantages, I'd suggest going back
Why not even use only 2 characters (=>26*26 = 676 possibles alpha
old FOURCC codes, and have the first letter denote command type. Then
<from-guid> <text without nick> would be a broadcast chat message,
<nick> a hub validatenick-type command and CCON <to-guid> <from-guid>
over, if we are using a GUID instead of nickname, we can even remove
separator because GUID have a constant size. Using this, a private
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? :)