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