Zdenek Stangl writes:
> 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())

Might I ask what you want the FF FF start word for?

> 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.

I just find it a bit unnecessary that you are into it as far as
eliminating a single instruction for bit-shifting, when you still need
to broadcast packets to 1000+ users, going through the kernel's TCP
assembly code and everything. To me, that optimization seems far less
than necessary, since your program will be blocking most of the time
anyway, waiting for the kernel to flush network data.

Especially so since you still have to word-split the data to process
it.

Fredrik Tolf