On Monday 01 December 2003 13:28, Fredrik Tolf wrote:
Zdenek Stangl writes:
> - 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.
I forgot to say, IMHO that would make the parsing algorithm less
generic, since it must treat the command name specially. A generic
algorithm would treat the command just like any other word in the
line.
I don't agree with you, even a semi-binary header can speed up stream
processing for a hub (and also the client) but only if it is the very thing
to come (before any fourcc). Currently, when data arrives, the only way to
know if a full command line is received is to search for '|' again and again
until the full line is received. If a binary header which contains the bloc
size, you just have to check the value with the size of the buffer of
incoming data.
The size in the header can also be optimized to be stored in 1 byte (as small
as the "|") and for bigger commands, we can use an escape code like 0 or 255
to tell the size is stored in 2 bytes (like in x86 instruction set) (it is
probably better to keep 0 as connection pulse to speed up detection of broken
connection).
In your previous mail, you also speak about text based protocols being easier
to debug because we can use telnet but there is some problem here:
1) you cannot use telnet on DC protocol because telnet sends the command after
a "return" and because the end of command is "|" in DC, you will have a LF in
the buffer at the beginning of the next command
2) the debug status is only temporary (or it is a very bad protocol with bad
programmers).
3) unlike us, clients and hubs always know the size of the data to send before
sending them because they have built the command.
About fourcc usage, I am not sure we can gain a lot here because there is some
problem to take into account. Comparing 4 characters is always faster than
comparing string of unknown size but to be very fast, we must compare the 4
bytes simultaneously (one 32bits value). However, in this case, we must
define the endianness of the protocol (big endian is better, like any
portable network protocol (TCP, IP,...) else we will have PC clients
incompatible with MAC one (ABCD on PC is displayed DCBA on mac). Only a onecc
can solve the problem without conversion
:)
Eric