[dcdev] Re: New Encoding Scheme First
"Zdenek Stangl" <[email protected]>
2003-11-28 4:26
"dcdev (el. adresa)" <[email protected]>

hi, just a few quick thoughts from my points of view:

- no xml. Too big payload:usefull_data ratio
- no hub-side data compression. There are still low-end hubs running 1000+ users
- for commands format i would prefer either
 a) short fourcc header for every command with command type and data length. Therefore no command separator and no newline/space/or_whatever escaping is needed (I know, the byte-order differences on various OSes but hey, sockets implementation deals with the same problem and it's working fine... htons, ntohl etc...  what's faster? Swapping of two bytes from the header or parsing the data for [end] separator? Not all messages are sent in one piece...)
 or b) let the command is zero-terminated string without length in the header. But then we are back in searching for data-end.
- keeping of own nicks in messages/commands sent to hub? Whatever... In both cases (Checking_and_broadcasting or reconstructing_and_broadcasting) you will have to copy the same amount of data to broadcast it. Just in the first case you will have to perform string comparsion which will fail with spoofed_nicks_commands only, therefore in 99% of cases the strcmp will loop over whole nick. From this point of view the sending of own nicks is rather inconvenient. Two calls to strncpy are faster than one call to strncmp + strncpy. But it all depends on design of certain commands...

lets kick our brains asses ;)

DC Developers mailinglist