Re: Re: BitTorrent for input file staging on clusters?

>> <>(1) "Connect only from IP's" isn't worthwhile, IMO; no one can 
>> download  without the torrent, and if you block the tracker's 
>> infopage, they can't even try unless they guess the hash value.
>
>
>This is more of a (paranoid) policy thing...I want to make sure I have
>some ground to stand on when my sysadmin says "your running what,
>where?" I'm not so concerned about someone "stealing" the data via BT,
>but of someone exploiting a bug in the tracker or client to break into
>the machine. Of course, given that the incoming IP address can be
>spoofed, it is not clear I've done anything useful.
>  
>

One of the reasons Python is used is because of the dynamic memory 
allocation, which makes buffer-overrun exploits pretty much impossible.  
There is no code for manipulating the machine in the client or tracker, 
which means there's nothing to "break into" with.  If you disable the 
infopage and the scrape functionality there's no way to read info hashes 
from the tracker, and you need the info hash to connect to a tracker or 
peer.  An info hash is a 20-byte SHA1 hash, so good luck guessing.  If 
someone is sniffing your connection they could theoretically grab your 
info hash, but if someone is sniffing your connection you've already got 
serious problems.

>> <>(2) In future versions of the official release, the torrent 
>> directory will be reparsed so frequently that forcing a refresh isn't 
>> worthwhile.  (BitTornado does this now.)
>
>
>I nearly went with that approach, but since the current client
>re-parses the allowed directory entirely, I was worried about bogging
>down the tracker. Are the URL's the tracker responds to an official
>part of the spec? If so, it'd be a big deal to introduce a new
>"keyword" and I guess polling would be the way to go.
>  
>

The old version re-parsed every torrent file when it re-parsed the 
directory; mine checks file sizes and modification times and only 
re-parses changed files, which requires very little overhead.

>>(3) Unescaping URLs for the tracker is problematic, since the info hash 
>>and peer ID may contain those characters.  I recommend coding your 
>>script properly from the start.
>>    
>>
>
>Ah. I wondered why it was being done this way. That explains another
>bug I had to fix...that I guess I introduced with this
>change...probably. My fix for the bug I introduced was to use b2a_hex
>and a2b_hex to encode the info_hash and peer ID, which "looks nicer"
>in the URL anyway and is consistent with the other places the hash
>appears (btshowmetainfo, infopage). 
>
>Thanks for your comments, especially the last one...which explains a
>considerable amound of recent hair-pulling. :-)
>  
>

NP.  :-)~



------------------------ 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/