dcdev mailing list

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

An example:

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

Yes, yes, I know, who (but me :) ) will use such things. Let's try something more useful.
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 ?

Eric

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

$Search pattern mp3|

2) an avi bigger than 2MB

$Seach pattern avi 2097152|

3) an mp3 bigger than 2 MB but smaller  than 10MB

$Seach pattern mp3 2097152 10485760|

4) an avi or an mpg being bigger than 350MB but smaller than 700MB

$Search pattern avi,mpg 367001600 734003200|

The 2 first cases are easy, show me the third and the fourth :)

IMHO there is nothing a binary protocol can do that a text one can't. The only thing it has to be considered is efficiency.

Bye

-- 
    Anakim Border
    aborder@users.sourceforge.net
    http://pydc.sf.net

Jan Vidar Krey writes:
> On Tuesday 02 December 2003 18:25, eric wrote:
> 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
> > SRCH [dest] [search id] audio/mpeg >0 [pattern]
> > > 2) an avi bigger than 2MB
> > SRCH [dest] [search id] video/x-msvideo >2097152 [pattern]
> > > 3) an mp3 bigger than 2 MB but smaller  than 10MB
> > SRCH [dest] [search id] video/x-msvideo 2097152-10485760 [pattern]
> > > 4) an avi or an mpg being bigger than 350MB but smaller than 700MB
> > SRCH [dest] [search id] video/x-msvideo,video/mpeg  367001600-734003200
> [pattern]
> > Note:
> Sizes can be (where xxx is a number indicating size in bytes):
> 1)      ">xxx" means more or equal.
> 2)      "<xxx" less or equal
> 3)      "xxx" exact size
> 4)      "!xxx" not exact size
> 5)      "xxx-xxx" more or equal and less or equal
> 6)      "xxx,xxx" list of exact sizes
>         ">0" any size (actually just number 1)

You might want to take a look at the SRCH criteria syntax that I
described in my draft just recently. I kind of liked it. I don't know
if I like the grouping syntax (because of the overhead it gives on
clients), but I think the rest of it was rather good.

Fredrik Tolf

I'm working on an updated draft for DCTNG, and here are some of the new
syntax, which I find more generic.
First of all, it's using mime-types, which I find as a good idea as it
allows for alot of interresting ideas. (Live video or audio streaming over
the DC protocol, anyone?).
The draft will be updated by the end of this week.

mime-types are good but the problem is to have an common mime-type database. There is lot of mysterious type (let's say application/ms-tnef (outlook) or application/proxy (netscape)) which are only know on a single platform (or even a single program) and there is even (a lot of file) file type without mime-types (let's say .ogg and .ogm files).

Eric

IMHO there is nothing a binary protocol can do that a text one can't. The
only thing it has to be considered is efficiency.

Yes, only efficency is important.

BTW, I have totally forgotten something. I think search query must contains an ID (a sequential uniq number for each user) to avoid conflict between search when replies arrives 2 or 3 minutes later due to a network congestion.

Eric

Ok, since everyone's doing it, I will as well...
http://dcplusplus.sf.net/ADC.htm (yes, it's an ugly filtered word htm thing
etc, but that was just to get the nice autonumbering)...I threw it together
in two hours so I've probably forgotten a bunch...
As to searching, no regexp, that's for sure...
I can strech as far as + and - to indicate what should and should not be
searched for, but ||, nested expressions etc you'll have to filter
locally...

/J

-----Original Message-----
From: dcdev-bounces@dcportal.net [mailto:dcdev-bounces@dcportal.net] On Behalf Of eric
Sent: Wednesday, December 03, 2003 6:09 PM
To: Direct Connect developers
Subject: Re: [dcdev] Protocol draft.

> I'm working on an updated draft for DCTNG, and here are some of the new
> syntax, which I find more generic.
> First of all, it's using mime-types, which I find as a good idea as it
> allows for alot of interresting ideas. (Live video or audio streaming over
> the DC protocol, anyone?).
> The draft will be updated by the end of this week.

mime-types are good but the problem is to have an common mime-type database. There is lot of mysterious type (let's say application/ms-tnef (outlook) or application/proxy (netscape)) which are only know on a single platform (or even a single program) and there is even (a lot of file) file type without mime-types (let's say .ogg and .ogm files).

Eric

On Wednesday, December 3, 2003, 19:42:23, Jacek Sieka wrote:

Ok, since everyone's doing it, I will as well...
http://dcplusplus.sf.net/ADC.htm (yes, it's an ugly filtered word htm thing
etc, but that was just to get the nice autonumbering)...I threw it together
in two hours so I've probably forgotten a bunch...

