[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: final release - p2p or mirrors

Chris Kloiber wrote:
On Mon, 2004-05-17 at 10:26, Jim Cornette wrote:

Chris Kloiber wrote:

On Sun, 2004-05-16 at 05:33, Jim Cornette wrote:

I was thinking in reference to someone posting about a high fragmentation level on a bittorrent acquired iso. I was also thinking that bittorrent used bits and pieces of files available. I never thought about tcp/ip delivering packets. I assumed that the files on mirrors would be streamed consecutively. (keeps stream of data first to last on file being downloaded.)

This can be overcome in most BT clients by pre-allocating the space for
the download at the beginning.

Would this be like a partition with no prior data installed? A partition previously formatted and mounted to a specified point. Say, for example /mnt/bittorrent?

Having a low fragmentation level would be desirable goal for a to be created CD set.

No, this is when having bittorrent read teh .torrent file, determine the
final size of the download, then dd if=/dev/zero of=filename
bs=<file_size>. Then as the pieces arrive they get written to the
correct position within the already existing file, resulting in almost
no fragmentation.

This sounds like the best approach for retrieving the file. Throwing it in a pre-allocated location that mirrors the original files location.

I was wondering if a CDROM created from a fragmented retrieval would hunt all over the place for bits and pieces of files. Those motors of hunting operations from CDROMs can be quite noisy.

Having a pool of computers grabbing some info from one user and some more bits from another source, then another source seems a little too open for foul play.

Not a problem, each piece is hashed and checked. Anyone feeding you more
than a few bad chunks (accidents do happen) gets banned (and you accept
no more from them). Only possibility I can see for foul play is if the
original seed was a trojan. And that can be checked for with public
md5sums, which already exist. (Ie: Downloading things from suprnova.org
is potentially hazardous, especially to Windows systems.)

Thanks for pointing out the safegaurds setup for a transfer of this type. Would the unmatching chunks be discarded or would the bittorrent process be interrupted? Either way, the bittorrent does not sound as risky as it once did. I still prefer ftp transfers from familiar mirrors. This is mainly because with bittorrent, you have to learn how to open ports for the torrent, people are pulling bits from my machine, I am pulling bits from machines that are unfamiliar to me.

Pieces with bad hashes are discarded, I believe they never make it to
the disk. Most clients I have seen will let you know about it, but
continue as if nothing happened.

Thanks for the explanation.

With ftp transferring, I get fairly decent rates. I can use a simple GUI ftp program that does not take a lot of time configuring.

End point, http, ftp, bittorrent transfers or whatever other method of retrieval of information should exist. One method should not be discontinued just because some think that one method is the "in thing", "the advancement of software at it's best".

Thanks for calming my fears with bittorrent transfers and pointing out ways to get a less fragmented image and keep security levels high.


You should give it a try at least once. I recommend you wait for the
official bittorrents from Duke University, or from Univerzita Karlova,
don't try suprnova.org as that one really sounds fishy to me, especially
since they list the DVD iso size at just over 2Gig, and by VPNing into
work I see a 4Gig DVD iso.

The 2Gig size sounds to me like a DVD image made by my FedoraSync.sh
script, which means no SRPMS. If that's all it is, well it's not
official but not harmful. But I can't tell that for sure.

I'll give it a shot. Has this been tried with SELinux enabled. :.)


Good day to deal with people in high places; particularly lonely stewardesses.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]