Re: bencoding 0:

--- In [email protected], Elliott Mitchell <ehem@m...> wrote:
> >From: skybuckflying <skybuck2000@h...>
> > I was just wondering if the following "bencoded" string is valid:
> > 
> > 0:
> > 
> > This would mean an empty string ?
> > 
> > Looks logical to me... just wondering though ;)
> 
> Yup. Perhaps not the most common string to deal with, but clients 
will
> encounter it and must correctly handle it. In particular the first 
client
> to connect to a tracker will see that as the list of peers.

Excellent :)

So that means the minimum size of a string is 2 characters.

I do wonder a bit about the "character set" being used...

It's probably just ansi... and unicode is compatible with that... lol.

I do wonder what about if chinese people want to make chinese file 
names ? :)

Maybe that's a bad idea in general lol :) Let english rule the world 
hehe... 

Anyway...

I guess the minimum size of an integer is 3

i0e

and the minimum size of a list is 2

le

And that it is possible to have multiple empty embedded lists ?

llleelelelleee

:) 

I haven't reached the dictionary stage yet =D

Also I wonder a bit about the infinite integer thing....

integers are defined as infinite so it might be possible to encounter 
something like:


i123456789012345678901234567890e

Have you seen anything like that in the "wild" ? :)

Oh yeah... and then the last thing...

The size of the string... this is crucial... since euhm this one 
really has to be converted to integers.... well maybe not really but 
otherwise it would be to difficult to parse...

For example:

12345:string etc...


12345 has to be turned into an integer... so that exactly 12345 
characters can be read...

Though my current language is kinda limited to 32 bits or at most 64 
bits.

So that means there is a limit to it... at least for "my 
implementation"

Currently the limit would be 2 Giga value. (2*1024*1024*1024) 
probably -1 ;)

Though I think 2 Gigabyte strings are pretty rare in the wild ? :)

So I don't think this is much of an issue...

If the size part is much large then the real string.. then my 
implementation will simply exit that parsing of it... so that's no 
problem ;)

Hehe, this bencoding is quite cool =D lol.

At first I was like.. gjezus man... what a wacky way to code 
something... but then again... xml would be too much overhead... and 
binary might be difficult too... big endian/little endian.. and fixed 
positions ? is that it ?

Bencoding might be more flexible ? because if some fields are missing 
bittorrent might still work ?

That's an advantage compared to a binary format... if there are 
things missing and it's "packed" etc... then it will be all wrong :)

But with a dictionary... it won't be wrong... some "words" might just 
be missing that's all ;)


Though... maybe the dictionary functionality could be simulated in 
binary by simply using binary "keys"


Maybe something like

byte identifiers:

01 begin of list
02 end of list
03 begin of string
04 end of string
05 begin of integer
06 end of integer

and then maybe something like

03
size of string
strings
04

hehe

that's actually the same as euhm the char thing so no savings there.

But for the dictionaries there might be some savings...

the key "file" which is 4 characters might be replaced with some byte 
value say  "7" or so... that would save 3 chars hehehehe.

So switching all the "dictionary key fields" (which are now 
transmitted as strings/text I believe... ) to "binary values" might 
save some bytes during transmission :)

Well suppose one still wants to save more... then dynamic huffman 
compression could be applied... but let's not do that lol... way to 
difficult ;)

If it's done... I hope a little indicator might be used to 
say: "compressed" or "uncompressed" data/stream/text if you know what 
I mean ;) so that client implementations can simply 
use "uncompressed" protocols at first as they develop... and more 
advanced implementations might used the "compressed" version of it :)

Bye,
  Skybuck.





------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dkFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/