[00:04:36] *** Elrohir has quit IRC
[00:13:45] *** Switeck has joined #bittorrent
[00:18:30] *** rrr_ has quit IRC
[00:20:45] *** nks has quit IRC
[00:20:55] *** nks has joined #bittorrent
[00:21:55] *** bbelt16ag has joined #bittorrent
[00:25:12] *** bbelt16ag has quit IRC
[00:30:46] *** gui7 has joined #bittorrent
[00:33:36] *** gui7 has quit IRC
[00:39:35] <DeHackEd> ha
[00:51:23] <TheSHAD0W> http://torrentfreak.com/comcasts-bittorrent-settlement-excludes-pirates-100114/
[00:56:05] <DWKnight> The_8472: how does AZ/Vuze handle multitracker right now?
[00:56:24] <TheSHAD0W> http://torrentfreak.com/everything-you-need-to-refute-a-file-sharing-legal-threat-100114/
[01:02:13] <Nolar> DWKnight 4306 and older do it per original spec, 4307+ announce to all in parallel
[01:02:22] <Nolar> ish
[01:04:34] <DWKnight> got a guy on the OOo distro list commenting on it
[01:04:49] <DWKnight> going to nitpick some of his stuff
[01:07:15] <Switeck> and on multitracker spec, does uTorrent v2.0 RC3 have udp trackers "fixed" instead of always tried regardless of placement?
[01:09:28] <Nolar> DWKnight on what?
[01:09:53] <Nolar>  <Switeck> and on multitracker spec, does uTorrent v2.0 RC3 have udp trackers "fixed" instead of always tried regardless of placement? <<< afaik ut doesnt obey the original spec
[01:09:59] <Nolar> it'll announce to all
[01:10:08] <DWKnight> I've been over this
[01:10:11] <Switeck> Then that is a problem...
[01:10:28] <DWKnight> and unless they've changed things, they're not giving ANY benefit to them being in the torrents at all
[01:14:38] <Nolar> the idea is you can find "lost" peers on that swarm
[01:15:40] <DWKnight> if the dual-protocol tracker is losing peers in that way, it's horridly broken
[01:16:14] <Switeck> I'm seeing lots of garbage ips returned by udp trackers, though I don't know if it's intrinsic to those particular udp trackers or a flaw in design.
[01:22:36] <Nolar> garbage ips?
[01:22:40] <Nolar> invalid, or not connectable?
[01:23:26] <Nolar> DWKnight the problem for us was that with multiple trackers avail, when we just announced to the first one, we might not be connecting to the "active" swarm/tracker
[01:24:00] <Switeck> Nolar, I mean 0.x.x.x and 224-255.x.x
[01:24:15] <Nolar> usually the first on the list is "active", but no guarantee
[01:24:23] <Switeck> technically a "legal" IPv4 number, but practically impossible under current internet mapping system.
[01:24:26] <Nolar> Switeck that would be a tracker bug imho
[01:24:54] <Nolar> public trackers should be filtering out non-public networks
[01:25:09] <DWKnight> udp tracker logic means that unless you're at least checking to see if there's a matching http tracker and skipping the http, you're wasting your udp support entirely
[01:25:16] <Switeck> udp trackers also return huge numbers of ips that seem to never work. so I don't think they're filtering not connectible ips either.
[01:28:09] <Nolar> Switeck if they are running udp, for a reason, they definitely will nto be doing nat checking
[01:29:18] <Switeck> Some of these are dual HTTP/udp trackers using similar URLs.
[01:29:50] <Switeck> The udp trackers may be holding older ips longer as well.
[01:31:20] <Nolar> ya, some people run both just because they can, whereas others run udp because it scales
[01:33:00] <Switeck> scales better you mean XD
[01:34:40] *** Waldorf has quit IRC
[01:35:26] <Nolar> "better"
[01:35:39] * Nolar prefers to scale http
[01:36:25] <DWKnight> udp may scale better for load
[01:36:33] <DWKnight> but http scales better for future functionality
[01:40:18] <Firon> K`Tetch, ping
[01:40:52] <Nolar> udp uses less bandwidth, that's it
[01:41:06] <Switeck> Yes, DWK thanks for the clarification...indeed http seems the best for future functionality.
[01:41:10] <DWKnight> http is more extensible and better documented
[01:41:10] <Nolar> http is far easier to scale out
[01:41:29] <Switeck> I only meant in terms of raw clients to a single tracker
[01:42:22] <Switeck> But returning predominately dead ips is questionable, as some may find nobody to connect to after a tracker update.
[01:43:59] <Nolar> ya
[01:44:12] <Nolar> we treat tracker as a good way to bootstrap
[01:44:36] <Nolar> but pex is far more effective at fleshing out the rest of the conns
[01:44:51] <Switeck> sadly, a lot of people see fit to dump in 10+ additional trackers "just to be sure" :P
[01:45:37] <DWKnight> usually 15-20
[01:45:38] <Nolar> yup
[01:45:48] <Nolar> onion ones too!
[01:46:51] <Switeck> So uTorrent always firing udp trackers puts an undue burden on them for no net return.
[01:48:37] <The_8472> always?
[01:48:50] <The_8472> autoprobing should be done with exponential backoff
[01:50:52] <Switeck> well, uTorrent might use exponential backoff if the udp tracker fails
[01:50:57] <The_8472> <Switeck> udp trackers also return huge numbers of ips that seem to never work. so I don't think they're filtering not connectible ips either. <- UDP trackers shouldn't work any different from the HTTP equivalent
[01:51:05] <The_8472> unless the parsing of the UDP packets is wrong somehow
[01:51:21] <The_8472> 4 bytes is 4 bytes, you can't check if it's actually an IP address
[01:51:37] <Nolar> ya, i don't know how ut handles announce timing, but ours was made to be quite conservative
[01:52:14] <Switeck> swapped sequences seems a likely possibility. where w.x.y.z:ab (ab = packed port #) might come out a.b.w.x:yz
[01:52:21] <Switeck> or some other silly nonsense
[01:53:03] <Nolar> ya, people throw crap at the trackers all the time
[01:53:20] <Switeck> or port # the connection used is what udp trackers report instead of that connection's listening port. :P
[01:55:00] <The_8472> that doesn't make sense
[01:55:19] <The_8472> UDP trackers and HTTP trackers are the same. they share the same pool of IPs of peers
[01:55:39] <The_8472> same backend, different frontend
[01:58:58] <Switeck> I cannot explain the discrepancy, only that it exists.
[02:02:16] *** The_8472 has quit IRC
[02:02:37] *** wadim has joined #bittorrent
[02:02:39] *** wadim is now known as The_8472
[02:10:19] <The_8472> Switeck, which tracker software in particular?
[02:10:43] <Switeck> I don't know
[02:10:49] *** neitcho has quit IRC
[02:11:13] <The_8472> well, do you know the tracker url?
[02:11:25] <Switeck> tracker.openbittorrent.com
[02:11:37] <Switeck> tracker.publicbt.com
[02:11:40] *** rrr_ has joined #bittorrent
[02:12:52] <The_8472> they're running opentracker
[02:21:35] *** andar2 has quit IRC
[02:31:32] *** Nolar has quit IRC
[02:31:41] *** Nolar has joined #bittorrent
[02:42:29] *** medecau has quit IRC
[02:43:40] *** rrr_ has quit IRC
[03:37:23] *** chelz has joined #bittorrent
[03:52:04] *** rrr_ has joined #bittorrent
[04:07:20] *** The_8472 has quit IRC
[04:07:40] *** wadim has joined #bittorrent
[04:07:42] *** wadim is now known as The_8472
[04:24:47] *** BentMyWookie has quit IRC
[04:25:09] *** init0 has joined #bittorrent
[04:25:11] *** BentMyWookie has joined #bittorrent
[04:39:14] *** init0_ has quit IRC
[04:58:45] <erdgeist> Hmmm, I've heard reports, too
[05:12:33] *** Nolar has quit IRC
[05:13:15] *** Nolar has joined #bittorrent
[05:19:39] *** Nolar has quit IRC
[05:19:39] *** goussx has quit IRC
[05:26:04] *** Nolar has joined #bittorrent
[05:28:57] *** goussx has joined #bittorrent
[05:36:55] *** bittwist has joined #BitTorrent
[05:44:00] *** goussx has quit IRC
[05:56:53] *** bt42 has quit IRC
[06:14:15] *** goussx has joined #bittorrent
[06:27:05] *** MassaRoddel has quit IRC
[07:18:30] *** MassaRoddel has joined #bittorrent
[07:20:15] *** rrr_ has quit IRC
[07:58:14] *** gui7 has joined #bittorrent
[07:59:32] *** kwinz2 has joined #bittorrent
[08:04:05] *** kwinz2 has quit IRC
[08:07:03] *** gui7 has quit IRC
[08:13:31] *** Switeck has quit IRC
[08:20:38] *** rrr has joined #bittorrent
[09:09:05] *** Mazon has quit IRC
[09:09:07] *** stalled has quit IRC
[09:09:07] *** K`Tetch has quit IRC
[09:09:09] *** alus has quit IRC
[09:09:09] *** BitTorrentBot has quit IRC
[09:09:09] *** charles has quit IRC
[09:09:09] *** tris has quit IRC
[09:09:13] *** hlindhe has quit IRC
[09:09:13] *** chalcedony has quit IRC
[09:09:13] *** swolchok has quit IRC
[09:09:13] *** DeHackEd has quit IRC
[09:09:14] *** goussx has quit IRC
[09:09:14] *** Nolar has quit IRC
[09:09:14] *** init0 has quit IRC
[09:09:15] *** punto has quit IRC
[09:09:17] *** jnpplf has quit IRC
[09:09:17] *** erdgeist has quit IRC
[09:09:23] *** uriel has quit IRC
[09:09:23] *** hlindhe_ is now known as hlindhe
[09:12:06] *** hlindhe has quit IRC
[09:12:08] *** hlindhe_ has joined #bittorrent
[09:12:12] *** goussx has joined #bittorrent
[09:12:12] *** Nolar has joined #bittorrent
[09:12:12] *** init0 has joined #bittorrent
[09:12:12] *** Mazon has joined #bittorrent
[09:12:12] *** punto has joined #bittorrent
[09:12:12] *** stalled has joined #bittorrent
[09:12:12] *** chalcedony has joined #bittorrent
[09:12:12] *** K`Tetch has joined #bittorrent
[09:12:12] *** uriel has joined #bittorrent
[09:12:12] *** tris has joined #bittorrent
[09:12:12] *** alus has joined #bittorrent
[09:12:12] *** charles has joined #bittorrent
[09:12:12] *** BitTorrentBot has joined #bittorrent
[09:12:12] *** hlindhe has joined #bittorrent
[09:12:12] *** DeHackEd has joined #bittorrent
[09:12:12] *** swolchok has joined #bittorrent
[09:12:12] *** jnpplf has joined #bittorrent
[09:12:12] *** erdgeist has joined #bittorrent
[10:24:01] *** echelog has joined #bittorrent
[10:30:34] *** medecau has joined #bittorrent
[10:53:14] *** rrr has quit IRC
[10:56:29] *** rrr has joined #bittorrent
[11:02:43] *** hydri has quit IRC
[11:04:59] *** mxs has quit IRC
[11:06:10] *** hydri has joined #bittorrent
[11:08:32] *** rrr has quit IRC
[11:12:16] *** mxs has joined #bittorrent
[11:13:55] *** mxs_ has joined #bittorrent
[11:14:24] *** mxs has quit IRC
[11:14:27] *** mxs_ is now known as mxs
[11:14:56] *** stalled_ has joined #bittorrent
[11:16:21] *** stalled has quit IRC
[11:16:48] *** stalled_ is now known as stalled
[11:17:57] *** rrr_ has joined #bittorrent
[11:24:50] *** chelz has quit IRC
[13:05:28] *** kjetilho has quit IRC
[14:27:54] *** kjetilho has joined #bittorrent
[15:13:36] *** _rafi_ has joined #bittorrent
[16:15:06] *** nonononono has joined #bittorrent
[16:15:39] <nonononono> Does not opening the needed port on the router prevents me from sharing / downloading torrents?
[16:17:05] <_rafi_> yes / no
[16:17:32] <nonononono> so I wont be able to upload back?
[16:18:17] <_rafi_> re-prasing: people will not be able to find/download from you what they need
[16:18:18] <mpl> mainly yes. but it will also greatly impairs your dl rate.
[16:19:05] <mpl> because other peers only share with peers sharing with them already (grossly).
[16:22:23] <nonononono> http? port 80
[16:30:39] *** nonononono has quit IRC
[16:37:06] *** _rafi_ has quit IRC
[16:48:34] *** GTHK has joined #bittorrent
[16:49:13] *** bt42 has joined #BitTorrent
[16:55:00] <K`Tetch> http://torrentfreak.com/oink-admin-found-not-guilty-walks-free-100115/
[16:56:45] *** punto has quit IRC
[17:03:38] <charles> whow, that was fast
[17:04:50] <charles> after all that brouhaha, the trial only took two weeks
[17:08:01] *** bittwist has quit IRC
[17:20:09] *** _rafi_ has joined #bittorrent
[17:20:31] *** _rafi_ has quit IRC
[17:21:30] *** _rafi_ has joined #bittorrent
[17:21:47] <TheSHAD0W> Yay!
[17:31:53] *** medecau_ has joined #bittorrent
[17:32:00] *** medecau has quit IRC
[17:32:12] *** medecau_ is now known as medecau
[17:48:51] *** gui7 has joined #bittorrent
[17:51:41] <The_8472> K`Tetch, does that mean he's cleared of all charges and thus running a site like oink would be legal in the UK?
[17:51:57] <The_8472> or are there other lawsuits pending?
[17:52:34] <K`Tetch> not sure on detils yet
[17:54:22] <burris> this was a criminal case for "conspiracy to defraud"  couldn't they go after him in civil court for secondary lnfringement?  I don't know shit about the uk
[17:54:33] <K`Tetch> possibly
[17:54:47] <burris> in the us they definitely could/would
[17:55:25] <burris> the prosecutor was quite mistaken in alleging that OiNK was a "cash cow"    clearly, it was a "cash pig."
[18:09:46] *** uriel has quit IRC
[18:09:55] *** uriel has joined #bittorrent
[18:12:48] *** cgreco has quit IRC
[18:15:27] *** cgreco has joined #bittorrent
[18:22:23] *** goussx has quit IRC
[18:45:07] <DWKnight> did you see how the breakdown of votes in the case went?
[18:45:19] <DWKnight> unanimous against the music industry
[18:50:12] <Andrius> surprisingly, there are still few sane people in the world
[18:51:52] <The_8472> well, "conspiracy to defraud" seems like a strong charge... not something mushy like incitement or contributory infringement. So it's much harder to prove it, especially if you have a criminal case where the burden of proof is higher.
[18:57:36] *** goussx has joined #bittorrent
[19:06:40] *** Elrohir has joined #bittorrent
[19:11:57] *** medecau has quit IRC
[19:12:15] *** medecau has joined #bittorrent
[19:31:05] *** medecau has quit IRC
[19:31:29] *** medecau has joined #bittorrent
[19:41:49] *** JudgeSHAD0W has joined #bittorrent
[19:49:41] *** andar2 has joined #bittorrent
[19:54:32] <K`Tetch> The_8472 - I'm not sure there is a charge for incitement or contributory infringement in the UKJ
[20:15:27] *** dandon has joined #bittorrent
[20:17:55] *** ajaya has joined #bittorrent
[20:31:21] *** foomor has quit IRC
[20:31:22] *** foomor_ has joined #bittorrent
[20:32:09] *** btcod2 has joined #bittorrent
[20:32:39] <btcod2> dear all
[20:33:19] <btcod2> antfarm is a proposal of efficient bandwidth allocation by seeds in BT
[20:33:31] <btcod2> https://www.usenix.org/events/nsdi09/tech/full_papers/peterson/peterson_html/
[20:33:46] <btcod2> do you know if any client already implements the policies described in the paper?
[20:34:16] *** foomor_ is now known as foomor
[20:36:03] <btcod2> it is a measurement based approach : keep monitoring the download rates of peers in different swarms, and increase the bandwidth provided to  swarms which would benefit most from the allocation of additional bandwidth
[20:59:48] * The_8472 suggests fixing the certificate for that site
[21:07:00] <alus> btcod2: seeders generally provide more bandwidth to swarms which are downloading faster
[21:08:25] <The_8472> and most importantly, BT clients have seeding queues that are not round-robin but based on scrape information
[21:10:42] <The_8472> and bandwidth allocation is not really done on a per-peer basis. it's more about a per-torrent basis.
[21:11:12] <The_8472> in most clients each upload slot gets more or less the same bandwidth if the peer can absorb it
[21:11:24] <The_8472> and if they can't the seeding unchoker will pick another peer
[21:12:45] <The_8472> "BitTorrent can starve swarms" ... a) peers are still uploading b) that depends on how seeders sort their seeding queue, different clients have different behaviors here
[21:13:36] <The_8472> c) it's a necessity at some point, since the global, aggregate bandwidth is finite and new content gets added every day. if old content wouldn't starve at some point the available bandwidth per torrent would decrease, on average.
[21:15:30] <The_8472> another issue is keeping state
[21:15:36] <The_8472> at least on public torrents
[21:17:24] <The_8472> trackers are designed to be as dumb as possible, since they have to answer requests in the thousands per second.... and that's with peers announcing every 30 minutes or so
[21:18:03] <The_8472> if it had to calculate many tokens for each peer things would get far more expensive state and cpu wise
[21:18:34] <DWKnight> disecting their work and showing how ugly it is?
[21:18:35] *** ania has joined #bittorrent
[21:18:38] *** medecau_ has joined #bittorrent
[21:18:39] *** medecau has quit IRC
[21:18:55] *** medecau_ is now known as medecau
[21:19:07] <The_8472> it's not all too ugly
[21:19:12] <The_8472> i just don't think it's practical
[21:20:00] <btcod2> right, it's a nice piece of work
[21:20:14] <btcod2> and i'm now disregarding the tockens issue
[21:20:22] *** medecau_ has joined #bittorrent
[21:20:32] <btcod2> just focusing on the publisher bandwidth allocation
[21:20:47] *** medecau has quit IRC
[21:20:47] *** medecau_ is now known as medecau
[21:21:32] <btcod2> the bandwidth allocation proposed in the paper is torrent based, not peer based
[21:23:31] *** ania has quit IRC
[21:23:57] <btcod2> alus: "seeders generally provide more bandwidth to swarms which are downloading faster" -- what is the rationale here ?
[21:24:16] <DWKnight> simple demand metrics
[21:24:45] <btcod2> so, does it happen by design or is it a mere side effect?
[21:25:16] <btcod2> and if it is a side effect, isn't it a bad one?
[21:30:51] <alus> the choker for a seeder uploads to peers who are downloading fastest
[21:31:15] <btcod2> is this an heuristic ?
[21:31:20] <alus> this is related to how fast that peer can upload, so the effect is that the seeder gives pieces to peers who can re-trade them faster
[21:31:23] <btcod2> which clients implement that ?
[21:31:29] <alus> probably all
[21:31:38] <btcod2> i see
[21:31:48] <btcod2> ok, this is inside a swarm
[21:31:57] <The_8472> btcod2, if you consider public swarms then bittorrent is a content distribution system, i.e. new content gets churned out every minute and has to be distributed fast. content retention is only a nice side-effect. swarms die eventually
[21:31:57] <btcod2> now what about the split among swarms ?
[21:32:24] <alus> well, this is inside a swarm or split among running swarms
[21:32:35] <The_8472> this can be done differently for content hosters, where they can just allocate seeds based on various demand metrics. e.g. they can dedicate seeds to swarms where no enduser is seeding
[21:32:40] <alus> for the entire queue of swarms, scrape info is used as The_8472 mentioned, in good clients anyway
[21:32:53] <The_8472> or they can dedicate seeds to the most popular swarms to keep them fast and user experience good for most of the users
[21:33:35] <btcod2> well ... but dedicating to seeds to the most popular swarms may not have a big impact on those swarms
[21:34:08] <btcod2> and if the aggregate number of users in less popular swarms is high allocating more to less popular users may lead to better experience for more users
[21:34:11] <The_8472> considering asymmetric internet connections itprobably does
[21:34:34] <The_8472> yes, but that depends on how you're managing your content
[21:34:52] <The_8472> so the content-provider has to choose a strategy that fits their business model
[21:36:10] <The_8472> if you distribute TV then mostly the newest episodes will be hot content and most users expect to get them asap
[21:36:47] <btcod2> right ... but then they will collaborate with each other
[21:36:51] <The_8472> if you do things more along the line of a video rental service then users will also expect the older stuff to be downloadable at reasonable speeds
[21:36:55] <btcod2> so, they don't really need a publisher to help
[21:37:15] <The_8472> if we lived in a world were everyone had symmetric internet connections...
[21:37:24] <The_8472> but we don't
[21:37:26] <btcod2> right
[21:37:45] <btcod2> well, they don't need a publisher in order to get the same as what they upload
[21:37:50] <btcod2> which could be considered "fair"
[21:37:56] <The_8472> yes
[21:38:16] <The_8472> but you can still throw more bandwidth at the swarm and it'll be able to absorb it
[21:38:30] <btcod2> yes
[21:38:41] <btcod2> well, antfarm accounts for that
[21:39:21] <The_8472> if a swarm is so heavily seeded that additional bandwidth will go unutilized then you can usually tell that from the seed:peer count
[21:39:28] <The_8472> at least you can make guesstimates
[21:39:39] <btcod2> so, i guess the publisher would need to trade between averge user satisfaction and minimum user satisfaction
[21:40:10] <The_8472> i guess so
[21:40:27] <btcod2> increasing the average of a swarm may degrade the quality perceived by the users downloading less popular content
[21:43:03] <The_8472> of course you can provide some minimal service to torrents with 0 seeds
[21:43:16] <The_8472> and once that is covered throw the remaining bandwidth at swarms based on a different metric
[21:43:36] <btcod2> right
[21:44:02] <The_8472> anyway, in the case of content providers its more a question of who you want to satisfy than achieving a mathematically optimal allocation of bandwidth
[21:44:04] <btcod2> does any client have flexibility to implement such schemes?
[21:44:27] <The_8472> on public torrents the optimal bandwidth allocation would be more interesting but less practical, so we simply go by heuristics like scrapes
[21:44:57] <The_8472> well, you can probably implement it in any open source client if you wanted
[21:45:48] <The_8472> azureus provides a plugin api for extending peer-peer messaging and to sort the seeding queue though
[21:54:30] <btcod2> thanks!
[21:58:28] <Nolar> <alus> the choker for a seeder uploads to peers who are downloading fastest  << not the heuristic ours uses btw
[21:59:22] <alus> Nolar: what does AZ use?
[22:00:45] <Nolar> as a seed, we upload to peers in round robin, spreading bw roughly equally
[22:01:01] <Nolar> (there are edge cases where that's not true for slow downloaders)
[22:01:04] <The_8472> the unchoker chokes the slowest peer though, for optimistics
[22:01:13] <Nolar> right
[22:01:19] <Nolar> better way of saying mine :)
[22:01:38] <The_8472> so it prefers faster peers until all are uploading equally fast
[22:01:49] <Nolar> well
[22:01:56] <Nolar> behavior is different when downloading vs seeding
[22:02:19] <The_8472> i think you and alus said the same, in different words xD
[22:02:30] <Nolar> not that i understand
[22:02:40] <Nolar> well maybe
[22:03:08] <Nolar> we try to upload to fastest peers
[22:03:15] <Nolar> per cycle
[22:03:36] <Nolar> but just because you're the fastest downloader one minute, doesn't mean you'll remain unchoked the next
[22:03:42] <alus> sure
[22:03:56] <Nolar> we cut you off and move on to uploading to another
[22:04:09] <Nolar> "fair" round robin - ish
[22:04:09] <alus> yeah, that's standard
[22:05:22] <Nolar> ok
[22:06:27] <Nolar> <alus> the choker for a seeder uploads to peers who are downloading fastest << in our case it's more of a watch-for-exceptionally-slow-downloaders
[22:07:03] <alus> well there's not much difference. except maybe you're spreading your upload too thin
[22:07:38] <Nolar> i.e. a peer downloading at 10KBs will get roughly equal unchoke time as one downloading at 1000
[22:08:19] <Nolar> (the latter getting 100x more bytes of course ;)
[22:08:29] <alus> pretending peers are symmetric or equally asymmetric, it's better to upload to one 100/100 peer than ten 10/10 peers
[22:09:35] <Nolar> yup, but that's a big pretend :)
[22:10:04] <btcod2> so, AZ divides time into slots and in each slot dedicates all its capacity to a single swarm?
[22:10:14] <btcod2> sorry, i didnt get it
[22:10:30] <alus> it's not that pretending which changes what you should do. you can't tell what a peer's upload rate is
[22:10:34] <Nolar> well, you're mixing peer vs swarm
[22:10:43] <btcod2> there are intra-swarm and inter-swarm  decisions, right ?
[22:10:43] <The_8472> they were talking about how to allocate upload bandwidth to indiivdual peers within a swarm
[22:10:47] <alus> and slower peers are not more likely to be symmetric. quite the opposite actually
[22:10:56] <Nolar> we were talking about uploading to peers within a single swarm
[22:11:30] <Nolar> for the most part, bittorrent heuristics are oriented to a single swarm
[22:11:38] <btcod2> so, for the intra-swarm decisions, time is divided into slots and the whole capacity is devoted to a single peer in each slot ?
[22:11:49] <The_8472> no
[22:11:53] <Nolar> vuze uses queue rules to handle multi-swarm seeding needs, but it's somewhat primitive
[22:11:54] <The_8472> there are several upload slots at once
[22:12:10] <btcod2> i see
[22:12:23] <Nolar> simplistically, say i can upload at 100KBs
[22:12:23] <The_8472> default is 4 slots, one of them rotates every 30 seconds
[22:12:43] <btcod2> once the number of upload slots is fixed, one rotates every 30 secons ... who is evicted ?
[22:12:44] <Nolar> if i'm on one swarm, i'll upload to 4 peers at 25KBs each
[22:12:54] <btcod2> i see
[22:13:09] <Nolar> if i'm on two swarms, i'll upload to 4x*2 peers, each getting 12.5
[22:13:33] <btcod2> got it
[22:14:03] <Nolar> so our seeding rules mostly controle how many parallel swarms we're playing in
[22:14:23] <The_8472> and which one gets started
[22:14:25] <btcod2> which is also a fixed parameter?
[22:14:43] <btcod2> the number of parallel swarms that are being served is fixed, right ?
[22:14:44] <The_8472> it's slightly dynamic, in case torrents do not ultilize the upload bandwidth
[22:14:54] <btcod2> ok
[22:15:19] <btcod2> what if there is only one peer in a swarm
[22:15:22] <Nolar> ya, it's rather dymamic actually
[22:15:32] <Nolar> depending on which of the 50million ways you configure the rules ;)
[22:15:39] <btcod2> oh!
[22:15:52] <Nolar> but most of the time it's "seed the needy"
[22:16:00] <btcod2> interesting
[22:16:03] <Nolar> which translates to "few seeds"
[22:16:26] <btcod2> alternatively, one could measure the download time of peers in swarms
[22:16:33] <Nolar> http://wiki.vuze.com/w/Seeding_Rules
[22:16:38] <btcod2> and devote more bw to the swarms in which peers are downloading slower
[22:16:46] <Nolar> yup
[22:17:00] <Nolar> but then you'd have to be passively participating in the swarm at all times
[22:17:06] <Nolar> i.e connected to peers
[22:17:13] <btcod2> yeah ... getting bitmaps
[22:17:40] <Nolar> (hmm, wiki page seems to be missing half the rules :)
[22:18:45] <btcod2> :)
[22:19:04] <The_8472> <Nolar> but most of the time it's "seed the needy" <- there's also a rule "seed swarms that are easy to seed"
[22:19:25] <btcod2> what does that mean?
[22:19:44] <The_8472> many more peers than seeds, even if there are many seeds
[22:19:53] <The_8472> a weighted delta more or less
[22:20:34] <The_8472> i.e. enough peers and not too many seeds so you can throw your bandwidth at the swarm without having to consider if it can absorb it or not
[22:21:00] <btcod2> well ... that seems a strong assumption to me
[22:21:31] <btcod2> # leechers >> # seeds doesn't seem to imply to me that the swarm is more in need of additional bandwidth
[22:21:48] <The_8472> it can absorb it.
[22:21:56] <btcod2> it depends on many factors, right ?
[22:22:03] <The_8472> not really
[22:22:19] <The_8472> most connections out there are asymmetric
[22:22:20] <btcod2> could there be a measurement based approach to see which swarms can absorb it better ?
[22:22:31] <The_8472> so if peers >> seeds then there's enough spare downlaod capacity
[22:22:46] <The_8472> not without participating in the swarm
[22:22:53] <The_8472> which is costly for peers to do
[22:22:57] <btcod2> they are asymmetric, but 1 ) people set caps  2 ) people are download content in parallel in different swarms
[22:23:32] <The_8472> download caps are still higher than their upload speed
[22:23:47] <The_8472> and downloading things in parallel doesn't change that they're asymmetric
[22:24:09] <btcod2> well ... my point is that even though connection is asymmetric
[22:24:27] <btcod2> in some swarms it might be that peers are uploading more than downloading
[22:24:43] <The_8472> not in swarms with seeds << peers
[22:25:16] <btcod2> well ... i dont have statistics about that
[22:26:30] <The_8472> neither do i, but i have experience ^^
[22:35:21] *** gui7 has quit IRC
[22:44:46] <DWKnight> btcod2: a lot of us that are here have been dealing with real-world bittorrent applied theory for at LEAST 5 years
[22:45:24] <DWKnight> we've SEEN this happen
[22:47:08] *** Elrohir has quit IRC
[22:49:24] *** _rafi_ has quit IRC
[22:56:18] <Nolar> http://remote.vuze.com/pairing/
[22:56:35] <Nolar> but i need a way to get rid of the error logs....
[22:58:18] <Nolar> if not, we have 3 options
[22:58:48] <Nolar> 1) i hardcode /pairing/ and /ui/, and every new mapping requires the same
[22:59:52] <Nolar> 2) i set doc root to www_vuze_com/remote/, but that means you cant access anything outside of /remote/, without calling www.vuze.com
[23:00:08] <Nolar> 3) we move this to a new remote_vuze_com project
[23:00:25] <Nolar> #2 and #3 are very similar
[23:00:44] <Nolar> oops
[23:00:48] <Nolar> lol
[23:00:59] * Nolar loves/hates fridays
[23:03:09] <alus> haha
[23:03:38] <Nolar> the secret is out ;)
[23:05:32] <alus> are you familiar with what uT is planning here?
[23:06:27] <jnpplf> Am I the 100000th person to say woooooo Alan Ellis?
[23:07:55] <K`Tetch> yes
[23:08:19] <K`Tetch> news is 6 hours old, hell it's even been on slashdot already - THAT is how old it is
[23:10:36] <jnpplf> I read it on my commute home :(
[23:10:48] <jnpplf> Still a good result
[23:11:14] <DWKnight> been around the internet and back again huh?
[23:11:24] <DWKnight> 12-0 verdict is kinda decisive
[23:11:50] *** JudgeSHAD0W has quit IRC
[23:14:22] <K`Tetch> anything other than 11-1 is a hung jury anyway
[23:14:33] <K`Tetch> or still in deliberation
[23:17:22] <Nolar> alus nope, but i imagine it's similar :)
[23:18:15] <Nolar> webui <--> client
[23:18:25] <alus> yup
[23:20:32] <Nolar> that's in the alpha?
[23:21:07] <Nolar> i cant keep track of all these uis
[23:21:09] * The_8472 is reminded of darwin's finches
[23:21:38] <Nolar> transmission, utorrent, iphone, andriod...
[23:22:00] <Nolar> finches?
[23:24:28] <swolchok> Nolar: that pairing feature scares the bejeezus out of me. Is it shipping?
[23:24:48] <alus> swolchok: why?
[23:24:51] <Nolar> ?
[23:24:53] <swolchok> alus: security>
[23:25:06] <Nolar> and yes, shipping with 4308 next week
[23:25:11] <alus> swolchok: you're worried someone will guess you 6 digit number?
[23:25:24] <swolchok> new feature in a fourth-order version # bump?
[23:25:25] <swolchok> wow
[23:25:30] <alus> swolchok: or you're worried someone will read your traffic while using the remote UI?
[23:25:41] <swolchok> alus: I'm worried it will take me 60 minutes or less to find a security problem. :)
[23:26:02] <Nolar> <swolchok> new feature in a fourth-order version # bump? <<< like the kernel, we just keep incrementing.  and occasionally get up the courage to bump up a major version ;)
[23:26:31] <swolchok> what part of the tree is it in?
[23:26:35] <alus> swolchok: well, you do know BT clients connect to tons of peers all over the place, right?
[23:26:38] <swolchok> updating my AzCVS now
[23:26:42] <swolchok> alus: so I've heard.
[23:26:51] <alus> swolchok: so why would a feature like this be worse?
[23:27:01] <swolchok> because it allows remote access to the system
[23:27:17] <Nolar> swolchok client code is in cvs, server code is not avail
[23:27:21] <alus> in a specified manner
[23:27:43] <alus> although I wonder
[23:27:51] <swolchok> Nolar: org/gudy/azureus2/pluginsimpl/remote?
[23:27:54] <alus> Nolar: does the AZ webui protect against CSRF?
[23:27:55] <Nolar> swolchok in our case, the 6 digit # is just a bootstrap.  everything else afterward uses proper security
[23:28:43] <Nolar> <alus> Nolar: does the AZ webui protect against CSRF? <<< i hope so, but i'm not the dev on that project
[23:29:10] <Nolar> parg is involved, so i would assume so ;)
[23:29:16] <alus> Nolar: point me in the correct direction, please. I would hate to spend the whole afternoon reverse engineering ;)
[23:29:32] <Nolar> to?
[23:29:41] <alus> parg, I suppose
[23:29:52] <Nolar> you have his email? :)
[23:29:58] <alus> lesse
[23:30:12] <swolchok> Nolar: or is it webplugin?
[23:30:14] <alus> I have the sf.net address
[23:30:39] <Nolar> swolchok not sure
[23:30:43] <Nolar> there's a lot of stuff
[23:30:55] <Nolar> pairing code in client is fairly new
[23:31:04] <Nolar> but we've had many webuis
[23:31:59] <Nolar> pairing != webui
[23:32:14] <Nolar> just a way to sync keys
[23:34:40] <alus> so what do you see after you pair?
[23:35:42] <Nolar> assuming it's all working, i believe you'll be directed to transmission-based webui served up by the client
[23:37:33] <Nolar> transmission webui -based
[23:40:00] *** hydri has quit IRC
[23:40:50] *** andar has quit IRC
[23:40:51] *** swinokur has quit IRC
[23:40:51] *** Gottaname has quit IRC
[23:44:44] <swolchok> I calculate pretty good success probability for an attacker who can guess 1000 6-digit codes if there are 1000 live codes at a time
[23:44:56] <swolchok> 63%
[23:45:12] <swolchok> had to pull ballpark numbers out of my rear, of course.
[23:45:57] *** mpl_ has joined #bittorrent
[23:46:31] <swolchok> It's only about 1% if the attacker can only guess 100 codes "quickly" and there are only 100 live codes.
[23:48:25] *** Firon_ has joined #bittorrent
[23:48:27] <Nolar> heh
[23:48:28] *** mpl has quit IRC
[23:49:03] <Nolar> not sure if they expire, but afaik we rate limit such queries on the server side
[23:49:19] *** mpl_ is now known as mpl
[23:49:22] <swolchok> per-IP rate limiting doesn't help against even a small botnet.
[23:49:33] <swolchok> for example, one with 1000 nodes :)
[23:49:47] *** rrr_ has quit IRC
[23:49:47] *** foomor has quit IRC
[23:49:48] *** burris has quit IRC
[23:49:48] *** Firon has quit IRC
[23:50:15] <The_8472> Nolar, have you ever tried azsmrc's web ui?
[23:50:40] *** foomor has joined #bittorrent
[23:51:05] <swolchok> uppercase letters and digits would make the password space over 2000 times bigger. lowercase and uppercase letters and digits would make it 56000 times bigger.
[23:52:47] <Nolar> i have
[23:52:47] <Nolar> nice
[23:53:14] <Nolar> we might make that compat too
[23:53:14] <Nolar> we've made the transmission webui and azwebui compat
[23:55:25] <Nolar> what exactly you are attacking though?
[23:55:25] <Nolar> you cant just guess  a 6 digit code and attach to someone's ui
[23:55:39] <swolchok> Nolar: then what's the point of the code?
[23:59:31] <Nolar> a human accessible method of exchanging crypto keys
[23:59:31] <Nolar> it's a one time verification code used to link the client to our server
[23:59:31] <Nolar> like bluetooth :)
[23:59:55] <swolchok> I need more specifics.





top