[00:18:13] *** medecau has joined #bittorrent
[00:29:48] *** goussx has quit IRC
[00:55:17] <DeHackEd> alus: I would have some special tweaks I would want. I would not be announcing myself globally, for example.
[00:55:46] <The_8472> that's not really possible without violating some contracts within the DHT
[00:56:03] <DeHackEd> to search, but not insert myself?
[00:56:05] <The_8472> at least you would have to misbehave like a NATed node
[00:56:12] <The_8472> oh
[00:56:33] <The_8472> if you just want to make lookups, sure, that's possible. i'm doing that in bulk even.
[00:56:42] <DeHackEd> I'd save anything someone asked me to. but as an ISP-local cache, I don't wnat to be seeding to the world
[00:57:14] <DeHackEd> yeah, I want to behave, but not be discovered via any way except BEP 22
[00:57:31] <DeHackEd> but if acceptance of BEP 22 is that low, it may not be worth the effort
[00:58:13] <DeHackEd> my questions are thing like "How long do I retain stored peers" and "Must I follow the listed peer storage bucket rules listed on BEP 5" ?
[00:59:44] <The_8472> let me check my code
[00:59:56] <DeHackEd> it may be easier to just check transmission's code...
[01:00:30] <The_8472> or that
[01:00:52] <The_8472> bep5 doesn't specify the timeouts. mine is 60 minutes (30 minutes * 2 for grace time)
[01:01:08] <The_8472> "Must I follow the listed peer storage bucket rules listed on BEP 5" <- rephrase please
[01:01:54] <DeHackEd> BEP 5 says that peers are stored in buckets that split when they're full provided my own node ID fits in that bucket. it's an interesting strategy to limit stored peers with a bias towards peers in proxmimity to you.
[01:01:56] <The_8472> buckets = routing table = you're referring to DHT nodes, not BT peers i assume. so which rules governing the routing table are you referring to?
[01:02:07] <DeHackEd> Is there any rule requiring I follow the same implementation?
[01:02:48] <DeHackEd> still, if following someone else's implementation it becomes a non-issue
[01:02:48] <The_8472> it is a property of kademlia, ensuring log(n) behavior.
[01:02:58] <DeHackEd> that PDF describes a different technique
[01:03:43] <The_8472> i... don't think so
[01:03:50] <The_8472> the kademlia spec is also about bucket splitting
[01:04:27] <DeHackEd> I thought they suggested an array of 160 slots, peers go into the slot depending on the size of their distance metric
[01:05:33] <The_8472> that's an approximate way to implement it, used by several implementations
[01:05:39] <The_8472> the accurate way is using buckets
[01:05:56] <The_8472> keyspace-prefix based buckets that is
[01:15:26] *** Switeck has joined #bittorrent
[01:20:50] *** medecau has quit IRC
[01:44:04] *** alienvenom has quit IRC
[01:48:50] <Dan39> why has no one used libtorrent-rakshasa besides rtorrent... :|
[01:52:00] *** alienvenom has joined #bittorrent
[02:03:39] <DeHackEd> special needs
[02:04:34] <Switeck> you mean special needs like the 2 prong fork or like rides the short bus?
[02:05:24] <Dan39> O_o
[02:07:21] <Dan39> what is this rediculousness in libtorrent-rasterbar wiki page
[02:07:23] <Dan39> Often, for files that are 4 GB, the piece size is 2 or 4 MB, just to avoid making the .torrent file too big.
[02:07:31] <Dan39> 4Gb is pretty smal
[02:07:39] <Dan39> id used like 512 or 1 mb haha
[02:07:51] <DeHackEd> Switeck: little of column A, little of column B
[02:09:02] <Switeck> Dan39, you'll find the recommendations for how to make and use torrents to be a bit on the failing side even from the experts who program BT clients.
[02:09:39] <DeHackEd> clients used to have bad piece selection algorithms that were slow, so keeping the piece count down had some benefits. that's gone.
[02:10:04] <DeHackEd> the .torrent size argument is the only good argument anymore, and even that's weak. if you're sharing 4 GB of data, you can probably afford to have a 500k torrent
[02:11:06] <Dan39> now adays
[02:11:31] <Dan39> i saw use smallest piece size(within reason) thatll be within site's .torrent size limit
[02:11:34] <Dan39> say
[02:11:45] <Switeck> why?
[02:11:59] <Dan39> why not?
[02:12:03] <Dan39> seems better
[02:12:04] <Switeck> If there's "too large", chances are there's a "too small" as well.
[02:12:06] <Dan39> more efficient
[02:12:23] <Dan39> i said within reason
[02:12:37] <Switeck> so if a swarm has 100 interconnected peers+seeds, sending haves to everyone 4-20x as often means a slight increase in overheads.
[02:12:39] <Dan39> on a 100GB torernt obviously dont make it 512 kb piece size
[02:12:43] <DeHackEd> well, there is too small. unnecessarily big .torrent files, broadcasting HAVEs too often...
[02:13:10] <Switeck> new haves rates has almost nothing to do with torrent size IMO
[02:13:23] <Switeck> it's a speed versus piece size
[02:13:50] <Dan39> but i mean, i was recomendintg 2 or 4 mb piece size for 35 GB torrent while other person was saying im an idiot and to just use 8 or 16
[02:14:36] <The_8472> 16MB pieces? insanity
[02:14:39] <Dan39> yep
[02:14:41] <Dan39> 16
[02:14:44] <DeHackEd> but if you have a piece size of, say, 16k then a typical cable modem user will be getting new pieces in fractions of a second
[02:14:55] <Dan39> 16mb piece size for packs only like 80 GB
[02:15:08] <Dan39> only time id see 16 is >500 GB
[02:15:11] <Switeck> My rule-of-thumb is the old 65535 (or was it 65536?) piece limit for a torrent.
[02:15:31] <Switeck> only exceed that for stupendously large torrents
[02:15:39] <Dan39> well i use mktorrent, so its like 18-23 ^2
[02:15:41] <Switeck> like >500 GB.
[02:15:58] <Dan39> or is it 2^ 18-23 lol
[02:15:59] <DeHackEd> I once followed 5000 pieces, or 256k pieces, whichever produces the biggest piece size. but yeah now I'd go bigger.
[02:16:01] <DeHackEd> still, 256k
[02:16:17] <Dan39> yea its 2^
[02:16:44] <Dan39> hmm
[02:16:48] <Dan39> merckle hash tree
[02:16:49] <Dan39> interesting
[02:17:08] <Dan39> merkle
[02:17:19] <Switeck> I'd seriously consider never using smaller than about 128 KB piece size even for small torrents.
[02:17:21] <Dan39> what clients support merkle hash tree?
[02:17:50] *** goussx has joined #bittorrent
[02:17:58] <Switeck> ...unless I know the swarm will be lots of dial-up modems :P
[02:20:34] <Switeck> Then again, with some people using "YouTube settings" for their BT client...nothing's safe.
[02:23:53] <Dan39> hehe
[02:24:06] <Switeck> start all torrents at once, give them each 10+ upload slots...because we want to share!
[02:24:39] <DeHackEd> youtube settings?
[02:25:25] <Dan39> settings from youtube videos i guess he means
[02:25:33] <Dan39> like search "utorrent settings" hehe
[02:25:39] <Switeck> exactly, although more generalized than that.
[02:27:19] <DeHackEd> first video fails at video recording
[02:29:21] <Dan39> whatd they use a cam for recording monitor? lmao
[02:29:47] <Dan39> like come on... there is good easy to use screen-capture software out there
[02:29:52] <Dan39> derrr
[02:30:41] <DeHackEd> it's not. somehow it's capturing a shaking selectoin of the screen...
[02:31:05] <Dan39> >_<
[02:36:16] <Switeck> that probably means you found one of the better ones XD
[02:56:53] *** goussx has quit IRC
[02:56:53] *** goussx_ has joined #bittorrent
[02:56:53] *** goussx_ is now known as goussx
[03:00:04] *** Switeck has quit IRC
[03:03:52] *** The_8472 has quit IRC
[03:08:11] *** Gottaname|Mobili has joined #bittorrent
[03:12:43] *** alienvenom has quit IRC
[03:21:22] *** alienvenom has joined #bittorrent
[04:01:53] <DeHackEd> oh wow, I saw someone hit the BEP 22 DNS record..
[04:48:21] *** agrajag has quit IRC
[04:54:59] *** goussx_ has joined #bittorrent
[04:54:59] *** goussx has quit IRC
[04:55:00] *** goussx_ is now known as goussx
[04:55:04] *** goussx has quit IRC
[04:55:04] *** goussx has joined #bittorrent
[06:30:51] *** MassaRoddel has quit IRC
[07:21:04] *** agrajag has joined #bittorrent
[07:25:47] *** agrajag has quit IRC
[07:25:47] *** agrajag has joined #bittorrent
[07:28:40] *** TheSHAD0W has quit IRC
[07:29:21] *** multi-d has joined #bittorrent
[08:05:16] *** Gottaname|Mobili has quit IRC
[08:09:36] *** Guest4310 has quit IRC
[08:20:19] *** MassaRoddel has joined #bittorrent
[09:11:37] *** multi-d has quit IRC
[09:36:04] *** goussx_ has joined #bittorrent
[09:36:04] *** goussx_ has joined #bittorrent
[09:36:04] *** goussx has quit IRC
[09:36:05] *** goussx_ is now known as goussx
[11:04:35] *** goussx has quit IRC
[11:06:42] *** hydri has quit IRC
[11:43:41] *** mxs_ has joined #bittorrent
[11:45:06] *** mxs has quit IRC
[11:45:06] *** mxs_ is now known as mxs
[12:32:41] *** init0_ has joined #bittorrent
[12:35:35] *** init0 has quit IRC
[13:37:19] *** init0_ has quit IRC
[13:37:26] *** init0 has joined #bittorrent
[16:04:12] *** TheSHAD0W has joined #bittorrent
[17:11:31] *** Gottaname has quit IRC
[18:42:00] *** Guest4310 has joined #bittorrent
[18:42:13] *** Guest4310 is now known as Kitsoran
[18:58:47] *** deed02392 has joined #bittorrent
[19:00:15] <deed02392> Hi guys, how do I decode an info_hash from an announce? For examlpe: GET /announce?info_hash=%d2%e6t%e2v%87%c1%0d%9d%b8%5b%1f7%cd%98EQc%2b%97
[19:32:27] *** `rafi_ has joined #bittorrent
[19:58:33] <DWKnight> urldecode it
[20:01:15] <Dan39> DWKnight: doesnt look like regular url % encoding... :|
[20:01:57] <DWKnight> does to me
[20:02:21] <DWKnight> go get another coffee and try again
[20:02:42] <Dan39> hehe
[20:04:17] <Dan39> '\xd2\xe6t\xe2v\x87\xc1\r\x9d\xb8[\x1f7\xcd\x98EQc+\x97' :|
[20:06:18] <Dan39> doesnt look like an infohash :
[20:08:31] <Dan39> DWKnight: O_o
[20:16:01] <DWKnight> does to me
[20:16:07] <DWKnight> echo strlen(urldecode("%d2%e6t%e2v%87%c1%0d%9d%b8%5b%1f7%cd%98EQc%2b%97"));
[20:16:10] <DWKnight> in php
[20:16:13] <DWKnight> spits out "20"
[20:16:17] <DWKnight> which is correct for an infohash
[20:19:21] <DWKnight> so stop with the decaf
[20:25:29] <Dan39> hehe
[20:25:34] <Dan39> well whats the infohash then?
[20:25:52] <Dan39> yea its 20 length...
[20:26:00] <Dan39> i got the same length
[20:27:04] <DWKnight> echo bin2hex(urldecode("%d2%e6t%e2v%87%c1%0d%9d%b8%5b%1f7%cd%98EQc%2b%97"));
[20:27:15] * DWKnight throws dan off a cliff
[20:29:42] <Dan39> woot
[20:29:44] <Dan39> 'd2e674e27687c10d9db85b1f37cd984551632b97'
[20:44:29] <DWKnight> see, they're not THAT hard to read
[20:46:15] <Dan39> ya 3 functions later...
[20:46:16] <Dan39> >_<
[20:47:14] <DWKnight> except I only need two of them to tell if the infohash is valid
[20:53:20] *** `rafi_ has quit IRC
[20:56:03] *** Samual has quit IRC
[21:07:49] <alus> url encoding a binary infohash is hilarious
[21:08:29] <Dan39> i dont really see the point
[21:08:47] <Dan39> besides obfuscating it
[21:08:56] <Dan39> which we just showed is pretty pointless
[21:19:12] *** The_8472 has joined #bittorrent
[21:29:32] <alus> the goal was not obfuscation
[21:29:49] <alus> the goal was Bram didn't understand http but he needed to use it
[21:30:04] <alus> or thought he did
[21:30:38] <The_8472> talking about trackers?
[21:34:56] <alus> the url encoding of the infohash
[21:38:51] <The_8472> ah
[21:53:12] *** `rafi_ has joined #bittorrent
[21:55:12] *** jch has joined #bittorrent
[21:55:24] *** swinokur has quit IRC
[21:56:08] *** swinokur has joined #bittorrent
[22:42:31] *** Samual has joined #bittorrent
[22:44:37] <jordan> alus: what is the "complete_ago" tag for in the extended handshake?
[22:45:49] <jordan> libtorrent-rb doesn't have it, and I don't see any discussion of it anywhere
[22:53:27] *** gde33 has joined #bittorrent
[23:35:22] *** Didier^ has joined #bittorrent
[23:36:18] <Didier^> Has anybody happened to have the hangover 2 .rar password ?
[23:36:57] <Dan39> read the topic
[23:37:06] <Dan39> BitTorrent, client and protocol discussion and support. -- This is not a file distribution channel. Do NOT ask about files you can download, do NOT ask where to find files, do NOT use !list, etc.
[23:44:42] <mpl> Didier^: I recommend herbal tea - maybe vervein - for a hangover.
[23:45:12] * jch prefers Kefir.
[23:46:13] <mpl> jch: dunno, I'm pulling it out of my ass, as I've never had a hangover. but herbal tea can't hurt :)
[23:46:48] <jch> You'll definitely want to make sure that your herbs don't have a diuretic effect.
[23:47:07] <mpl> right. and then vervein is pretty bad in that respect.
[23:47:09] <jch> You're probably dehydrated enough already.
[23:47:17] <mpl> not as bad as green tea, but still bad.
[23:49:30] <kjetilho> jch: you have Kefir over there?
[23:49:37] * kjetilho was a bit surprised to see it mentioned
[23:49:52] <jch> Not here, unfortunately.  We do have it where I grew up ;-)
[23:50:31] <alus> jordan: it is to do swarm guess of the last time anyone saw it complete. the semantics are Tricky and Dangerous and we never documented it because it Should Not Be Used (yet)
[23:50:44] <alus> in realitely I think it's something simple like min() or max() but I forget which
[23:50:48] <jch> We do have north-african buttermilk, though.
[23:55:30] <jordan> alus: ok. thanks
[23:55:51] *** Didier^ has quit IRC

   July 25, 2011  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >