[01:04:32] *** alus has joined #bittorrent
[01:08:57] *** Andrius has quit IRC
[01:44:43] *** bt42 has joined #bittorrent
[01:47:53] *** bittwist has quit IRC
[01:49:42] *** gnarkill has joined #bittorrent
[01:49:51] <gnarkill> bramm: http://www.pastebin.org/84745
[01:50:19] <gnarkill> bramm: freenode won't screw with services for an important project lead, but they'll surely do it if you pay them!
[01:50:37] <gnarkill> protip
[02:08:53] <bramm> gnarkill: yech
[02:09:11] *** kwinz2 has quit IRC
[02:09:47] <bramm> I wouldn't do that in principle
[02:10:12] <The_8472> note that this was about a ## channel, not a # one
[02:10:23] <The_8472> they're quite adamant about the distinction
[02:10:59] <The_8472> i.e. it might require a higher donation ^^
[02:11:22] <bramm> the_: no writeups yet, erdgeist did say that when doing https the amount that the tracker can handle goes down to like 1% of what it was otherwise
[02:11:51] <bramm> I wonder what happened to my autocomplete, maybe that's an option I have to turn on
[02:13:17] <bramm> after discussing it at the conference I'm more convinced than ever that share mode is a good idea
[02:13:31] <The_8472> what is a share mode?
[02:13:40] <bramm> but how to present it to the broader community is an open question
[02:14:03] <bramm> share mode is a mode where the client downloads just enough data to keep uploading full bore
[02:14:30] <bramm> it isn't implemented yet, just an idea we've been kicking around for a while
[02:15:04] <bramm> it has two benefit (1) it helps people who want to improve their share ratio do so, and (2) it makes it possible for download speeds on even very young torrents to be fast
[02:15:15] <The_8472> uhm. that would only seem necessary if a client has nothing to seed. which means people are probably removing torrents immediately after finishing the download so they don't "have to" seed...
[02:15:59] <The_8472> oh... you mean some special seed-slave kind of thing. for dedicated but secondary seeds?
[02:16:07] <bramm> frequently everything someone has is completely overseeded already, and not much uploading can be done for it
[02:16:21] <The_8472> that's only true for private trackers
[02:16:34] <The_8472> and who gives a shit about those, they create their own problems
[02:17:11] <The_8472> i have about 900 torrents in my queue, i could probably pump 1 Gbit into them and still have some torrents left that i'm not seeding..
[02:17:12] *** neurodrone is now known as neurodrone_
[02:17:30] <bramm> it's helpful even for completely public things - they do eventually get overseeded, and by the nature of the protocol there's more need for upload early on because aggregate download = aggregate upload, and if someone just starts downloading they're sucking down as many resources as they're using until they finish
[02:18:16] <bramm> well yes, it's most helpful for private trackers, but past experience indicates that explaining the laws of physics to the is sometimes futile
[02:18:30] <The_8472> <bramm> it's helpful even for completely public things - they do eventually get overseeded <- i have yet to see a public torrent getting so overseeded that you can't throw upload bandwidth at it. it almost never happens.
[02:19:04] <The_8472> [...]but past experience indicates that explaining the laws of physics to the is sometimes futile <- so true :)
[02:19:21] <bramm> when a torrent first becomes available you may wish to help everyone else's download speeds. If you simply start downloading it, you don't help with that until you finish
[02:19:35] <bramm> also, we do want to help serve private trackers, even if they're sometimes misguided
[02:19:52] <The_8472> you still help by increasing the baseline availability. you just don't help speed-wise.
[02:20:05] <DWKnight> [9:21:26pm] <bramm> also, we do want to help serve private trackers, even if they're sometimes misguided <-- broke one of my weaker understatement meters
[02:20:13] *** sam has joined #bittorrent
[02:20:43] <The_8472> private trackers need different fixes. improved queueing mechanism so that people don't have to keep hundreds of torrents active. some kind of push mechanism to wake up torrents maybe. we have that in Az as custom tracker extension iirc
[02:20:47] <The_8472> mostly for CDNs
[02:21:02] <bramm> sure you do, if you download 1% of a file and upload a complete copy, then you've made 99% of the files size more resources available for everyone else than if you'd downloaded 100% and uploaded 100%
[02:21:58] <bramm> the fear is that if we don't spin share mode properly, private trackers might see that some n00bs use it to get positive share ratios and decide that it's a form of cheating
[02:22:19] <The_8472> yeah, but i doubt many people would do that, except dedicated seeders. and they operate differently. a distribution group i shall not name here simply has 1 seedbox that spreads it to N seedboxes and only after that N boxes have the copy the torrent goes live
[02:22:35] <The_8472> they all have stuff like 100/100 or at least 10/10
[02:22:56] <The_8472> so dedicated seeders are exactly those people who don't need this
[02:23:31] <bramm> well that distribution group could do much better with everyone running in seed mode - they'd be able to make the complete file available right away, and still have their seed boxes going full bore
[02:23:51] <bramm> so it speeds up launch times
[02:24:08] <The_8472> i think the cheating thing is a non-issue. private trackers even give out free leeches just so people can build up ratios. they know (well, a few do) that the ratio system is quite flawed and work around that.
[02:24:36] <The_8472> but really, if you want to fix private trackers then this is the wrong approach. improved ratio accounting and some extension to queueing behavior in clients would work way better there.
[02:24:44] *** kwinz2 has joined #bittorrent
[02:25:16] <The_8472> if you have 100Mbit boxes in seed mode you get piece distribution hotspots. which can create a problem for newcomers
[02:25:28] <The_8472> *partial seed mode
[02:25:58] <bramm> hmmm, yes, a different approach may make sense then
[02:26:40] <bramm> actually, for the seed boxes case the hack of setting max download rate to a specific fraction of current upload rate is probably the right solution
[02:26:57] <bramm> the bittyrant people I think mentioned having that feature
[02:27:15] *** neurodrone_ has quit IRC
[02:27:17] <The_8472> uh, i think there's even a plugin for Az to achieve that
[02:27:38] *** neurodrone has joined #bittorrent
[02:28:01] <The_8472> but really, seed boxes finish gigabyte torrents in less than an hour. so it's really a non-issue for them. and i somehow don't see regular users on public torrents using such a feature
[02:28:15] <The_8472> which leaves private trackers.... and those need a whole bunch of other fixes.
[02:28:44] <bramm> but public torrents frequently don't have sufficient seeding early on
[02:29:23] <The_8472> well, not sufficient to max out everyone's download. but enough to keep the swarm alive
[02:29:29] <bramm> they have sufficient seeding to scale, certainly, because everybody's uploading, but not enough to max out downloads
[02:29:40] <The_8472> but i don't see why anyone would lower their download speed even further just so that others can download faster
[02:29:51] <bramm> share mode could make it possible for downloads to be fast early on
[02:30:08] <The_8472> only for those who don't use share mode ^^
[02:30:21] <The_8472> i do not see any incentives to use it here
[02:30:25] <bramm> maybe because there isn't anything they themselves are actively downloading at the time, and they want to contribute constantly
[02:30:37] <bramm> share mode isn't a way of downloading, it's a way of contributing
[02:31:07] <The_8472> then you'd basically have to download torrents at random (DHT sampling or whatever), join them in seed mode and then leave once the torrent is healthy
[02:31:48] <The_8472> but an easier approach would be getting people to actually keep torrents in their seeding queue
[02:31:54] <The_8472> and then schedule those who need it the most
[02:32:39] <The_8472> i mean you could only do share mode if there's nothing else to seed... and if that's the case something alread went "wrong"
[02:32:42] <The_8472> *already
[02:32:57] <bramm> you could decide which ones to get from from an RSS feed, and seed mode my definition automatically stops downloading once the swarm is healthy
[02:33:30] <The_8472> <The_8472> i mean you could only do share mode if there's nothing else to seed <-
[02:33:39] <The_8472> fix that problem instead
[02:33:53] <bramm> yes, detecting of old stuff which needs help to improve longevity is another issue
[02:35:03] <The_8472> it's actually the same issue. one of redistributing a finite amount of upload bandwidth between the two conflicting goals of content retention and speedy distribution of new content
[02:36:04] <The_8472> you're tinkering on the wrong end. people use their upload bandwidth improperly by either downloading 15 torrents at once and thus only providing a trickle of upload to each torrent
[02:36:07] <bramm> but share mode can improve speedy distribution of new content beyond what's available now
[02:36:23] <The_8472> or they're quitting after downloading, not seeding at all
[02:36:39] <The_8472> or they're seeding rather healthy torrents when they have different ones in their queue that could use it more
[02:36:55] <The_8472> there are so many things to improve...
[02:37:12] <bramm> quitting after downloading isn't particularly a problem for either if you come back again later
[02:37:37] <The_8472>  <bramm> but share mode can improve speedy distribution of new content beyond what's available now <- you're assuming idle upload bandwidth. the very existence of idle upload bandwidth points at a different problem. that's what i'm saying
[02:37:50] <bramm> generally speaking uploading right after downloading is the least helpful time for longevity
[02:38:03] <bt42> no
[02:38:06] <The_8472> but it helps keeping the initial distribution speedy
[02:38:06] <bt42> short time seeders are
[02:38:10] *** Switeck has joined #bittorrent
[02:38:45] <bramm> no, when content first becomes available share mode can make it download faster than otherwise
[02:39:05] <The_8472> if you keep on seeding right after the download finishes you'll keep things speedy for those who started after you did. it's not like everyone is starting the same torrent at the same time.
[02:39:19] <bramm> and there are tons of people out there who only download stuff once in a while, and they really don't have much content to upload
[02:39:47] <bramm> sure they do - every piece of content gets a big bump at the beginning and then rapidly becomes problematic
[02:40:10] <The_8472> problematic? nah. popular content survives for months
[02:40:17] <The_8472> maybe not at max speed, but it survives
[02:40:29] * The_8472 is currently downloading a 4 year old torrent
[02:40:42] <bramm> bt42, it isn't so much the amount of time seeding as the distribution of time seeding - everybody does it for a short period of time after the initial bump, if they were spread out more it wouldn't be a problem
[02:41:31] <bramm> the fact is that someone who hops on and only is interested in downloading one thing which is eons (or even worse, just a few days) old will simply not be able to upload as much as they download on that one torrent
[02:41:53] <The_8472> that's not true
[02:42:06] <bt42> as long as there is new folks coming onto it, thats not true
[02:42:25] <bt42> and if they are the last ones, it does not matter then does it
[02:42:36] <The_8472> due to asymmetric connections you can even throw tons of bandwidth at a torrent with 200 seeds and 100 peers.
[02:42:37] <bramm> but there generally aren't - there's a rapid decline after the initial push, and lots of seeds linger for a while
[02:43:16] <bramm> but you can't contribute much when nobody else is downloading
[02:43:17] <The_8472> experience on public torrents tells me otherwise. the seeds basically follow a time-delayed version of the peers curve
[02:43:19] <bt42> bramm: i was only referering to what i consider to be torrent longevity, how long the swarm exists as a whole
[02:43:23] <bramm> which is the case for most stuff which winds up dead
[02:43:35] <The_8472> <bramm> but you can't contribute much when nobody else is downloading <- that is only the case for very very old torrents, close ot the end of their lifecycle
[02:43:37] <bt42> if they are the ones at the end, they should know their place and continue to seed
[02:43:56] <bramm> I'm not so interested in 'should'
[02:43:58] <bt42> really the focus is not on ratio but just keeping the bugger alive
[02:44:07] *** kwinz2 has quit IRC
[02:44:14] <The_8472> during pretty much any other point in the lifecycle you can throw tons of bandwidth at a torrent and it'll suck it up.
[02:44:17] <bramm> and I don't understand why you guys are poo-pooing improving speed of download of new stuff so much
[02:44:30] <bramm> speed of download matters to users
[02:44:33] <bt42> ?
[02:44:35] <bt42> who said i was
[02:44:50] <bramm> okay, maybe you didn't bt42
[02:45:13] <Switeck> If you increase speed of uploading, shouldn't speed of downloading take care of itself?
[02:45:26] <The_8472> i'm saying that there are more important things to do. your share mode implies that there is unused bandwidth. i'm saying that this unused bandwidth shouldn't be there in the first place.
[02:46:17] <bramm> switeck: when something first becomes available there's this problem that everybody who tries to upload downloads themself, so they aren't net contributing until after they're done downloading
[02:46:46] <bramm> okay then, ignoring the unused bandwidth problem, what's wrong with allocating bandwidth to improving download speeds?
[02:46:57] <Switeck> I've seen feast-or-famine download/upload results due to a very slow seed...both early and late in a torrent's life-cycle.
[02:47:28] <Switeck> A problem that uTorrent ran into was estimation of OVERHEADS, mostly caused by TCP SYN-ACK packets.
[02:47:30] <The_8472> bramm, well... then the question is... could this bandwidth not be used elsewhere?
[02:47:34] <bramm> being bottlenecked on the seed is a different problem - for that all you can do is make sure that the piece selection algorithm isn't busted
[02:48:01] <The_8472> or that the clients aren't seeding too many torrents at once
[02:48:11] <The_8472> misconfigured clients is a far more serious problem
[02:48:17] <Switeck> If the overheads are counted against the limit and uTorrent is allocating bandwidth to improve download speeds...if upload speed max is set low, then ALL the upload speed is devoted to overheads -- NONE to uploading to peers.
[02:48:44] <The_8472> then the upload limit is too low
[02:48:57] <The_8472> the problem isn't caused by the overhead accounting. it's caused by stupid settings
[02:49:05] <The_8472> as usual
[02:49:11] <bramm> any upload bandwidth you provide helps - other people seeding can just allocate that upload elsewhere
[02:49:21] <Switeck> There are people on 10:1 and worse ratio lines that can trigger that easily even without stupid settings.
[02:49:47] <Switeck> If the overheads are not counted against the limit, the overheads plus a high upload max could lead to line overload...
[02:49:54] <The_8472> if that were the case then ACKs would congest their uplink either way, wether you account for them or not
[02:50:16] <bramm> the solution to the max upload problem is to use UTP
[02:50:33] <The_8472> if we had symmetric connections or SSM all this wouldn't be a problem *sigh*
[02:50:36] <Switeck> Much of the point of limits on upload speed in the first place is to prevent congestion...uTorrent's uTP bandwidth regulation is there to "combat" it.
[02:50:53] <Switeck> I disagree! Even symmetric connections would have the issue in lesser degree.
[02:51:01] <The_8472> no, they wouldn't
[02:51:05] <bramm> you just plain don't need to set a max upload rate if you're just using UTP
[02:51:37] <bramm> because it never causes serious congestion, even while uploading full bore
[02:51:47] <The_8472> utp is a nice idea, but at the wrong level. it needs to be plugged into TCP instead of everyone reinventing the wheel (TCP) ontop of UDP over and over and over
[02:52:08] <bramm> we're working on that, getting it through the standards process with LEDBAT
[02:52:17] <The_8472> congestion controller good, yet-another-UDP-transport bad
[02:52:40] <bramm> well it's the only option we have, and we're actually doing it well, and we're working on getting it into TCP
[02:52:42] <The_8472> someone needs to whip the m$ and lunix kernel devs though ^^
[02:52:53] <Switeck> News flash -- uTorrent runs horribly if you don't set an upload speed max even with uTP.
[02:53:00] <bramm> yes, it's called the IETF
[02:53:43] <Switeck> Its estimation for how many upload slots to use, how fast each upload slot runs, and even chokes/unchokes go into fibrillation.
[02:53:46] <bramm> switeck, we're tweaking that - the problem is the interaction between TCP and UTP, if you only have UTP then everything works great
[02:54:18] <Switeck> I've tested with straight uTP before as well, the problem still occurs just to lesser degree.
[02:54:51] <Switeck> uTP apparently causes uTorrent to come to ridiculous upload max limit estimates.
[02:54:58] <bramm> although the bittyrant guys said that in their tests running multiple things using UTP causes weird behavior, which doesn't make much sense because congestion control is per connection, we'll have to investigate further
[02:55:20] <The_8472> anyway, bramm... that share mode is basically barking up the wrong tree. There's nothing wrong with it per se... it's just that there are so many other related things that could be improved
[02:55:21] <bramm> switeck, there is no max limit estimate when you're using utp
[02:55:52] <Switeck> There has to be something like that, because of uTorrent's estimate for allowed upload slots.
[02:56:18] <The_8472> µT is regulating upload slots dynamically?
[02:56:20] <bramm> oh, we just rewrote that code, it soon won't calculate upload slots that way
[02:56:22] <Switeck> The BitTyrant guys are still around?! o.O
[02:56:34] <bramm> yes, they're at U Washington
[02:56:42] <Switeck> Yes, uTorrent regulated upload slots dynamically.
[02:56:46] <Switeck> ...sometimes poorly.
[02:56:59] <The_8472> it's a horrible thing to do imo.
[02:56:59] <bramm> the current uT choking algorithms suck
[02:57:10] <bramm> what is a horrible thing to do ?
[02:57:20] <The_8472> dynamically adjusting the # of upload slots
[02:57:31] <bramm> why?
[02:57:56] <Switeck> "alllow additional upload slots if upload speed <90% max" has been in uTorrent for a LONG time.
[02:58:18] <The_8472> because increasing the number of upload slots means you upload less per slot. so you basically get unchoked by a slower set of peers
[02:58:29] <Switeck> But...there is also another upload slot limiter. One that prevents upload slots per torrent going over 1 if upload speed is very low.
[02:58:36] <The_8472> you cannot really predict whether it's good or bad to be unchoked by more but slower peers or fewer but faster ones.
[02:59:27] <The_8472> and if everyone does this you can basically end up with a low equilibrium of many slow unchokes instead of fewer fast ones
[02:59:38] <Switeck> In a large swarm, is it better to upload to a single leech at your max speed (even though you easily can) knowing that leech cannot also upload to the swarm at the same speed...instead of few but multiple peers at once?
[03:00:00] <The_8472> a single one is not necessary, no
[03:00:45] <The_8472> but keeping the # of slots constant means the speed per slot is higher when your overall upload is higher. which in turn means you will also be unchoked by faster peers
[03:00:50] <bramm> having a fixed number of slots sometimes makes you upload to peers which aren't reciprocating at all
[03:00:52] <Switeck> I'd think uploading to a peer considerably faster than it can also upload to others implies the same kind of results, just to a lesser degree.
[03:00:54] <The_8472> because over time peers tend to seek out their equals
[03:01:10] <The_8472> bramm, sure... that's what optimistics and all is good for
[03:01:17] <bramm> you're being simplistic about it, you have current information of how quickly peers are uploading to you, you can use that
[03:01:38] <Switeck> not even optimistics! If you have 4 upload slots, you upload to 4 peers regardless of them returning the favor.
[03:01:44] <The_8472> if they use the same algorithm as you do that information is not worth much
[03:02:08] <bramm> the currently deployed uT code does something really stupid, we just rewrote it to be better
[03:02:10] <The_8472> Switeck, sure. but they'll soon be dropped for a better one
[03:02:32] <Switeck> ...not if you're a seed OR peer with few pieces the swarm is interested in.
[03:03:30] <Switeck> (maybe i got that backwards for the peer...)
[03:03:36] <The_8472> if you're a seed there's nothing you can do anyway.
[03:03:44] <The_8472> seeds have 0 information about fairness within the swarm
[03:03:45] <Switeck> A peer with high % complete would find few other peers to download from.
[03:04:15] <Switeck> 1 partial exception to that is super seeding/initial seeding.
[03:04:28] <The_8472> yes, but they should preferably unchoke peers they're interested in
[03:04:36] <Switeck> But it's a clever kludge more than a solution... :P
[03:05:34] <The_8472> anyway, my point is that dynamically adjusting the # of upload slots doesn't have straight-forward results. and if implemented badly by many peers in a swarm can lead to a low-equilibrium where the bandwidth waste due to overhead is much higher
[03:05:45] <Switeck> In my observations, tit-for-tat can be a rare event rather than the norm for a torrent swarm -- due to it being end-of-life.
[03:05:47] <The_8472> so i see little value in doing it
[03:06:18] <The_8472> yeah, many things can break down at the end of the life cycle
[03:06:22] <bramm> well yes, it's easy to do wrong, but we did something very conservative for it which has nice behavior
[03:06:24] <The_8472> but that's not where the bulk of transfering happens
[03:06:36] <Switeck> Even a fixed upload slot value of 4 with decent upload speed might be "slow" at propagating 4 MB pieces if every peer and seed connects to 100+ other peers.
[03:06:49] <bramm> you can also be dynamic with seeding
[03:07:14] <Switeck> I suggested not uploading at all on many torrents when upload speed is set too low.
[03:07:27] <The_8472> yes, but less than 4 means that you're focusing on fewer peers. so you might be selecting some leech at random. doesn't imrpove things either
[03:07:54] <The_8472> Switeck, yes. a minimum upload speed per slot should be maintained
[03:07:54] *** _rafi2_ has joined #bittorrent
[03:08:13] <The_8472> there's no point in running/uploading dozens of torrents with 0.1KiB/s/slot
[03:08:28] <Switeck> To preserve that minimum upload speed per slot, about the only thing that can be done is reduce below 4 upload slots per torrent.
[03:08:45] <The_8472> ... or run fewer torrents
[03:08:47] <Switeck> ...people won't use your client if instead you return 'excess' started torrents to queued state.
[03:09:10] <Switeck> You have to cater to the leeches somewhat.
[03:09:19] *** kwinz2 has joined #bittorrent
[03:09:24] *** _rafi_ has quit IRC
[03:09:46] <The_8472> you can make it the default setting though. and make other settings with consistency checks and warnings to harass them ^^
[03:10:09] <Switeck> by warnings, you mean pop-up windows?
[03:10:13] <The_8472> yes
[03:10:31] <Switeck> Expect a dropping client share if you do that too. :(
[03:11:05] <The_8472> just because there's a popup and a small wall of text when you change specific settings?
[03:11:08] <The_8472> i doubt that
[03:11:22] <Switeck> Where have you been on the internet for the last 10 years? XD
[03:11:33] <Switeck> MANY People don't like nag-ware and pop-ups.
[03:11:47] <The_8472> it's not like if it's asking for donations oO
[03:11:59] <The_8472> it's a warning mesasge about potentially harmful settings ^^
[03:12:01] <Switeck> If your client also steals focus, they will get out pitchforks and torches.
[03:12:04] <The_8472> you just have to phrase it properly
[03:12:30] <The_8472> that popup would only occur when you hit the save button on changing a critical setting, d'uh
[03:12:38] <The_8472> not in the middle of something else
[03:12:57] <The_8472> call it a modal confirmation/warning dialog instead of a popup then ^^
[03:13:00] *** chelz has joined #bittorrent
[03:13:01] *** chelz has joined #bittorrent
[03:13:01] <Switeck> Some of the settings combos being bad can be the results of conditions as well.
[03:13:17] <Switeck> a blinking red icon might help...
[03:13:22] <The_8472> some settings are just stupid
[03:13:34] <The_8472> those can be easily detected and users educated...
[03:14:01] * The_8472 starts a bittorent re-education camp
[03:14:14] <Switeck> Private trackers, where people try to leave many torrents started (but generally idle) is an example where people are acting against common sense because of the skewed rules.
[03:14:44] * The_8472 yells "Bubba, bring me the car battery and the bed frame"
[03:14:45] <chelz> against common sense of bt alone, but not for the game of bt + private trackers
[03:14:47] <Switeck> Giving them more sense won't help those rules.
[03:15:08] <chelz> oh, well yeah the rules of private trackers could/should be refined
[03:15:14] <The_8472> a lot
[03:15:46] <Switeck> chelz, a torrent client that scrapes often and dynamically starts/stops torrents to suit demand might work -- but it could risk keeping constant-demand torrents active and neglect low demand ones.
[03:16:07] <DWKnight> thrown out the window (of the observation floor of the cn tower) and rebuilt from scratch
[03:16:36] <chelz> Switeck: i thought about some kind of system unique to private trackers where the tracker itself sends out delegations of seeding 'duties' and users trust it to be fair, and give good ratio to all
[03:16:58] <Switeck> A few private trackers limit the number of torrents you're updating at once. Others give credit for availability time even if you seeded little-to-nothing.
[03:17:15] <Switeck> that concept should not be unique to private trackers...
[03:17:24] <The_8472> Switeck> chelz, a torrent client that scrapes often and dynamically starts/stops torrents to suit demand might work -- but it could risk keeping constant-demand torrents active and neglect low demand ones. <- in Az we have an event-driven method of starting torrents. we can bump the scrape up if we detect an incoming connection for an inactive torrent. but that requires trackers supporting this feature so they can hand out IPs of stand-by peers
[03:17:31] <Switeck> a public tracker with many torrents still needs help.
[03:17:45] <chelz> almost like writing a genetic algorithm, where you have to determine fitness measures to track the evolution; depending on what private tracker admins want, they need to setup proper rules to get it
[03:18:08] <Switeck> The_8472, yes that's probably a good idea.
[03:18:38] <Switeck> Getting "help" from private tracker admins amounts to them making feature demands. :P
[03:19:10] <Switeck> Ask big public tracker admins as well.
[03:19:56] <The_8472> the opentracker guys are fairly reasonable. they make their own standards proposals and don't really make demands. more like pleas for support
[03:20:01] * The_8472 pats erdgeist
[03:20:06] <Switeck> Good to hear :)
[03:22:35] <chelz> almost all private trackers are running xbtt i think, with tbdev and all. practically all of them if gazelle uses xbtt too.
[03:28:08] <The_8472> it's not the private tracker tracker devs that make the trouble, it's those people who run private tracker sites that do
[03:28:22] <Switeck> good point XD
[03:29:10] <Switeck> Are some/most trackers handing out only unfirewalled ips?
[03:29:21] <chelz> a lot of times i'd wager they don't know any better and just go with the defaults though
[03:29:32] <Switeck> And are some/most trackers handing out only peer ips to seeds?
[03:29:45] <DWKnight> [10:31:01pm] <Switeck> Are some/most trackers handing out only unfirewalled ips? <-- very few
[03:29:57] <DWKnight> [10:31:23pm] <Switeck> And are some/most trackers handing out only peer ips to seeds? <-- definitely, not sure how many though
[03:30:10] <K`Tetch> The_8472 - yeah, most dont have a clue what they're talking about
[03:30:25] <K`Tetch> and then you have sites like The Pirate Society, who reinforce the bad settings as 'what you must do'
[03:30:52] <Switeck> K'Tetch, examples?
[03:31:58] <Switeck> The thing I hear from private tracker settings requirements is to disable DHT and Peer Exchange...and Local Peer Discover if they know about it.
[03:32:09] <K`Tetch> go join TPS
[03:32:14] <Switeck> f-no!
[03:32:23] <K`Tetch> they have the whole 'use these settings in the advance prefs of utorrent' thing
[03:32:49] <K`Tetch> I can't give you too many examples, I pissed too many site admins off calling them ont heir stupid stuff and got banned
[03:32:52] <Switeck> If they're such a bad idea, joining them feeds bad habits.
[03:33:19] <K`Tetch> I did include one of their site reps on the DHT myths piece I worked on a few months back
[03:33:36] <bramm> why the fuck would you only hand out peer ips to seeds?
[03:33:55] <DWKnight> why the fuck would you hand out another seed to a seed?
[03:34:27] * DWKnight knows where Switeck was going with that thought
[03:34:31] <K`Tetch> "Not all torrent clients respect the private flag. But if you are using a client like Vuze, uTorrent or similar if the private flag is on (set by the tracker) the DHT, peer exchange settings etc are ignored. However, if you are using something like BitComet, BitLord or their ilk they ignore the private flag so if you have DHT etc enabled it is going to be enabled no matter what." <-- pornbits+empornium site admin
[03:35:23] <Switeck> Private trackers, 100+ seeds per torrent, very few peers. Tracker handing out seed ips to seeds might not even *GIVE* a peer ip out because it gets lost in the noise. So seeds spam-retry other seeds...and that doesn't work well.
[03:36:21] <chelz> K`Tetch: that's some crazy misinformation.
[03:36:28] <K`Tetch> I know
[03:36:44] <chelz> also how likely is it really that a private torrent gets uploaded somewhere else and starts gathering peers if there's no seed
[03:38:25] <bramm> dwknight, we're parsing it differently, I'm parsing it as (hand out peer ips (to seeds))
[03:38:37] <bramm> as in, not handing peer ips to other peers
[03:38:54] <DWKnight> apparently
[03:38:56] <bramm> but maybe I just misunderstood the original comment
[03:39:14] <Switeck> yeah
[03:39:20] <DWKnight> his point (and what the intention of the original comment was) don't give seeds the information for other seeds
[03:39:23] <Switeck> of course peer ips need to be handed out to other peers.
[03:39:31] <DWKnight> which you can probably agree is a good optimization to make
[03:39:39] <Switeck> If a seed suddenly becomes a peer again, 1 tracker update will correct that
[03:47:16] *** neurodrone has quit IRC
[03:49:07] <chelz> also peer exchange is handling that data anyway
[03:49:59] *** neurodrone has joined #bittorrent
[03:50:54] <Switeck> Does PEX have any means of reporting now-dead ips that it was previously handing out? Or is that considered too vulnerable to attack?
[03:55:02] <Switeck> BearShare/Gnutella used to use Neg-Alt-Locs to remove dead/bad entries.
[03:56:04] <alus> PEX does send a notification that a connection was lost
[03:56:44] <alus> DWKnight: uT does not send seeds to seeds via PEX
[03:57:56] <bramm> I wonder what the chances might be of xbtt supporting uhttp
[03:58:10] <bramm> the extant httpu is kind of a non-starter - it has no anti-smurfing protection
[03:58:14] <Switeck> BT clients individually should have ever-increasing retry times (and eventually drop) dead ips on their own.
[03:59:07] <alus> they do have ever-increasing retry times
[03:59:21] <alus> but what's the point in dropping IPs if you have no other IPs to hit?
[04:00:22] <Switeck> what's the point of retrying dead ips as fast as possible? XD
[04:00:32] <alus> it doesn't retry them as fast as possible
[04:00:48] <alus> it retries them at the longest retry interval
[04:01:01] *** The_8472 has quit IRC
[04:01:43] <Switeck> perhaps true of uTorrent and BitTorrent clients, but the others...maybe not so true :(
[04:02:16] <Switeck> I've seen BitComet, Transmission, and Opera retry my ip at stupid rates.
[04:02:28] <alus> so file a bug with them
[04:02:33] <Switeck> (Transmission doesn't seem to do that anymore)
[04:02:45] <Switeck> ...because I have contacted the devs over that.
[04:04:14] <DWKnight> BC probably won't listen
[04:05:52] <Switeck> BitComet devs have a language barrier.
[04:06:28] *** The_8472 has joined #bittorrent
[04:07:29] <Switeck> On a different subject, uTorrent defaulting to not logging much of anything is incorrectly giving people the impression nothing is wrong. :(
[04:08:45] <alus> or, is uTorrent defaulting to not logging much of anything incorrectly giving you the impression that something is wrong?
[04:09:13] <Switeck> Best example is incoming connections...
[04:09:26] <Switeck> people are firewalled and not know why.
[04:09:55] <Switeck> yes, alus that's true too.
[04:09:57] <alus> and you think they will look at the logger tab?
[04:10:12] <Switeck> yes
[04:10:48] <GTHK> Makin' the icon say "OK" on a single holepunch doesn't do a whole lot for helping people find out they're firewalled.
[04:10:55] <Switeck> The ones that have bothered to register with uTorrent forums, read the troubleshooting threads, AND make a coherent post about their problems indeed might look at logger.
[04:11:20] <Switeck> the rest I'm not likely to "see" anyway.
[04:11:51] <alus> I think holepunches don't light the light
[04:11:54] <Switeck> Likewise, if they're not firewalled on TCP but are on UDP...
[04:12:25] <GTHK> Did several times for me while I was in Illinois.
[04:12:48] <alus> I dunno. upnp and nat-pmp help a lot. hole punching works.
[04:13:13] <alus> anything else might be more annoying in pestering them than helpful in making the network better
[04:13:28] <Switeck> that's what yellow is for instead of red
[04:13:45] <alus> there are just going to be some people that can't or don't know how to open up a port
[04:13:55] <Switeck> yes
[04:14:18] <Switeck> BitTornado had a checkbox to disable the light for those "hopelessly firewalled" people. :P
[04:14:42] <Switeck> unchecked by default, of course.
[04:14:52] <GTHK> Some might be able to open a port, but see the green ok and never think twice about it. Yellow/red lets people know what's up, or did anyway..
[04:14:55] *** Stremma has joined #bittorrent
[04:15:05] <alus> "did"?
[04:15:16] <Switeck> yes, "did"
[04:15:22] <Switeck> as in, it doesn't now.
[04:15:26] <alus> why not?
[04:15:55] *** rot has joined #bittorrent
[04:16:13] <Switeck> they get 1 hole-punched uTP connection, light turns green...but their connectivity still stinks.
[04:16:43] <GTHK> Litterally one on one torrent I ran.
[04:17:09] <alus> well, holepunching lighting the light is just a bug
[04:17:32] <alus> but it's pretty neat that holepunching is working so well
[04:22:20] <Switeck> that bug needs to be fixed before uTorrent v2.0 goes final :(
[04:23:02] <Switeck> mouse-over on the light could also reveal if only TCP or UDP is firewalled by uTorrent's best guess.
[04:23:51] <GTHK> If it hasn't already, back home I can actually forward. But not UPnP, DD-WRT made that even more faily and now the forwards drop after a moment.
[04:24:32] *** TheSHAD0W has joined #bittorrent
[04:24:33] <Switeck> I am reasonably sure many networking setups have unreliable UPnP support.
[04:24:51] <semaphore> i don't trust upnp much
[04:24:57] <GTHK> Older version of dd-wrt worked ok, as long as you didn't map an already manually forwarded port.
[04:25:05] <Switeck> I trust it by disabling it.
[04:25:09] <GTHK> I gave up on it completely, I just like updating and seeing it fail even more XP
[04:25:11] <semaphore> right
[04:25:11] <alus> UPnP is fine, it's the crappy firmware makers that can't write anything correctly
[04:25:26] <alus> they can't even write NAT properly
[04:25:38] <GTHK> Hm, wonder how tomato would do, curse this v6 pos.
[04:25:51] <alus> it's hilarious that dd-wrt is bad too
[04:25:54] <alus> losers
[04:25:58] <Switeck> That's why router tests were showing partial fails with connections even before 200 connections at once. (Some of the failures were transparent to the users.)
[04:26:48] <GTHK> I tried the "latest stable", haven't tried the "recommended" RC whatever. Mebbe I'll muck with it more once I have a suitable replacement.
[04:27:42] <Switeck> An ever-increasing problem is people with ADSL modem-routers or people whose connection passes through a VoIP router -- they're double-NATed and a total pain to forward.
[04:29:01] <The_8472> <alus> DWKnight: uT does not send seeds to seeds via PEX <- uh... what? you should use the seed flag for that so peers can maintain an accurate view of the swarm...
[04:30:25] <alus> The_8472: err, that's how it does it
[04:30:38] <alus> The_8472: same effect in terms of the optimization they were talking about, though
[04:30:38] <The_8472> <alus> UPnP is fine <- upnp is a horrible franken-protocol though
[04:30:46] <The_8472> good good
[04:30:53] <alus> The_8472: but UPnP can work in practice.
[04:31:04] <alus> The_8472: the problem is not under-specification ;)
[04:31:17] <alus> I've seen just as many NAT-PMP problems
[04:31:29] <The_8472> hrrm, ok
[04:39:59] *** neurodrone has quit IRC
[04:40:04] <charles> they both have problems, but at least NAT-PMP is relatively simple
[04:40:29] <charles> UPnP is hideously complicated
[04:41:47] <Switeck> if only more routers supported NAT-PMP and it stays simple...
[04:41:55] *** neurodrone has joined #bittorrent
[04:45:09] <GTHK> Older DD-WRT would just close ports if you tried to map a manually forwarded port. That was the only issue. Now if I try to use it (for testing) with uTorrent I get lots of logging messages about the forwards not even existing. A port test one moment is fine, the next, fail!
[04:45:44] <alus> with both, there is an ambiguity about manually forwarded ports and automatically forwarded ports
[04:46:25] <alus> should both kinds show up in both lists? can one interface close a port opened by the other interface?
[04:47:16] <GTHK> Some time last year alus I had you check a wireshark capture for when I tried to UPnP an already manually forwarded port, you told me the router was saying the forward was successful, silly DD-WRT only closed it though XP
[05:26:03] *** bramm has quit IRC
[05:37:56] *** Stremma has quit IRC
[05:38:22] *** neurodrone has quit IRC
[05:40:26] *** init0 has quit IRC
[05:41:54] *** init0 has joined #bittorrent
[05:47:05] *** _rafi_ has joined #bittorrent
[05:47:16] <Switeck> disjointed post of the day:  http://forum.utorrent.com/viewtopic.php?id=67388
[05:48:29] *** _rafi2_ has quit IRC
[06:23:30] *** TheSHAD0W has quit IRC
[06:24:56] *** neurodrone has joined #bittorrent
[06:26:02] *** kwinz2 has quit IRC
[06:47:43] *** TheSHAD0W has joined #bittorrent
[06:59:08] <TheSHAD0W> Switeck: I've had people popping into IRC, demanding we seed some w4r3z torrent, then disappearing...
[06:59:42] <Switeck> heh
[07:00:10] <Switeck> the nature of disjointed posts at uTorrent isn't that they're asking about warez but that they're almost completely nonsensical
[07:00:16] <K`Tetch> yeah, very common on channels like tpb's
[07:00:18] <Switeck> 10-to-1, they're not English speakers
[07:01:42] <Switeck> It's scary to see what translating to another language (using Google translate) then back to English does to posts...
[07:01:51] *** MassaRoddel has quit IRC
[07:12:04] *** senex has joined #bittorrent
[07:15:30] *** _rafi2_ has joined #bittorrent
[07:17:08] *** MassaRoddel has joined #bittorrent
[07:17:24] *** _rafi_ has quit IRC
[07:34:03] <The_8472> <Switeck> 10-to-1, they're not English speakers <- i've seen native english speakers delivering significantly worse than that post
[07:34:41] <Switeck> http://forum.utorrent.com/viewtopic.php?id=67388
[07:34:45] <Switeck> like that?
[07:34:53] <Switeck> doh
[07:34:57] <Switeck> same post
[07:35:24] <Switeck> That post was made from Sky Broadband in the UK.
[07:36:12] <Switeck> So quite possibly that poster is a native English speaker.
[07:36:27] <The_8472> well, think of adding more sms-speak ontop of that
[07:36:48] <Switeck> sms?
[07:37:16] <Switeck> instant messenger or texting via cellphones?
[07:37:37] <The_8472> texting. you know, sortof like leetspeak
[07:38:01] <The_8472> or like twitter speak these days
[07:38:09] <The_8472> compact, unreadable, riddled with errors
[07:38:10] <Switeck> sado-masochistic style? (sms)
[07:38:23] <The_8472> short message service
[07:38:39] <Switeck> ah
[07:38:41] <The_8472> http://en.wikipedia.org/wiki/SMS
[07:39:36] *** _rafi_ has joined #bittorrent
[07:40:18] <Switeck> wow, so vulnerable
[07:41:24] *** _rafi2_ has quit IRC
[08:01:33] *** _rafi2_ has joined #bittorrent
[08:02:03] *** TheSHAD0W has quit IRC
[08:03:51] *** TheSHAD0W has joined #bittorrent
[08:04:16] *** _rafi_ has quit IRC
[08:07:22] *** Switeck has quit IRC
[08:14:34] *** neurodrone has quit IRC
[08:20:48] *** GTHK has quit IRC
[08:22:41] *** _rafi_ has joined #bittorrent
[08:25:00] *** _rafi2_ has quit IRC
[08:42:34] *** _rafi2_ has joined #bittorrent
[08:43:57] *** Andrius has joined #bittorrent
[08:45:17] *** _rafi_ has quit IRC
[08:54:10] *** r2wj is now known as r2wj|zzz
[09:05:38] *** _rafi_ has joined #bittorrent
[09:05:44] *** kniu has joined #bittorrent
[09:06:26] *** goussx has quit IRC
[09:06:47] *** goussx has joined #bittorrent
[09:07:21] *** _rafi2_ has quit IRC
[09:24:59] *** Waldorf has quit IRC
[09:28:34] *** _rafi2_ has joined #bittorrent
[09:29:52] *** _rafi_ has quit IRC
[09:49:52] *** _rafi_ has joined #bittorrent
[09:52:39] *** _rafi2_ has quit IRC
[09:53:25] *** Waldorf has joined #bittorrent
[10:05:28] *** cyb2063 has joined #bittorrent
[10:11:08] <kjetilho> http://www.freedom-to-tinker.com/blog/felten/census-files-available-bittorrent
[10:11:26] *** _rafi2_ has joined #bittorrent
[10:12:25] *** skampler has quit IRC
[10:12:30] *** skampler has joined #bittorrent
[10:12:56] *** skampler is now known as Guest97400
[10:14:02] *** _rafi_ has quit IRC
[10:16:18] <chelz> aw, i was hoping that was going to be about data released by some govt was using bt for distribution
[10:21:53] <kjetilho> chelz: yeah, I thought the same thing when I saw the URL and was a bit disappointed.  still interesting, though
[10:22:27] <chelz> yeah, i like seeing surveys every few years to see the status of trends
[10:30:28] *** senex has quit IRC
[10:32:52] *** _rafi_ has joined #bittorrent
[10:35:31] *** _rafi2_ has quit IRC
[10:36:42] *** kwinz2 has joined #bittorrent
[10:40:54] *** stalled has quit IRC
[10:50:43] *** stalled has joined #bittorrent
[10:52:09] *** _rafi2_ has joined #bittorrent
[10:55:12] *** _rafi_ has quit IRC
[10:57:03] *** stalled has quit IRC
[11:00:31] *** stalled has joined #bittorrent
[11:06:53] *** kwinz2 has quit IRC
[11:22:03] *** chelz has quit IRC
[11:35:27] *** _rafi_ has joined #bittorrent
[11:35:32] *** _rafi2_ has quit IRC
[11:39:59] *** cyb2063 has quit IRC
[11:45:20] *** kwinz2 has joined #bittorrent
[11:59:03] *** Waldorf has quit IRC
[12:09:16] *** kwinz2 has quit IRC
[12:23:53] *** kwinz2 has joined #bittorrent
[12:44:58] *** kwinz2 has quit IRC
[12:45:08] *** kwinz2 has joined #bittorrent
[13:53:07] <sktrdie> hi
[13:53:22] <sktrdie> what's the Peer Exchange tracker that i automatically connect to?
[13:53:26] <sktrdie> with my client?
[13:53:53] <DeHackEd> it's not a tracker. it's an addon to the client<->client protocol to exchange peer listings
[13:54:03] <sktrdie> i just started seeding this
[13:54:04] <DeHackEd> though it'll probably be represented as a meta-tracker
[13:54:07] <sktrdie> i haven't put it anywhere
[13:54:11] <sktrdie> and i have 18 peers!
[13:54:23] <DeHackEd> vuze?
[13:54:26] <sktrdie> no
[13:54:28] <sktrdie> utorrent
[13:55:00] * DeHackEd throws that theory out
[14:00:06] <sktrdie> are there bot clients that automatically download from PEX?
[14:00:09] <sktrdie> and DHT?
[14:06:07] <alus> who knows. are they downloading your file?
[14:06:33] <alus> is it possible this file has been torrented before by someone else?
[14:06:47] <alus> re-torrenting it would make the same infohash, and people would be able to find you through the DHT
[14:08:26] <sktrdie> no its a torrent i created
[14:08:51] <sktrdie> so the file itself might contain a torrent related info?
[14:08:55] <sktrdie> the fild im seeding
[14:08:56] <alus> no
[14:09:04] <alus> did you create the file itself?
[14:09:12] <alus> or is this something you downloaded from elsewhere?
[14:09:24] <sktrdie> no i created it
[14:09:29] <sktrdie> with utorrent
[14:09:44] <alus> no, the file which you are torrenting
[14:09:47] <alus> not the .torrent file
[14:09:48] <sktrdie> also
[14:09:52] <sktrdie> not related to this
[14:10:05] <sktrdie> i downloaded the file from somewhere else
[14:10:15] <sktrdie> if a tracker updates every 30 mins
[14:10:24] <alus> ok, so perhaps someone else has also made a torrent of the exact same file
[14:10:29] <sktrdie> how do new peers get up to date peers informationj
[14:11:02] <alus> 30 minutes is the time between when you check in
[14:11:10] <alus> when you start the torrent, you tell the tracker right away
[14:11:31] <sktrdie> ok
[15:02:00] *** edigaryev has joined #bittorrent
[15:40:34] <TheSHAD0W> You know, with the new metadata trading funcs, it's possible to speculatively download torrents.
[15:41:00] <TheSHAD0W> Find a torrent hash, connect to a torrent, download the metadata, inspect its contents and then decide if you want the payload.
[15:48:54] <TheSHAD0W> This is a second reason why the DHT ought to be based on the hash of the hash, rather than the hash itself.
[16:02:22] *** MassaRoddel has quit IRC
[16:05:34] *** MassaRoddel has joined #bittorrent
[16:08:29] *** TheSHAD0W has quit IRC
[16:16:24] *** neurodrone has joined #bittorrent
[16:43:04] *** KyleK_ has joined #bittorrent
[17:13:59] *** goussx has quit IRC
[17:22:38] *** Waldorf has joined #bittorrent
[17:28:51] *** trelane has quit IRC
[17:32:17] *** Nolar has quit IRC
[17:35:44] *** Nolar has joined #bittorrent
[17:35:44] *** Nolar has joined #bittorrent
[17:59:05] *** Guest97400 is now known as skampler
[17:59:11] *** skampler has joined #bittorrent
[18:02:38] *** KyleK_ has quit IRC
[18:03:34] *** Nolar has quit IRC
[18:08:24] *** Nolar has joined #bittorrent
[18:08:24] *** Nolar has joined #bittorrent
[19:21:31] *** Nolar has quit IRC
[19:22:50] *** goussx has joined #bittorrent
[19:23:11] *** goussx has joined #bittorrent
[19:23:27] *** Nolar has joined #bittorrent
[19:23:27] *** Nolar has joined #bittorrent
[19:42:40] *** burris has quit IRC
[19:42:55] *** burris has joined #bittorrent
[19:45:25] *** Waldorf has quit IRC
[19:50:47] *** Miller` has quit IRC
[20:07:24] *** neurodrone has quit IRC
[20:54:48] *** KyleK_ has joined #bittorrent
[21:02:33] *** neurodrone has joined #bittorrent
[21:08:31] *** edigaryev has quit IRC
[21:12:17] *** r2wj|zzz is now known as r2wj
[21:14:48] *** Miller` has joined #bittorrent
[21:22:38] *** GTHK has joined #bittorrent
[21:58:03] *** ivan` has quit IRC
[21:59:49] *** ivan` has joined #bittorrent
[22:00:10] *** ivan` has quit IRC
[22:02:02] *** ivan` has joined #bittorrent
[22:02:04] *** ivan` has joined #bittorrent
[22:10:37] *** kwinz2 has quit IRC
[22:19:14] *** burris has quit IRC
[22:42:32] *** burris has joined #bittorrent
[22:47:39] *** neurodrone has quit IRC
[22:58:07] *** kwinz2 has joined #bittorrent
[23:02:43] *** neurodrone has joined #bittorrent
[23:02:54] *** t0nic has joined #bittorrent
[23:06:25] *** stalled has quit IRC
[23:13:22] *** Andrius has quit IRC
[23:13:28] *** Andrius[] has joined #bittorrent
[23:16:23] <t0nic> is there a way to configure utorrent to not send traffic to ports 80/443?
[23:17:13] <t0nic> the #peerblock was talking about how "bad guys" could accept torrent traffic on those ports to get around peerblock if http is allowed
[23:17:42] <t0nic> or, is there any reason someone would NEED to accept bt traffic only on 80/443?
[23:19:29] <DWKnight> I don't trust anything peerblock guys say
[23:19:38] <DWKnight> mainly because their blocklists don't actually work
[23:21:43] <DWKnight> you CAN configure uT to not connect out to specific ports
[23:22:17] <DWKnight> but given the less-than-stellar performance of IP blockers like peerblock, I'd say don't bother using them
[23:24:56] *** kwinz2 has quit IRC
[23:25:16] *** kwinz2 has joined #bittorrent
[23:32:47] *** wnoise has joined #bittorrent
[23:33:45] *** wnoise has left #bittorrent
[23:36:43] *** stalled has joined #bittorrent
[23:36:45] <Miller`> I'm still confused about the time they blocked the 192.168 subnet...
[23:39:22] <DWKnight> it's not their first stupidity
[23:39:26] <DWKnight> nor will it be their last
[23:40:12] <kjetilho> hahaha, they did that?
[23:40:26] <kjetilho> good thing I'm using the much faster 10.0.0.x :-p
[23:41:17] <DWKnight> I'm pretty sure they've blocked multicast at one point or another
[23:41:34] <DWKnight> they've also blocked sourceforge (which was hosting their whole system at the time)
[23:42:51] *** stalled has quit IRC
[23:48:14] *** Andrius[] is now known as Andrius
[23:48:37] *** stalled has joined #bittorrent
[23:56:13] *** Andrius has quit IRC

top