The email is mess, but still understandable with some effort
Code:> i wonder again and again why one would use 4Kb blocks. i chose 4M > (mega) blocks - full bit-map of blocks for 8GB file can be sent in a > single Ethernet packet. Of course you can do that, both in the current implememtation and in what we are discussing for bt2. If you want bt1-like behavior, make piece size 4 megs and a 2048-ary tree. The total tree is about 40 kilobytes, or in other words: nothing. > let's forget for a second about overhead BT creates. The faster peers > learn who has what the better overall performance is going to be. Yeah, and the faster they can share what they got, the better for all of bt. On the other hand, for an 8 gig file, 4 megs are pretty small... Theres no "true" answer. The tree is there to get rid of the long piece_hash list, and a means to get rid of the .torrent file at all. We would have to do experiments what works and what is important. > Loosely related issue. Let me doubt the reasons behind choosing of > bencoding format, instead of compressed XML or JASON if are looking > for something less "bloated". I think it was a simple choise, because > it was ready to use in Phyton. or i am wrong ? Let's save one day of > coding and think about the cost later. Where do you get the idea that bencoding was "already there" with python? I cannot find a single reference about beconding history and almost every description I found mentioned bittorrent. I conclude that bencoding was made for bt, but I am not sure. > The cost though is not marginal, far from it. Overhead of the protocol > is a linear function of a number of sent packets which, because of > small block size, is a linear fucntion of the file size. i think that > in reality the function is stronger than linear, because in the > situation where we have a large file with only one seed and large > swarm most of the traffic generated BT clients agressively looking for > the blocks. I suppose you're talking about have lists, again. Yes, with very small blocks and binary trees, the huge number of 512k for a bitfield of an 8 g file with 4 k pieces makes it impractical if we dont use some kind of mechanism to ease the pain. > Let's be honest. BT is created for 0.5-1G files and for the network of > multiple hosting servers (seeds) interconnected with fast links. 10G+ > files is not exactly the BT "market". But it works, and works fine, if you tune the piece size accordingly. > And what about lossless video codecs ? 24 frames/s * 1024 * 1280 * 60 > * 60 gives us 100G/hour. with 1:4 compression 25GB/hour. Two hour > video clip is 50G. are we going to use 4KB blocks for this kind of > files too. and calculate hash tree using mainframe ? Nobody ever said 4k was fixed. It always was the smallest number that isnt outright ridiculous. But no matter the piece size, if you treat it as a constant and increase the file size, the tree size grows by the same factor.


LinkBack URL
About LinkBacks
Reply With Quote
Although a lot of the technical aspects go over my head, I'm interested in learning more about Rodi and I'm sure a lot of others are as well. 

Bookmarks