final release - p2p or mirrors

[Jim Cornette]

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.
>>
>>Jim
> 
> 
> 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. :.)

Jim


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