[bittorrent] Introductory/endgame algorithms

Jari Sundell sundell.software at gmail.com
Fri Sep 30 11:37:38 EDT 2005


On 9/30/05, Elliott Mitchell <ehem at m5p.com> wrote:
>
> I'm well aware of that fact. Though you can still do page-sized I/O
> aligned to the file, though not well aligned to the torrent (yuck).
>
> This is definitely something that should be considered in any V2 protocol
> designs.


There's no need for this kind of extension, nor is it desirable in a
protocol. If you want to do zero-copy IO from a file to a socket, look at
sendfile. It does not require any alignment.

I was sticking to protocol terminology since that is the common frame of
> reference for this mailing list. /If/ I'm reading your meaning correctly
> I can see why it would help. Has the benefit of limiting the performance
> degradation on those clients from randomized I/O.


"'piece' messages contain an index, begin, and piece.", the protocol
specification uses the word in an ambiguous way.

> I must still mention that the second is a bad idea since you're
> decreasing performance on your high speed peers. With your kind of
> bandwidth an RTT of 0.05s can result in a very high BDP.


I have a dynamic queue size, maxed out at 200 pieces. Halving that will
still put me above ~4 sec RTT in average.

Wrong. If your buffer is page-aligned and you're doing I/O to
> page-aligned portions of a file, Linux will do a copy but by modifying
> the page table. I'm less certain of FreeBSD doing the same, but I think
> it does. If you're not doing large blocks I/O this isn't convenient, and
> not all OSes will do the copy via page table.


Looking at some DMA documentation it seems to take an offset, in addition
the starting address which is aligned. So being page aligned should not be a
requirement for doing zero-copy transfer.

Hmm, seems you've got better knowledge of what it can do than I do.
> Perhaps (hmm, make that likely) better performance on many systems, but
> on some OSes with the right preparation they're equivalent.


Not equivalent to any of the clients I've looked at. They all seem to build
a copy of the file data in heap memory, which does make them less efficient
than just mmap'ing that data. Both due to the copy in itself and the
duplicate of that data that exists in disk cache.

> http://libtorrent.rakshasa.no/
>
> Unfortunately two issues here. First, http://libtorrent.sourceforge.net/,
> there is already a library of the same name out there. Second, despite
> claims to the contrary, the world is not ruled by C++, quite a few new
> things are written in C. Just because you're using C, doesn't mean you
> aren't doing OO (sorry, rant time there).
>

The naming issue, yeah... I've noticed. There's really not that many
permutations of "lib" and "BitTorrent", but i'd rather not discuss this
issue here.

C vs C++; the standards share a common base. I choose C++ because that is
what i know best, and it is efficient and easy to modify. Also i love
template's. If you prefer C then a wrapper library could be used.

--
Rakshasa

Nyaa?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20050930/ea4ecf2a/attachment.html 


More information about the BitTorrent mailing list