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

...

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:

I totally agree with you on the header format and I also think the data (which are like command parameter) should have a similar structure.

loop_over_entire_data_block_and_look_for_the_pipe_by_comparing_each_byte_wi
th_0x7C. There is no kernel_based solution under windows systems). I don't

I don't think unix has such thing and in any case, kernel_based only means the kernel does it. It is easier to let the kernel or a library to it but it is always slower to do something comparing to not to do it.

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'm 100% with you :)

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.

My opinion only engages me as both hub and client coder :)

Eric