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

for the case of total data distortion. I think it's always better to have some 'anchor' for cases, when data goes inconsistent or mangled, than none.

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.

Doing word-splitting for every incomming data on the hub-side isn't really good idea. For current DC protocol, Im having custom parsing routine for every single command, looking only for tokens or specific parts that I really need for the processing. Im also avoiding data copying/moving as much as possible and believe me, all this has helped to gain performance of ptokax by approximately 15% in 0.330 version in comparsion with currenlty available 0.326, which uses string classes and copies data a lot. And that's just the parsing mechanism. All sockets are in non-blocking mode - when underlaying tcp kernel wouldblock, im buffering data by myself - no blocking, no threads.

There is still something missing in our discussion, to have it constructive. Try to come out with alternatives, if you can't agree with my draft, please.

Fredrik Tolf

Zdenek.