Ämne:Re: [dcdev] ADC Issues
Från:Carl-Adam Brengesjö <[email protected]>
Till:Direct Connect developers
There are issues with ADC that I personally consider should be changed
or looked more deeply into.
First of all it's the message delimiter \r\n that should be changed to
\n. There is no reason to favor the current win32 implementation of
new-lines here, it only adds bug-sources to code. Splitting messages
with only one 'char' is better in every possible way I think. And this
isn't http anyway ;)
Numbers should be at least double? "double" is implementation-specific
so I guess you mean 64-bit? And then, why? This must be, just like
integers being 64-bit, state dependant. Not all kinds of data needs such
large numbers, I'd say that's a specification that should be removed
from the protocol.
In the ERR message there are params and description. Since this protocol
says that message parts are delimited with space, and descriptions can
include space, how will I know what is a parameter to ERR and what is
the description? Maybe "ERR Code:Descr: param1 param2..." is a better
way, and force description not to include ':'.. It's ugly yes, but just
In INF I couldn't see an ip port for TCP. How will client A be able to
connect to client B without knowing the TCP port? Maybe I missed
And when speaking of INF, "HI"? Can an arbitrary user send that info to
become invisible? I think it should be used only for special occasions
of some kind of bots. And then it's prolly up to the hub anyway to "make
it hidden", so, I really don't see the use of this.
I would like a "mode" where file sharing is disabled, a kind of "chat
only mode". That should be represented in the INF as well with HC or
something like that..
If I send a MSG how will end-lines be escaped? The regular \n (or if
\r\n for some very weird reason is preferred) will cause the next line
to be interpreted as another message/command, right?