...

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.

That's my point ;)

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 :)

Because of that a protocol is called protocol ;) Once you design the format (in this case the order of bytes in fourcc tag and order of length bytes) then it becomes a rule which needs certain implementations on certain platforms/OSes ;) Lets focus on protocol design, not the API.

Eric

Zdenek