Oh now I got it ;) The reason why I've wanted the fourcc first was that the fourcc tag would also act as command-start flag and as such it should start always with the same pattern because the data length bytes will always vary. With such header there is also no need for data-end separator and the 0 byte could be used for other tasks such as heart-beat signaling. To be a little more exact, here is my rough idea of the message packet format:

|- 6_bytes_hdr -| |---data--->
FF FF 00 XX LL LH DA TA .. ..

FF FF - the data start flag
00 XX - command code
LL - low byte of length word
LH - high byte of length word
(data length includes the header length - simply length of data used in send())

The 00 byte of the command code seems to be redundant, but reading from memory without explicit type conversion is always better. With this model Im able to read bytes 2-5 at once into single int variable, and have data-length by simple masking the value by 0x0000FFFF or get the command code with 0xFFFF0000 mask. Then by #defining commands from 0x00010000 up, there is also no need for bit-shifting, if I could dig into possible implementation details here :o)
The data header is always 6 bytes long, so there is no big deal with searching for command data begin.

Just for sure: Im thinking about this all from a hub-coder perspective. For me it's always big advantage to be able look-up a command quickly and know the data length without the need to search for command separator (in other words: loop_over_entire_data_block_and_look_for_the_pipe_by_comparing_each_byte_with_0x7C. There is no kernel_based solution under windows systems). I don't care of UTF encoding or other client-side issues. All Im doing in most cases is receiving-data -> processing-data (with minimal alternation) -> transmitting/broadcasting-data and I have to do it really fast to serve more than thousand of simultaneous connections. Therefore the message-packet length and unified command identificators would be of great help (not just) to me.

Comment it please, Im willing to discuss this matter deeply and I would like to find good compromise which would satisfy both the hub and the client coders.

Zdenek.


-----Original Message-----
From: Fredrik Tolf [mailto:[email protected]]
Sent: Monday, December 01, 2003 7:44 PM
To: Direct Connect developers
Subject: RE: [dcdev] Re: New Encoding Scheme First


Zdenek Stangl writes:
> I would like to see particular C/C++ implementation of such
> statement ;) If you know, that message fourcc tag is 4 bytes long
> and that the data length bytes are at positions 5 and 6, what's
> wrong then? First you check the received length against the value
> in header, if it's ok, then you lookup the command by it's fourcc,
> process it and then jump right at the begining of next command if
> there is any... In my opinion it's the same for every single
> command. Correct me if Im wrong.

If you do it that way, yeah. However, since you wanted a word splitter
anyway, I say it's more generic to have the command be part of the
final word array, just like shells and everything else do it. While
your model has packets consisting of three parts (fourcc, length,
data, where the fourcc could just as well be part of the data), my
model only has two elements (length, data). Since the fourcc tags have
the same syntax as the rest of the data anyway, I'd say it's better to
just keep all of it part of the same part of the packet.

That's just my opinion, of course.

Fredrik Tolf

> > -----Original Message-----
> From: Fredrik Tolf [mailto:[email protected]]
> Sent: Monday, December 01, 2003 1:28 PM
> To: Direct Connect developers
> Subject: RE: [dcdev] Re: New Encoding Scheme First
> > > 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.
> > Fredrik Tolf
> > -- > DC Developers mailinglist
> http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev
> -- > DC Developers mailinglist
> http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev