[00:15:50] *** _rafi_ has quit IRC
[01:04:40] *** GTHKn has quit IRC
[01:07:06] *** GTHK has joined #bittorrent
[02:08:21] *** Switeck has joined #bittorrent
[02:29:55] *** A9 has quit IRC
[02:29:55] *** jnpplf has quit IRC
[02:29:56] *** mpl has quit IRC
[02:29:56] *** erdgeist has quit IRC
[02:29:56] *** Nolar has quit IRC
[02:29:57] *** Firon_ has quit IRC
[02:29:57] *** cgreco has quit IRC
[02:29:58] *** lioux has quit IRC
[02:29:58] *** void^ has quit IRC
[02:29:59] *** alus has quit IRC
[02:29:59] *** BitTorrentBot has quit IRC
[02:29:59] *** charles has quit IRC
[02:29:59] *** tris has quit IRC
[02:30:00] *** init0_ has quit IRC
[02:30:00] *** Harold_parker has quit IRC
[02:30:00] *** BentMyWookie has quit IRC
[02:30:00] *** Gottaname has quit IRC
[02:30:01] *** swolchok has quit IRC
[02:30:01] *** DeHackEd has quit IRC
[02:30:01] *** hlindhe has quit IRC
[02:30:01] *** chalcedony has quit IRC
[02:30:02] *** rrr_ has quit IRC
[02:30:02] *** GTHK has quit IRC
[02:30:03] *** ProperNoun has quit IRC
[02:30:03] *** gui7 has quit IRC
[02:30:04] *** MassaRoddel has quit IRC
[02:30:04] *** ivan` has quit IRC
[02:30:05] *** stalled has quit IRC
[02:30:05] *** nks has quit IRC
[02:30:05] *** TheSHAD0W has quit IRC
[02:30:05] *** kjetilho has quit IRC
[02:30:05] *** foomor has quit IRC
[02:30:05] *** Nakor has quit IRC
[02:30:05] *** ahath has quit IRC
[02:30:06] *** Switeck has quit IRC
[02:30:07] *** ajaya has quit IRC
[02:30:07] *** dandon has quit IRC
[02:30:07] *** hydri has quit IRC
[02:30:07] *** swinokur has quit IRC
[02:30:08] *** uau has quit IRC
[02:30:09] *** Astro has quit IRC
[02:30:09] *** mxs has quit IRC
[02:30:09] *** The_8472 has quit IRC
[02:30:09] *** andar has quit IRC
[02:30:09] *** uriel has quit IRC
[02:30:09] *** K`Tetch has quit IRC
[02:30:10] *** hlindhe_ has quit IRC
[02:30:11] *** Mazon has quit IRC
[02:31:14] *** alienvenom has quit IRC
[02:31:21] *** alienvenom has joined #bittorrent
[02:34:40] *** bt42 has quit IRC
[02:52:35] *** bittwist has joined #bittorrent
[02:52:35] *** alienvenom has joined #bittorrent
[02:52:35] *** Switeck has joined #bittorrent
[02:52:35] *** GTHK has joined #bittorrent
[02:52:35] *** ajaya has joined #bittorrent
[02:52:35] *** init0_ has joined #bittorrent
[02:52:35] *** lioux has joined #bittorrent
[02:52:35] *** dandon has joined #bittorrent
[02:52:35] *** hydri has joined #bittorrent
[02:52:35] *** ProperNoun has joined #bittorrent
[02:52:35] *** The_8472 has joined #bittorrent
[02:52:35] *** MassaRoddel has joined #bittorrent
[02:52:35] *** ivan` has joined #bittorrent
[02:52:35] *** void^ has joined #bittorrent
[02:52:35] *** Harold_parker has joined #bittorrent
[02:52:35] *** gui7 has joined #bittorrent
[02:52:35] *** swinokur has joined #bittorrent
[02:52:35] *** rrr_ has joined #bittorrent
[02:52:35] *** andar has joined #bittorrent
[02:52:35] *** BentMyWookie has joined #bittorrent
[02:52:35] *** Gottaname has joined #bittorrent
[02:52:35] *** A9 has joined #bittorrent
[02:52:35] *** uriel has joined #bittorrent
[02:52:35] *** stalled has joined #bittorrent
[02:52:35] *** K`Tetch has joined #bittorrent
[02:52:35] *** erdgeist has joined #bittorrent
[02:52:35] *** jnpplf has joined #bittorrent
[02:52:35] *** Nolar has joined #bittorrent
[02:52:35] *** mpl has joined #bittorrent
[02:52:35] *** Firon_ has joined #bittorrent
[02:52:35] *** nks has joined #bittorrent
[02:52:35] *** Mazon has joined #bittorrent
[02:52:35] *** foomor has joined #bittorrent
[02:52:35] *** cgreco has joined #bittorrent
[02:52:35] *** kjetilho has joined #bittorrent
[02:52:35] *** mxs has joined #bittorrent
[02:52:35] *** swolchok has joined #bittorrent
[02:52:35] *** DeHackEd has joined #bittorrent
[02:52:35] *** hlindhe has joined #bittorrent
[02:52:35] *** BitTorrentBot has joined #bittorrent
[02:52:35] *** charles has joined #bittorrent
[02:52:35] *** alus has joined #bittorrent
[02:52:35] *** tris has joined #bittorrent
[02:52:35] *** chalcedony has joined #bittorrent
[02:52:35] *** hlindhe_ has joined #bittorrent
[02:52:35] *** ahath has joined #bittorrent
[02:52:35] *** uau has joined #bittorrent
[02:52:35] *** Astro has joined #bittorrent
[02:52:35] *** TheSHAD0W has joined #bittorrent
[02:52:35] *** Nakor has joined #bittorrent
[03:15:33] *** alienvenom has quit IRC
[03:15:39] *** alienvenom has joined #bittorrent
[04:07:02] *** The_8472 has quit IRC
[04:07:23] *** wadim has joined #bittorrent
[04:07:25] *** wadim is now known as The_8472
[04:15:36] *** A9 is now known as A9[idle]
[05:00:05] *** The_8472 has quit IRC
[05:33:39] *** chelz has joined #bittorrent
[05:40:32] <chelz> would there generally be any noticeable difference between two torrents and the performance of their swarm if they're each for the same four 1 GiB files, 4 GiB total, but one has a piece size of 4 MiB and the other 8 MiB?
[05:40:48] <Switeck> yes
[05:41:06] <Switeck> if the torrent is public and most of the participants are 'average' ADSL and cable modems.
[05:41:10] <TheSHAD0W> Piece sizes over 512K reduce the torrent performance.
[05:41:27] <chelz> TheSHAD0W: no matter what size the files are in the torrent?
[05:41:31] <alus> although that will be fixed soon!
[05:41:34] <TheSHAD0W> Correct.
[05:41:40] <TheSHAD0W> alus: Eh?
[05:41:41] <chelz> why is that?
[05:41:49] <alus> it's a problem with the choker intervals
[05:41:55] <Switeck> chelz, average upload speed of peers/seeds
[05:42:01] <TheSHAD0W> alus: I disagree.
[05:42:05] <chelz> is it based on the ideal amount of pieces? since i've seen torrents opt for going with 1.5k pieces instead of 3k at times
[05:42:05] <Switeck> How long does it take them to upload 1 whole piece?
[05:42:09] <alus> TheSHAD0W: why do you think it is?
[05:42:23] <TheSHAD0W> It's because peers just take longer to complete pieces and re-share them.
[05:42:25] <chelz> Switeck: can't parts of pieces be gotten from multiple peers?
[05:42:32] <alus> TheSHAD0W: but why would that matter?
[05:42:43] <Switeck> chelz, yes and no
[05:42:50] <TheSHAD0W> It reduces interest from other peers.
[05:42:52] <alus> TheSHAD0W: that would mean that every piece size increase would be proportially worse, right?
[05:42:55] <Switeck> yes multiple peers can feed you, no...not all will.
[05:43:04] <TheSHAD0W> I've found reduced upload utilization.
[05:43:14] <TheSHAD0W> Yes, it gets much worse, fast.
[05:43:19] <chelz> oh, so just for getting lots of peers to connect it's good to have a high piece count?
[05:43:36] <Switeck> peers connect without ANY basis of piece count
[05:43:42] <alus> TheSHAD0W: and have you tried increasing the choker intervals for all peers involved?
[05:43:49] <TheSHAD0W> Yes, my client does that.
[05:43:57] <TheSHAD0W> Especially for seeding.
[05:44:00] <alus> well, you have to do it for everyone
[05:44:15] <TheSHAD0W> It still causes problems.
[05:44:20] <alus> why?
[05:44:31] <TheSHAD0W> I already told you.
[05:45:01] <alus> reduced interest shouldn't matter because they still have lots of downloading to do
[05:45:18] <TheSHAD0W> But they don't download from as many people, because they don't have the pieces.
[05:45:23] <alus> you aren't annoucing new haves because you're not done. they shouldn't care because they're not done either
[05:45:35] <Switeck> chelz, a slow single seed can cause feast-or-famine conditions. The time to complete a single piece from the peers is much quicker than the seed uploads, so much of the time the download speed is 0.
[05:45:55] <TheSHAD0W> alus: It's still IMO silly to increase piece size to such a large amount.
[05:45:59] <alus> yes, it takes extra time for a new peer to join the network, but that should be a constant on the front
[05:46:15] <alus> once they have pieces, they should participate in the same slow have announcing that you're doing
[05:46:17] <TheSHAD0W> Just to reduce the size of the metafile.
[05:46:34] <alus> the only illiquid part is the choker interval
[05:46:38] <alus> and like, RTT
[05:46:42] <Switeck> It is also somewhat silly to have a 32 KB piece size on 4+ GB torrents IMO.
[05:46:50] <chelz> hm so i'm not really understanding how piece size would affect speeds if parts of pieces can come from multiple peers and the piece count doesn't affecting connecting. perhaps if a client is downloading a piece, it is unlikely to get other peers for that piece because the client doesn't request it? or announces that it's downloading it so peers don't offer / try to connect ?
[05:46:52] <TheSHAD0W> If we're going to magnet-style links, reducing the size of the metafile isn't at all important anyway.
[05:47:05] <alus> TheSHAD0W: agreed!
[05:47:15] <TheSHAD0W> 32KB is too small.
[05:47:18] <alus> they already swarm download the metafile, so it doesn't matter!
[05:47:21] <TheSHAD0W> 512K is better.
[05:48:01] <TheSHAD0W> I use a 32K piece size for torrent downloads for my own client BTW...
[05:48:10] <TheSHAD0W> The download is only 4MB.  ;-)
[05:48:23] <alus> haha
[05:48:31] <alus> we thought about torrenting uT for updates
[05:48:35] <alus> then we laughed
[05:48:42] <TheSHAD0W> People kept asking me for a torrent, so I made one.
[05:48:58] <TheSHAD0W> And then I had people downloading the torrent and saying, "so how do I install this?"
[05:49:00] * TheSHAD0W facepalms
[05:49:17] <alus> yes, you zipped the unzip.exe
[05:49:23] <alus> savings!
[05:50:07] <alus> TheSHAD0W: you could make an NSIS installer which uses DNA to download BitTornado
[05:50:48] <alus> heck, I could make one. all it needs is the URL to BitTornado
[05:51:28] <TheSHAD0W> Hehe.
[05:51:42] <chelz> that's an interesting idea
[05:51:53] <TheSHAD0W> alus:
[05:51:54] <TheSHAD0W> http://tracker.degreez.net/
[05:52:26] <alus> http://dnagen.bittorrent.com/bdg/get?url=http%3A%2F%2Fdownload.bittornado.com%2Fdownload%2FBitTornado-0.3.17-w32install.exe
[05:52:32] <alus> :)
[05:52:42] <TheSHAD0W> LOL
[05:52:53] <TheSHAD0W> What I really need to do...
[05:53:04] <TheSHAD0W> Is redo the libtorrent library and reimplement it.
[05:53:16] <TheSHAD0W> Ain't gonna happen though.  I'm too busy.
[05:55:23] <TheSHAD0W> Python is cool, especially for experimenting, but...
[05:56:00] <TheSHAD0W> IMO we really need a good, solid BT library, something that software companies can embed.
[05:57:41] <TheSHAD0W> You know...
[05:58:45] <TheSHAD0W> If we're moving to a magnet-only system, it'd be possible to extend the metafile protocol to include hash-tree-based alternatives.
[05:59:06] <TheSHAD0W> Which would solve a few problems simultaneously.
[05:59:20] <chelz> what sort of problems?
[05:59:41] <TheSHAD0W> Reduce the piece size, reduce the amount of download needed to recover from hash fails...
[06:00:49] <hydri> TheSHAD0W: http://www.bittorrent.org/beps/bep_0030.html
[06:02:05] <Switeck> hash fails are fortunately not the severe issue they once were due to faster lines and better "spot the poisoner" logic XD
[06:02:38] <TheSHAD0W> True, but it still happens.
[06:02:55] <TheSHAD0W> Why is it incompatible with the http seeding extensions?
[06:03:16] <hydri> TheSHAD0W: because the http server won't send you the "uncle" hashes
[06:03:24] <hydri> so you can
[06:03:30] <hydri> 't verify them as you receive them
[06:03:44] <TheSHAD0W> Yeah.  Could be solved by having a conventional seeder in there as well as http.
[06:03:55] <hydri> yep
[06:04:16] <TheSHAD0W> The script-based http seeder can also be modified to return merkle tree data.
[06:05:03] <hydri> TheSHAD0W: speaking of which.. When I implemented support for script-based http seeds in libtorrent, I was wondering.. is the range you specify to the seed inclusive or exclusive?
[06:05:14] <TheSHAD0W> Pardon?
[06:05:25] <hydri> TheSHAD0W: I believe the docs are not explicit on that point, and being http, it could be inclusive
[06:05:39] <hydri> TheSHAD0W: there is a start and end offset, right?
[06:05:47] <TheSHAD0W> It mirrors http's standard range specification.
[06:05:55] <TheSHAD0W> http://bittornado.com/docs/webseed-spec.txt
[06:06:02] * hydri looks up code
[06:06:20] <TheSHAD0W> One example given uses "&ranges=49152-131071,180224-262143
[06:06:24] <TheSHAD0W> "
[06:06:36] <hydri> ok, so, inclusive then.. the first byte would be 1-1
[06:06:52] <TheSHAD0W> 0-0, I think.
[06:07:02] <hydri> oh, right
[06:08:19] <TheSHAD0W> The script ought to also support the http range header, as well as the url option...
[06:08:21] <TheSHAD0W> But, eh.
[06:09:30] <hydri> my current implementation assumes the end of the range is one passed the end.. and I believe it worked with the scripts..
[06:09:47] <hydri> but the example values definitely suggest that it's supposed to be the last byte
[06:10:04] <TheSHAD0W> Hum.
[06:10:13] <TheSHAD0W> Let me check out the webseed script...
[06:11:32] <TheSHAD0W> 		$myxmit .= substr($xmit, $start, $stop-$start+1);
[06:12:43] <TheSHAD0W> That cuts a range out of the piece based on what's specified in the url...
[06:12:47] <TheSHAD0W> Is that correct?
[06:13:55] <hydri> yeah, that looks right
[06:14:00] <hydri> I'll fix my code then
[06:14:29] *** grinder has joined #bittorrent
[06:15:19] <grinder> it is true, isn't it, that thepiratebay.org has been bought up by some company?
[06:16:30] <grinder> hi
[06:16:50] <TheSHAD0W> Some shady company tried it but didn't follow through.
[06:17:14] <grinder> why is thepiratebay now based in germany?
[06:17:49] <TheSHAD0W> I unno.
[06:18:08] <chelz> grinder: #thepiratebay on EFnet might fit more what you're looking for
[06:18:20] <grinder> chelz: thanks a lot
[06:19:38] <grinder> chelz: there was no one there
[06:20:56] *** MassaRoddel has quit IRC
[06:21:12] <chelz> grinder: #thepiratebay.org
[06:21:13] <chelz> rather
[06:29:35] <grinder> TheSHAD0W: so you would say using ipredator would be safe?
[06:30:10] <TheSHAD0W> Not familiar with it.
[06:30:35] <chelz> i'd say it was safe in terms of copyright laws in most countries
[06:30:42] <TheSHAD0W> Depending on how it was designed, it would be relatively safe assuming the ISPs weren't co-opted.
[06:30:51] <chelz> but not for anything srsly illegal
[06:32:01] <TheSHAD0W> Don't take my word for it though.  I really don't know how it works.
[06:32:19] <grinder> ick. its pptp
[06:32:29] <grinder> :p
[06:32:38] <grinder> didnt realize that
[06:32:50] <TheSHAD0W> That would be safe.  ISPs would know you were connecting to the site, but not what you were transferring.
[06:33:41] <chelz> pptp is nice an universal from what i read about it
[06:33:49] <grinder> a good cracker could crack that in a couple of weeks
[06:34:39] <grinder> thats a long time lol
[06:36:04] <grinder> but i still like top quality
[06:38:19] <TheSHAD0W> You have to remember that the IP kops can't currently tap into internet connections.  They can traipse through a p2p network, but if you're proxied...
[06:40:04] <TheSHAD0W> Even an unencrypted proxy would give you protection, so long as no one is monitoring the link and they can't serve the proxy with a subpoena.
[06:40:38] <TheSHAD0W> (And the proxy doesn't belong to the bad guys.)
[06:42:18] <Switeck> and there is malware now that uses p2p networks
[06:44:12] <grinder> TheSHAD0W: i like vpns for more than just unthrottled p2p
[06:52:46] <chelz> TheSHAD0W: haven't you heard about those secret filtering rooms in ATT isp centers?
[06:53:20] <TheSHAD0W> chelz: They can't use that info to prosecute file traders; if they did, those rooms wouldn't be secret any more.
[06:53:26] <Switeck> They're logging connections more than content
[06:53:34] <TheSHAD0W> NSA doesn't care about MP3s or AVIs, anyway.
[06:55:15] <chelz> eh yeah but he mentioned a cracker so i'm assuming there's some adversary targeting a user
[06:56:07] <grinder> chelz: adversary?
[06:56:59] <grinder> chelz: what are you saying?
[06:57:00] <chelz> or 'attacker', whatever you like to call a hypothetical person trying to break a security system
[06:57:26] <chelz> no point in security if no one is going to try to break it n all
[06:57:38] <grinder> just hackers
[06:58:26] <Switeck> So an AVI or MP3 file sent via p2p in a password-locked RAR file...or something slightly more obscure like 7Zip...isn't going to get read.
[06:58:38] <grinder> vpns are multi-purpose, not just for file sharing
[06:58:52] <chelz> well i prefer the traditional definition of "hacker"
[07:04:39] <grinder> look im not trying to be rude when i repeat my self here
[07:04:42] <grinder> vpns are multi-purpose, not just for file sharing
[07:05:00] <grinder> that means that other data needs security too
[07:39:57] *** GTHK has quit IRC
[07:43:34] *** ivan` has quit IRC
[07:43:45] *** ivan` has joined #bittorrent
[07:44:49] *** ivan` has quit IRC
[07:45:00] *** ivan` has joined #bittorrent
[07:46:01] *** MassaRoddel has joined #bittorrent
[07:46:44] *** ivan` has quit IRC
[07:46:55] *** ivan` has joined #bittorrent
[07:47:31] *** ivan` has quit IRC
[07:47:43] *** ivan` has joined #bittorrent
[08:06:20] *** rrr_ has quit IRC
[08:12:46] *** grinder has quit IRC
[08:33:59] *** Nolar has quit IRC
[08:34:09] *** Nolar has joined #bittorrent
[08:40:12] *** rrr_ has joined #bittorrent
[09:07:45] *** Nolar has quit IRC
[09:12:58] *** Nolar has joined #bittorrent
[09:59:08] <mpl> chelz: pptp sucks. I wish the ipredator/relakks guys provided something openvpn style.
[10:01:02] <chelz> why?
[10:01:18] <chelz> i'm curious what openvpn does that pptp doesn't
[10:01:25] <chelz> besides that pptp security issue
[10:02:11] *** ajaya has quit IRC
[10:03:24] <mpl> chelz: for one thing it's easier to configure
[10:04:10] <chelz> are there any feature differences?
[10:04:13] <chelz> maybe performance
[10:04:22] <mpl> and pki is more secure than pass-based stuff,
[10:04:57] *** HandheldPenguin` is now known as HandheldPenguin
[10:05:01] <mpl> appart from the ovbious problem of securely transmitting the key the first time.
[10:06:31] <mpl> well also I'm biaised because I already knew openvpn and it annoyed me that I didn't have the choice but to use pptp for that.
[10:08:17] <mpl> chelz: dunno about perf; there might be a bit more overhead with openvpn, but once the connection is established I don't think there is that much a diff between the two in terms of b/w usage or load.
[10:09:15] <chelz> ah
[10:09:39] <mpl> chelz: anyway, I'm whining but I eventually got it up and running and I've been using it happily ever since.
[10:10:01] <chelz> that's good :)
[10:10:18] <chelz> actually i haven't read into methods of assuring the pubkey you've received is legitimate. there might be some cryptomagic i'm overlooking but it seems to me that there might need to be some initial trusted third party
[10:11:35] <mpl> chelz: well, if they set up some https form where you can just cp and paste the pubkey from, I'd be pretty ok with that. you just have to check the cert of the https session and make sure it does belong to whoever you're trading with.
[10:12:04] <chelz> yeah, the certs being shipped with your browser being the trusted third party
[10:12:18] <mpl> in that case the third party would be the CA authority
[10:12:20] <mpl> yep
[10:12:32] <mpl> but that's always the case with https
[10:14:12] <chelz> yeah
[10:14:32] <chelz> does relakks and ipredator supply their pubkeys through https?
[10:15:04] <mpl> uh? there's no pubkey, it's pass based.
[10:15:36] <chelz> oh, uh oh
[10:15:39] <chelz> that's vulnerable then
[10:15:55] <chelz> i was hoping they were using eap-tls
[10:16:09] <mpl> hmm wait
[10:16:49] <mpl> you authenticate with a pass, but I'm not sure you have a mean of authenticating them indeed.
[10:17:04] *** kwinz2 has quit IRC
[10:19:01] <mpl> at least in my config, I have noauth set, and it's using mschap-v2
[10:19:56] <mpl> there might be a way to make it more secure but I'm pretty sure they don't give out pubkeys.
[10:19:59] <chelz> http://en.wikipedia.org/wiki/Pptp#Security_of_the_PPTP_protocol
[10:20:06] <chelz> is what i'm going off of
[10:20:08] <chelz> might be wrong
[10:20:18] <chelz> but it seems like from that only using 'eap-tls' is unbroken so far
[10:21:00] *** kwinz2 has joined #bittorrent
[10:21:19] <mpl> yeah eap-tls == pki, so it would look more like openvpn with thaut.
[10:21:24] <mpl> *that
[10:27:46] *** edigaryev has joined #bittorrent
[10:30:37] <mpl> chelz: I think there are a few vpn services out there who support pki based auth, but I wouldn't trust the ppl behind those services as much as I trust the ipredator/relakks ppl to not give out connections info.
[10:31:28] *** Harold_parker has quit IRC
[10:32:42] <chelz> yeah
[10:32:48] <chelz> logging is my top concern
[10:35:43] *** Elrohir has joined #bittorrent
[10:49:21] *** Harold_parker has joined #bittorrent
[10:57:03] *** cyb2063 has joined #bittorrent
[12:02:22] *** goussx has quit IRC
[12:11:47] *** Elrohir has quit IRC
[12:16:19] *** _rafi_ has joined #bittorrent
[12:22:12] *** Waldorf has joined #bittorrent
[12:24:46] *** edigaryev has quit IRC
[12:25:01] *** edigaryev has joined #bittorrent
[12:27:08] *** edigaryev has left #bittorrent
[12:27:28] *** edigaryev has joined #bittorrent
[12:37:53] *** ivan` has quit IRC
[12:38:24] *** ivan` has joined #bittorrent
[12:43:40] *** cyb2063 has quit IRC
[12:50:59] *** medecau has joined #bittorrent
[13:35:40] *** kwinz2 has quit IRC
[13:36:21] <chelz> two things, and i'll probably bring them up later too but; is there any discussion or work on: standardizing onto one DHT across all bittorrent clients? and combining torrent swarms, perhaps by having a manageable per-file hash?
[13:41:33] <chelz> also apparently there are some RSS feed horror stories. if anyone has any i'm interesting in hearing them.
[14:09:50] *** HandheldPenguin is now known as HandheldPenguin`
[14:11:21] *** ania has joined #bittorrent
[14:18:24] *** kwinz2 has joined #bittorrent
[14:19:51] <DWKnight> the big thing with rss is that there's no hard standard used across everybody
[14:20:11] <DWKnight> there are enough differences between different feeds for the most part that it's difficult to maintain compatibility
[14:22:08] <DWKnight> AZ/Vuze has a plugin that supports the mainline DHT, effectively bridging the two with enough user base having it active
[14:23:14] <DWKnight> combining torrent swarms by per-file hashes is difficult, but not impossible. The big thing is getting per-file hashes into torrents in the first place
[14:23:50] <Switeck> thanks :)
[14:25:02] <DWKnight> for covering everything at once?
[14:25:07] <chelz> the first step with per-file hashes is getting support for them in clients so torrents get made with them.
[14:25:25] <chelz> well a bep rather even
[14:25:48] <chelz> has it been brought up in serious bep-released discussion?
[14:26:02] <DWKnight> not that I know of
[14:27:03] <chelz> interesting
[14:27:27] <chelz> well people must have heard about BitComet's partial file fiasco that probably gave the concept a bad rap
[14:27:51] *** kwinz2 has quit IRC
[14:27:53] <DWKnight> it was a poorly thought out kludge that didn't address the issue
[14:28:39] <Switeck> even changing piece size makes currently identifying files by hash worse.
[14:28:45] <chelz> well Switeck had the idea of if zero-length padding files are necessary for whatever reason, they could be virtual and never actually created
[14:29:21] <DWKnight> given the extendability of the .torrent format, they aren't necessary
[14:29:25] <Switeck> that's only in concept...basically every file's end is the end of a piece
[14:29:33] <DWKnight> http://wiki.depthstrike.com/index.php/P2P:Protocol:Specifications:Optional_Hashes
[14:29:37] <chelz> oh, that's good
[14:29:37] <Switeck> or at least for files larger than piece size
[14:29:50] <chelz> there could be a standard formula drawn up to handle mandatory piece sizes for any amount of data
[14:30:16] <Switeck> problem is, piece size is forced to somewhat scale by how large your torrent is overall.
[14:30:19] <DWKnight> or maybe handle things like was put in for stuff like shareaza
[14:30:59] <chelz> how does shareaza handle things?
[14:31:12] <DWKnight> secondary hash information put in per-file
[14:31:48] * DWKnight points at his last link
[14:31:59] <chelz> ah
[14:32:03] <chelz> yeah, i was thinking about that. but depending on the hash size it might use up more data than people want with that.
[14:32:26] <chelz> maybe corners could be cut by generating a normal hash but only storing part of it
[14:32:39] <DWKnight> TTH pretty much covers any scenario you'd actually need
[14:32:43] <chelz> but only if that's necessary. say in cases of many, many small files
[14:32:47] <chelz> oh
[14:32:59] <DWKnight> because it does segmented hashing with piece sizes that auto-scale
[14:33:15] <chelz> that's very cool
[14:33:43] <DWKnight> and the output hash you get at the end is always the same
[14:33:47] <DWKnight> regardless of file size
[14:34:16] <DWKnight> kind of like the merkle tree hashing that was proposed a couple years ago
[14:34:20] <chelz> what do you think of adding in some kind of support into tracker software to automatically share peers between swarms with the same files? or what, if not the tracker, would be a good thing for combining swarms?
[14:34:29] <DWKnight> except with tiger as the hashing algorithm instead of sha1
[14:34:49] *** kwinz2 has joined #bittorrent
[14:34:51] <DWKnight> the tracker really can't combine swarms with different infohashes
[14:36:05] <DWKnight> I keep going back to it because it's the only thing I see actually trying to do things right, but shareaza would, in a multi-file torrent where it knew per-file hashes, search its other networks for those individual files
[14:36:46] <chelz> it's overhead, but in the interest of combining swarms: if the tracker knows about the per-hashes of files, it could associate the relevant infohashes together
[14:36:55] <DWKnight> not easily
[14:37:23] <chelz> how else though, barring doing shareaza's method of searching p2p networks?
[14:37:23] <DWKnight> clients would have problems with that because of how they handle connection negotiation
[14:37:38] <DWKnight> DHT with the per-file hashes is about it
[14:38:17] <chelz> ah i was just about to say how i'm not sure how one would associate infohashes with the DHT acting as a tracker
[14:38:25] <chelz> that's an interesting setup
[14:39:12] <chelz> i would imagine if swarm-combining-functionality was added to trackers, clients would have to have some modifications
[14:39:37] <DWKnight> the thing is, trackers can't really do the swarm combining
[14:39:45] <DWKnight> it's all basically client side
[14:40:06] <DWKnight> shareaza's hash search on its supported networks amounts to the same functionality as a DHT
[14:41:18] <chelz> well say a tracker has a db of all the torrent's it's tracking, fetched from DHT through the infohash say. the tracker looks for duplicate hashes and when it finds them it notifies the peers in each swarm by sending them the infohash of it in a new announce protocol addition, then the peers grab the other torrent from dht with the infohash
[14:41:42] <chelz> it's heavy and overhead, but it's centralized and offloaded from the client
[14:44:54] <DWKnight> per-file hash searches over DHT is probably the cleanest way that I could see
[14:45:10] <chelz> yeah, that way does seem better
[14:45:31] <chelz> but trackers could do it, if that was necessary for some reason
[14:45:52] <Switeck> trackers already have scaling issues though...
[14:46:12] <DWKnight> it probably isn't necessary for them
[14:46:22] <Switeck> sometimes due to bandwidth or processing power or even connections per second.
[14:47:45] <chelz> well i'm thinking in terms of perceived speed for a user. the more that's not centralized on a server, the slower it is and the longer it will take.
[14:48:15] <DWKnight> I'll be honest, it might add about 30 seconds to ramp-up
[14:48:32] <DWKnight> based on what I've seen of existing DHT speeds
[14:48:52] <DWKnight> assuming there's an availability issue to begin with
[14:49:14] <chelz> hmm if that's so that wouldn't be bad at all
[14:49:34] <Switeck> First peer/seed you get will probably have PEX enabled, and that'll make the rest come in quick
[14:50:09] <Switeck> I've seen a nearly inactive torrent go from 1 new peer to "it just invited 20+ friends!" in <5 minutes
[14:50:29] <Switeck> ...all thanks to PEX
[14:50:38] <chelz> so actually
[14:50:57] <chelz> if TTHs kickoff, torrent magnet links might be using TTHs instead of infohashes
[14:51:03] <DWKnight> the infamous "torrent downloaded from demonoid" files would be fucking everywhere
[14:51:09] <chelz> hahah
[14:51:12] <DWKnight> and would never stop a torrent from completing
[14:51:53] <chelz> certain client authors, at their discretion, could always set up blacklists for certain undesirable files matching certain patterns *cough*
[14:52:22] <chelz> DWKnight: do you think TTHs are worth adding to BT's DHT?
[14:52:39] <DWKnight> per-file sha1 would probably be enough
[14:53:11] <chelz> erm weren't TTH's better for some reason? say about lots of small files?
[14:55:09] <DWKnight> depends on what you're going after
[14:55:22] <DWKnight> but if you have the file size and it's full SHA1 (not segments) you have enough
[14:57:11] <DWKnight> anyway, I'll be back in 3h or so, got to get back to work
[14:57:21] <chelz> alright
[14:57:39] <chelz> i do wonder what happened with the " merkle tree hashing that was proposed a couple years ago" and why it didn't catch on
[14:58:57] *** bbelt16ag has joined #bittorrent
[15:02:44] <chelz> FastTrack uses UUHash, ED2K/Kad uses MD4, Gnutella uses TTH, and G2 uses: "For file identification and secure integrity check of files it employs SHA-1 hashes. To allow for a file to be reliably downloaded in parallel from multiple sources as well as to allow for the reliable uploading of parts as the file is being downloaded (swarming), Tiger tree hashes are used."
[15:03:19] <chelz> if compatibility with other clients/networks is a goal, TTH seems like the way to go. SHA-1 isn't used by anyone else for the primary hash.
[15:06:38] <chelz> oh also seems Gnutella uses SHA-1
[15:09:27] *** bbelt16ag has quit IRC
[15:26:39] *** kwinz2 has quit IRC
[15:35:13] *** _rafi2_ has joined #bittorrent
[15:41:09] *** HandheldPenguin` is now known as HandheldPenguin
[15:43:46] *** kwinz2 has joined #bittorrent
[15:45:10] *** HandheldPenguin is now known as HandheldPenguin`
[15:45:27] *** _rafi_ has quit IRC
[15:46:51] *** _rafi2_ is now known as _rafi_
[15:50:58] *** medecau has quit IRC
[15:51:23] *** medecau has joined #bittorrent
[15:51:32] *** kwinz2_ has joined #bittorrent
[15:55:30] *** kwinz2 has quit IRC
[16:35:41] *** Switeck has quit IRC
[16:48:03] *** medecau has left #bittorrent
[16:55:55] <burris> I don't care what you say, if four other people are currently trying to sell the same item on eBay then the item is not *RARE*
[16:57:26] <kjetilho> burris: why not?
[16:57:37] <kjetilho> 4 people out of 7 billion
[17:08:00] *** edigaryev has quit IRC
[17:20:31] *** GTHK has joined #bittorrent
[17:21:29] *** edigaryev has joined #bittorrent
[17:33:51] *** drugosaur has joined #bittorrent
[17:34:46] *** drugosaur has quit IRC
[17:34:56] *** wojci has joined #bittorrent
[17:35:32] *** Elrohir has joined #bittorrent
[17:58:26] *** ajaya has joined #bittorrent
[18:01:44] *** ahath has quit IRC
[18:17:50] *** ahath has joined #bittorrent
[18:18:08] *** pevangelista has joined #bittorrent
[18:30:13] *** edigaryev has quit IRC
[18:30:55] *** edigaryev has joined #bittorrent
[18:40:42] <DWKnight> chelz: most GNUTella1/2 clients use SHA1 to identify files and TTH to validate
[18:42:19] <DWKnight> fasttrack doesn't count in my book because UUHash isn't even remotely secure
[18:44:44] <DWKnight> all things considered though, with the spec I linked for the optional file hashes, it's actually quite trivial to add per-file hashes to torrents
[18:44:53] <DWKnight> getting clients to be able to use them is where the real fun is
[18:51:08] *** gui7 has quit IRC
[18:56:34] *** DWKnight has quit IRC
[19:03:51] *** andar2 has joined #bittorrent
[19:06:01] *** ania has quit IRC
[19:09:57] *** kwinz2_ has quit IRC
[19:20:22] *** goussx has joined #bittorrent
[19:41:04] *** Elrohir has quit IRC
[20:03:38] *** KyleK_ has joined #bittorrent
[20:05:24] *** pevangelista has quit IRC
[20:15:43] *** Waldorf has quit IRC
[20:20:22] *** The_8472 has joined #bittorrent
[21:17:54] *** init0 has joined #bittorrent
[21:31:56] *** init0_ has quit IRC
[21:34:59] *** The_8472 has quit IRC
[21:35:20] *** wadim has joined #bittorrent
[21:35:22] *** wadim is now known as The_8472
[21:46:36] *** ajaya has quit IRC
[21:55:29] *** Miller` has joined #bittorrent
[22:42:22] *** BentMyWookie has quit IRC
[22:42:41] *** void^ has quit IRC
[22:43:42] *** kwinz2 has joined #bittorrent
[22:57:01] *** KyleK_ has quit IRC
[23:02:16] *** chelz has quit IRC
[23:02:31] *** alienvenom has quit IRC
[23:03:20] *** ajaya has joined #bittorrent
[23:06:55] *** edigaryev has quit IRC
[23:18:57] *** void^ has joined #bittorrent
[23:21:51] *** alienvenom has joined #bittorrent
[23:47:06] *** echelog` has joined #bittorrent
[23:47:39] *** echelog` is now known as echelog
[23:48:21] *** echelog has joined #bittorrent





top