A few comments:

,-----[ ERR <code> <description>\r\n ]
| 5 Temporarily banned, next parameter must be an integer specifying the
|   number of seconds left until it expires, followed by the textual
|   description as usual (This is used for kick as well?).
`-----

I'd like the hub to reset the number of seconds left for certain bans - this
way, the user has the chance to fix his problem without getting reconnected
and kicked (and possibly permanently banned) while he was away -- or should
we make "don't reconnect if kicked" a requirement?

,----- [ INF <CID> <field1> <field2> ? <fieldN>\r\n ]
| IP Client IP, using standard notation from above with port. Sending this
|    field to the hub with an IP means that this client wants to run in active
|    mode. If this field is missing (or empty), it means that the client
|    should be treated as passive.
`-----

IMHO, IP should be sent from the hub to client. This would solve a lot of
problems for clients behind routers (with forwarded ports) with dynamic IPs.

-- 
Jernej Simoncic, ender@ena.si
http://www2.arnes.si/~sopjsimo/
http://deepthought.ena.si/

When you dial a wrong number, you never get a busy siginal.
      -- Kovac's Conundrum

eric writes:
> > I'm working on an updated draft for DCTNG, and here are some of the new
> > syntax, which I find more generic.
> > First of all, it's using mime-types, which I find as a good idea as it
> > allows for alot of interresting ideas. (Live video or audio streaming over
> > the DC protocol, anyone?).
> > The draft will be updated by the end of this week.
> > mime-types are good but the problem is to have an common mime-type database.
> There is lot of mysterious type (let's say application/ms-tnef (outlook) or > application/proxy (netscape)) which are only know on a single platform (or > even a single program) and there is even (a lot of file) file type without > mime-types (let's say .ogg and .ogm files).

Mime types are certainly good. On UNIX it's no problem - just fork a
'file -i' process to get it. I don't know how it would be done on
Windows, but I think there is some shell32 function for it. I haven't
been writing Windows programs for some years, but it should be
possible.

Fredrik Tolf

eric writes:
> > > IMHO there is nothing a binary protocol can do that a text one can't. The
> > only thing it has to be considered is efficiency.
> > Yes, only efficency is important.
> > BTW, I have totally forgotten something. I think search query must
> contains an ID (a sequential uniq number for each user) to avoid
> conflict between search when replies arrives 2 or 3 minutes later
> due to a network congestion.

It most certainly has to, but I thought that was already decided upon
long ago?

Fredrik Tolf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm working on an updated draft for DCTNG, and here are some of the new
syntax, which I find more generic.
First of all, it's using mime-types, which I find as a good idea as it allows
for alot of interresting ideas. (Live video or audio streaming over the DC
protocol, anyone?).
The draft will be updated by the end of this week.

On Tuesday 02 December 2003 18:25, eric wrote:
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

SRCH [dest] [search id] audio/mpeg >0 [pattern]

2) an avi bigger than 2MB

SRCH [dest] [search id] video/x-msvideo >2097152 [pattern]

3) an mp3 bigger than 2 MB but smaller  than 10MB

SRCH [dest] [search id] video/x-msvideo 2097152-10485760 [pattern]

4) an avi or an mpg being bigger than 350MB but smaller than 700MB

SRCH [dest] [search id] video/x-msvideo,video/mpeg  367001600-734003200
[pattern]

Note:
Sizes can be (where xxx is a number indicating size in bytes):
1)      ">xxx" means more or equal.
2)      "<xxx" less or equal
3)      "xxx" exact size
4)      "!xxx" not exact size
5)      "xxx-xxx" more or equal and less or equal
6)      "xxx,xxx" list of exact sizes
       ">0" any size (actually just number 1)

Cheers

- -- - -janvidar-

Dj Offset / QuickDC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/zaYpMLjmoUcyZAoRAlW8AKCmQ9pNxu0Xu2NMts2wsGbHxyRXqgCgrOsF
0FC+ugCbuu47hjVsD8p+NP8=
=gP6p
-----END PGP SIGNATURE-----

On Wednesday 03 December 2003 19:42, Jacek Sieka wrote:

Ok, since everyone's doing it, I will as well...
http://dcplusplus.sf.net/ADC.htm (yes, it's an ugly filtered word htm thing
etc, but that was just to get the nice autonumbering)...I threw it together
in two hours so I've probably forgotten a bunch...
As to searching, no regexp, that's for sure...
I can strech as far as + and - to indicate what should and should not be
searched for, but ||, nested expressions etc you'll have to filter
locally...

isn't your fourcc looking like 3cc ? :)

Eric