Earlier, I propose everyone to post its draft. Here is mine.
It is a binary protocol:
1) the shell:
2 bytes: pattern
2 bytes: shell size (including everything even the pattern)
2 bytes: command code (the name of the command)
1 byte: number of parameters
2) the parameter
A parameter is composed of 3 things:
1 byte: parameter size (inclunding the size)
1 byte: parameter meaning (see below)
1 byte: parameter type (integer, UTF-8, ...)
N bytes: parameter value
Using the previously posted example:
00 03 00 04 "Chat" 00 14 (20 character UUID) 00 0E "Hi everyone!\r\n"
I would have sent:
FF FF 00 2C XX XX 02 17 UU TT (20 character UUID) 10 VV YY "Hi everyone!"
FFFF => pattern
002C => shell size (I hope I have made no error :)
XXXX is the code meaning chat
02 => 2 parameters
17 => the first parameter uses 23 bytes
UU means emitting user ID (parameter meaning)
TT is the code for UUID type
10 => the second parameter ises 16 bytes
VV means message (parameter meaning)
YY is the code for UTF8 string type
In a previous mail, I speak about variable type parameters. Imagine this
(nearly same example has before):
FF FF 00 22 XX XX 02 0B UU YY "nickname" 10 VV YY "Hi everyone!"
Now, the user ID is sent as a string instead of its UID. I wonder how text
based protocol can do this but I have also something harder (too hard to
produce an example manually). You know the $Search query. Using a standard
text protocol (only 1 command allowed, you have no limit, it is a draft :)
produce me an example working for searching:
1) an mp3
2) an avi bigger than 2MB
3) an mp3 bigger than 2 MB but smaller than 10MB
4) an avi or an mpg being bigger than 350MB but smaller than 700MB
The 2 first cases are easy, show me the third and the fourth :)
With a binary protocol like the one I describe above, it is easy:
* case 3) 1 parameter has "string" type and value "mp3", the 2 nd has "size"
type and value "2MB", the third has "size" type and value "-700MB".
* case 4) Just provide 2 strings parameters, 1 is "avi" and the second is
Yes, yes, I know, who (but me :)
) will use such things. Let's try something
Imagine a private chat:
chat_command source_nick dest_nick chat_message
Easy. Whouldn't it be interesting to have a chat with more than 2 users, let's
say N (N is not defined):
chat_command source_nick dest_nick1 ... dest_nickN chat_message.
You use less bandwith to receive the data than receiving N times the message
with different nickname and the hub can handle this faster...
Opinions ? comments ?