RE: [dcdev] Re: New Encoding Scheme First
"Zdenek Stangl" <[email protected]>
2003-12-01 10:59
"Direct Connect developers" <[email protected]>

- compression should be optional, no doubts about it ;)
- semi-binary header != binary protocol. All I would like to have is the fourcc AND length at the begining of message. Everything else remains text-based. With such scheme the debugging is still simple + the parsing mechanism would be more generic and fast.

-----Original Message-----
From: Fredrik Tolf [mailto:[email protected]]
Sent: Friday, November 28, 2003 8:18 PM
To: Direct Connect developers
Subject: Re: [dcdev] Re: New Encoding Scheme First

Zdenek Stangl writes:
> hi, just a few quick thoughts from my points of view:
> > - no hub-side data compression. There are still low-end hubs
> running 1000+ users

Like Jernej said, isn't it better to make it optional? That way the
hub owner can decide the policy depending on his CPU or bandwidth. The
hub can simply:
1. Not request compression (For low-CPU hubs)
2. Request compression (For high-end hubs, make the client decide)
3. Require compression (For low-bandwidth hubs)

Like Jernej also said, I think encryption should be considered as
well. There are several good reasons, including the ability to
authenticate on certificate basis (for ops, for example).

> - for commands format i would prefer either
>   a) short fourcc header for every command with command type and
>   data length. Therefore no command separator and no
>   newline/space/or_whatever escaping is needed (I know, the
>   byte-order differences on various OSes but hey, sockets
>   implementation deals with the same problem and it's working
>   fine... htons, ntohl etc...  what's faster? Swapping of two bytes
>   from the header or parsing the data for [end] separator? Not all
>   messages are sent in one piece...)
>   or b) let the command is zero-terminated string without length in
>   the header. But then we are back in searching for data-end.

I do not agree with you. Although binary protocols admittedly have
advantages, it isn't that hard to implement quoting anyway, so why not
simplify debugging and monitoring by using a text-based protocol
instead? When it comes to using CPU power, there are far greater
problems in a DC implementation than protocol parsing. Like searching,
for example.

I do agree that there should be fourcc commands, though, unlike
DN-TNGs idea of using command strings. Fourcc commands simplifies
things for all parties. In most else I agree with DC-TNG, though, for
example having CRLF line terminators for consistency with other
Internet protocols.


Fredrik Tolf

DC Developers mailinglist
DC Developers mailinglist