[00:17:12] *** gringochapin has quit IRC
[00:17:33] *** gilles has quit IRC
[00:34:00] *** Andrius has quit IRC
[00:52:07] *** _rafi_ has joined #bittorrent
[00:57:19] *** _rafi2_ has quit IRC
[01:00:44] *** mxs has quit IRC
[01:01:56] *** mxs has joined #bittorrent
[01:08:33] *** gilles has joined #bittorrent
[01:22:34] *** mxs has quit IRC
[01:23:00] *** mxs has joined #bittorrent
[01:26:45] *** mxs has quit IRC
[01:26:49] *** chelz has joined #bittorrent
[01:28:21] *** mxs has joined #bittorrent
[01:34:24] *** mxs has quit IRC
[01:34:25] *** mxs_ has joined #bittorrent
[01:37:39] *** MassaRoddel has quit IRC
[01:37:42] *** mxs_ has quit IRC
[01:39:35] *** mxs has joined #bittorrent
[01:45:57] *** init0_ has joined #bittorrent
[01:56:54] <burris> magnet links on tpb are just a temporary measure until they are ready to deploy eXeem...
[01:57:12] *** init0 has quit IRC
[01:57:46] <Nolar> :)
[01:58:52] <DHE> what's tha?
[01:58:56] <DHE> man I'm out of it...
[02:02:45] <The_8472> hahaha
[02:17:14] *** FAB_ has joined #bittorrent
[02:20:35] *** Miller` has joined #bittorrent
[02:33:19] <chelz> lol wow that would be so crazy
[02:33:38] <chelz> there certainly has been enough time to finally finish that
[02:36:45] *** JaVaSan has quit IRC
[02:38:50] *** mxs has quit IRC
[02:42:02] *** Nolar has quit IRC
[02:42:10] *** Nolar has joined #bittorrent
[02:43:17] *** mxs has joined #bittorrent
[02:43:39] *** FAB_ has quit IRC
[02:44:16] *** FAB_ has joined #bittorrent
[02:45:35] *** FAB_ has quit IRC
[02:46:54] <ivan`> I'm switching back to suprnova
[02:47:56] <The_8472> that's owned by tpb
[02:48:36] <ivan`> oh, I didn't even realize it was relaunched
[02:48:44] <ivan`> joke fail
[02:49:04] *** andar has quit IRC
[02:55:24] *** therma has joined #bittorrent
[03:03:41] <uriel> haha
[03:04:16] *** Snoopotic6367 has joined #bittorrent
[03:05:47] *** Miller` has quit IRC
[03:05:47] *** init0_ has quit IRC
[03:05:47] *** chelz has quit IRC
[03:05:47] *** Snoopotic has quit IRC
[03:05:47] *** thermal has quit IRC
[03:08:03] *** init0 has joined #bittorrent
[03:08:43] *** Miller` has joined #bittorrent
[03:08:43] *** init0_ has joined #bittorrent
[03:08:43] *** chelz has joined #bittorrent
[03:08:43] *** Snoopotic has joined #bittorrent
[03:08:49] *** init0_ has quit IRC
[03:21:16] *** andar has joined #bittorrent
[03:21:40] *** Miller` has quit IRC
[03:22:46] *** Snoopotic has quit IRC
[03:23:16] *** thermal has joined #bittorrent
[03:32:25] *** Miller` has joined #bittorrent
[03:34:26] *** therma has quit IRC
[03:43:35] <K`Tetch> burris - exeem's long gone, slon's busy doing TFtv for us
[04:07:47] *** gilles has quit IRC
[04:07:50] *** The_8472 has quit IRC
[04:08:11] *** wadim has joined #bittorrent
[04:08:13] *** wadim is now known as The_8472
[04:10:12] *** mxs has quit IRC
[04:14:53] *** mxs has joined #bittorrent
[04:31:17] *** The_8472 has quit IRC
[04:31:18] *** chelz has quit IRC
[04:32:20] *** goussx has quit IRC
[04:35:32] *** The_8472 has joined #bittorrent
[04:35:32] *** chelz has joined #bittorrent
[05:01:10] *** goussx has joined #bittorrent
[06:24:17] *** bittwist has quit IRC
[06:24:43] *** _rafi_ has quit IRC
[06:29:48] *** gilles has joined #bittorrent
[06:51:56] *** goussx has quit IRC
[06:51:56] *** chelz has quit IRC
[06:51:56] *** The_8472 has quit IRC
[06:57:11] *** The_8472 has joined #bittorrent
[06:57:48] *** goussx has joined #bittorrent
[07:04:15] *** bittwist has joined #bittorrent
[07:05:23] *** chelz has joined #bittorrent
[07:06:28] *** chelz has quit IRC
[07:06:54] *** chelz1 has joined #bittorrent
[07:12:00] *** spoop has quit IRC
[07:22:04] *** spoop has joined #bittorrent
[07:30:21] *** thermal has quit IRC
[08:19:19] *** Miller` has quit IRC
[08:25:41] *** MassaRoddel has joined #bittorrent
[08:29:05] *** Andrius has joined #bittorrent
[08:32:48] *** mxs has quit IRC
[08:33:07] *** mxs has joined #bittorrent
[08:42:46] *** gilles has quit IRC
[08:46:54] *** Miller` has joined #bittorrent
[09:08:10] *** Switeck has quit IRC
[09:08:17] *** GTHK has quit IRC
[09:28:27] *** Andrius has quit IRC
[09:44:17] *** rdjong has joined #bittorrent
[09:49:48] *** bittwist has quit IRC
[09:50:08] *** bittwist has joined #bittorrent
[10:10:16] *** rdjong has quit IRC
[10:10:50] *** rdjong has joined #bittorrent
[10:45:42] *** rdjong_ has joined #bittorrent
[10:50:48] *** rdjong has quit IRC
[11:05:32] *** rdjong has joined #bittorrent
[11:06:10] *** mxs has quit IRC
[11:08:22] *** waldorf_ has joined #bittorrent
[11:08:22] *** mxs has joined #bittorrent
[11:11:16] *** goussx_ has joined #bittorrent
[11:12:18] *** rdjong has quit IRC
[11:14:08] *** rdjong_ has quit IRC
[11:16:13] *** rdjong has joined #bittorrent
[11:26:11] *** rdjong has quit IRC
[11:27:45] *** goussx has quit IRC
[11:27:45] *** goussx_ is now known as goussx
[11:29:50] *** rdjong has joined #bittorrent
[11:36:09] *** bt42 has joined #bittorrent
[11:38:35] *** bittwist has quit IRC
[11:44:55] *** rdjong has quit IRC
[11:58:58] *** The_8472 has quit IRC
[11:59:18] *** wadim has joined #bittorrent
[11:59:20] *** wadim is now known as The_8472
[12:39:50] *** ivan` has quit IRC
[12:40:08] *** ivan` has joined #bittorrent
[12:52:07] *** waldorf_ has quit IRC
[13:09:02] *** chelz1 has quit IRC
[15:22:00] *** rdjong has joined #bittorrent
[15:59:10] *** burris has quit IRC
[15:59:22] *** burris has joined #bittorrent
[16:02:31] *** rdjong_ has joined #bittorrent
[16:07:47] *** rdjong__ has joined #bittorrent
[16:12:57] *** rdjong___ has joined #bittorrent
[16:15:37] *** rdjong_ has quit IRC
[16:17:01] *** HandheldPenguin` is now known as HandheldPenguin
[16:17:03] *** burris has quit IRC
[16:18:21] *** rdjong_ has joined #bittorrent
[16:20:49] *** burris has joined #bittorrent
[16:23:02] *** rdjong has quit IRC
[16:23:32] *** rdjong has joined #bittorrent
[16:28:51] *** rdjong____ has joined #bittorrent
[16:35:14] *** rdjong__ has quit IRC
[16:35:34] *** rdjong__ has joined #bittorrent
[16:39:53] *** rdjong_____ has joined #bittorrent
[16:41:30] *** rdjong___ has quit IRC
[16:43:58] *** rdjong____ has quit IRC
[16:44:30] *** BentMyWookie has quit IRC
[16:44:38] *** BentMyWookie_ has joined #bittorrent
[16:45:15] *** rdjong___ has joined #bittorrent
[16:45:38] *** rdjong_ has quit IRC
[16:45:56] *** mxs has quit IRC
[16:49:52] *** rdjong has quit IRC
[16:49:54] *** rdjong___ is now known as rdjong
[16:50:39] *** rdjong_ has joined #bittorrent
[16:51:52] *** mxs has joined #bittorrent
[16:54:31] *** mxs has quit IRC
[16:56:06] *** rdjong___ has joined #bittorrent
[16:56:08] *** BentMyWookie_ has quit IRC
[16:56:34] *** BentMyWookie has joined #bittorrent
[17:01:21] *** rdjong____ has joined #bittorrent
[17:02:11] *** mxs has joined #bittorrent
[17:02:17] *** rdjong__ has quit IRC
[17:06:33] *** rdjong__ has joined #bittorrent
[17:08:08] *** rdjong__ has quit IRC
[17:08:14] *** rdjong_____ has quit IRC
[17:09:00] <BentMyWookie> another peer id question: -OS0670-
[17:09:31] <BentMyWookie> and -PC261A-
[17:13:00] *** rdjong has quit IRC
[17:14:31] *** Switeck has joined #bittorrent
[17:15:21] *** rdjong____ has quit IRC
[17:15:37] *** mxs has quit IRC
[17:18:06] *** rdjong_ has quit IRC
[17:22:30] *** bbelt16ag has quit IRC
[17:24:01] *** rdjong___ has quit IRC
[17:26:26] *** mxs has joined #bittorrent
[17:40:07] *** mxs has quit IRC
[17:46:13] <TheSHAD0W> BentMyWookie: From the tracker?  Or a peer?
[17:47:01] <BentMyWookie> peer
[17:48:34] <TheSHAD0W> Mmm.
[17:48:45] <TheSHAD0W> From a tracker, the user agent string might help...
[17:48:53] <BentMyWookie> ya
[17:49:01] <BentMyWookie> afaict it's from the peer
[17:51:13] <TheSHAD0W> No, no, I mean, if a tracker is being contacted by that peer, the peer may also send a user-agent in the metadata with a full name.
[17:51:52] <BentMyWookie> unfortunately the peer id is all the info i have
[17:55:01] <The_8472> PC is possibly a CacheLogic peer (some p2p caching solution) and OS is OneSwarm
[17:56:45] *** mxs has joined #bittorrent
[17:57:56] *** BentMyWookie has quit IRC
[18:00:10] *** BentMyWookie has joined #bittorrent
[18:01:22] *** mxs has quit IRC
[18:07:51] *** mxs has joined #bittorrent
[18:10:58] *** mxs has quit IRC
[18:21:45] *** SundanceKid has joined #bittorrent
[18:29:17] *** mxs has joined #bittorrent
[18:49:27] *** DWKnight has quit IRC
[18:58:04] *** DWKnight has joined #bittorrent
[19:01:24] *** bbelt16ag has joined #bittorrent
[19:08:42] *** erdgeist has joined #bittorrent
[19:08:44] <erdgeist> Helloe
[19:09:10] <erdgeist> I've heard there's two implementations of a DHT proto right now. Anyone has a link to the other on besides http://www.bittorrent.org/beps/bep_0005.html
[19:11:11] <The_8472> there is no complete specification of the other one, atm only packet formats are documented: http://azureuswiki.com/index.php/DHT#Packet_format
[19:11:39] <erdgeist> The_8472: thanks. Do you know WHO supports what?
[19:12:54] <The_8472> azureus supports its own dht (+ bep5 via a plugin), everyone else does bep5
[19:13:04] <The_8472> and the rest does neither
[19:13:11] <erdgeist> The_8472: So I go with bep5
[19:13:26] <BentMyWookie> why doesn't azureus switch to bep5?
[19:13:26] <The_8472> you go with bep32+bep5
[19:13:40] <The_8472> BentMyWookie, because bep5 lacks a significant amount of features
[19:13:50] <BentMyWookie> ya?
[19:13:54] <The_8472> yes
[19:14:41] <BentMyWookie> can you ellaborate?
[19:14:44] <The_8472> not to mention that we were the first and mainline then did a "not invented here" and rolled their own.... just like they did with LTEP. just like they did with PEX
[19:15:02] <erdgeist> The_8472: who's "we" in that context?
[19:15:12] * The_8472 points at his hostname
[19:16:32] <erdgeist> The_8472: Ahh, the client that now sounds like a vulgar word for "vagina" in german
[19:16:52] <The_8472> depends how you pronounce it
[19:17:09] <erdgeist> The_8472: depends on how someone NOT in the know reads it :)
[19:17:29] <The_8472> BentMyWookie, sure. we have various security features that make it harder to poison the DHT. e.g. fixed node IDs to prevent nodes from inserting them near specific IDs
[19:17:43] <erdgeist> The_8472: okay to PM you?
[19:18:02] <The_8472> it also has replication, large-value transfers, etc.
[19:18:06] <The_8472> is it necessary?
[19:18:32] <erdgeist> The_8472: depends. I'm not sure.
[19:19:04] <The_8472> well, if it concerns bittorrent it usually can be discussed here
[19:21:04] <Astro> erdgeist: what are you up to with DHTs?
[19:22:18] * The_8472 prods the earth spirit
[19:23:03] <Astro> ETOOMANYGERMANS
[19:23:13] <erdgeist> Astro: well, I'm not too familiar with the guys hanging out here
[19:23:52] <Astro> me neither, I just joined after TPB announced shutdown of their trackers
[19:23:58] <The_8472> basically a bunch of bittorrent devs, tracker admins and power users here
[19:24:16] <erdgeist> Thing is, tpb is thinking about distributing super-dht-nodes
[19:24:33] <The_8472> what would their purpose be?
[19:24:35] <erdgeist> That can be deployed on any 5$-virtual-box
[19:25:00] <Astro> how would they be "super" compared to all the other nodes?
[19:25:09] <erdgeist> The_8472: bring together nodes not talking DHT and the built in tracker
[19:25:21] <erdgeist> The_8472: for torrents server from tpb
[19:25:29] <The_8472> so, more like a tracker-dht-bridge?
[19:25:59] <The_8472> we just discussed that yesterday ^^
[19:26:04] <erdgeist> Ohh
[19:26:12] <Astro> like http://trackhub.appspot.com/ ?
[19:26:18] <The_8472> no, that's something else
[19:26:44] <erdgeist> Well, there's some issues about trackers. You know single point of failure. Privacy concerns
[19:27:07] <The_8472> yes, but i'm still not sure what you mean by <erdgeist> The_8472: bring together nodes not talking DHT and the built in tracker
[19:27:19] <The_8472> is it supposed to be a tracker protocol to dht bridge?
[19:29:02] <The_8472> btw, considering privacy concerns... the DHT is public, anyone can gather data from it... the only difference is that it's not under the control by any specific group of people.
[19:29:07] <erdgeist> The_8472: I am not completely sure. Just gathering data. Is it true that without trackers dht currently could not stem the load?
[19:29:12] <The_8472> but it does not really improve anyone's privacy
[19:29:59] <The_8472> erdgeist, the DHT is pretty scaleable. some implementations might need to be optimized by i think it could handle the load (unless many people do really stupid things like announcing 200 torrents at once)
[19:30:16] <The_8472> *but i think
[19:30:46] <The_8472> but there are other concerns
[19:31:14] <The_8472> the mainline DHT lacks scrapes and security features that prevent someone taking over the keyspace responsible for a particular torrent
[19:31:48] <TheSHAD0W> Yeah.
[19:31:54] <erdgeist> so you could randomly send requestors to non-valid peers?
[19:32:12] <TheSHAD0W> It's unfortunate that mainline can't switch to a different and already established DHT system that has such features.
[19:32:13] <The_8472> or just return empty peer lists, yes
[19:32:22] <TheSHAD0W> Oh wait, I forgot.  They can't, because it's NOT DOCUMENTED!
[19:32:26] * TheSHAD0W runs away!
[19:33:07] <The_8472> TheSHAD0W, well, if someone would officially request documentation from parg... nobody seriously asked so far
[19:33:45] <TheSHAD0W> Mmm.
[19:34:04] <TheSHAD0W> I can't truly, seriously do it, because I haven't been able to do any development lately.
[19:34:42] <TheSHAD0W> Oh alus...  o/^
[19:35:36] <erdgeist> The_8472: But there's no way to trust some nodes more than others?
[19:35:45] <erdgeist> The_8472: like signatures or something?
[19:38:11] <erdgeist> The_8472: What exactly is wrong with announcing 200 torrents at once?
[19:39:20] <The_8472> no, there is no trust hiererchy among nodes. everyone is a potential hostile
[19:39:34] <The_8472> all you can do is make sure that they operate according to the protocol
[19:39:43] <erdgeist> Hmm
[19:40:19] <The_8472> and... the DHT is inefficient for individual nodes. what makes it efficient on the global scale is that you don't have a central point that it behing hammered by the many packets generated
[19:40:49] <The_8472> an announce can easily generate 100 requests + 100 replies
[19:40:56] <The_8472> i.e. UDP packets
[19:41:02] <erdgeist> The_8472: Well, I LOVE udp
[19:41:19] <erdgeist> The_8472: tpb also has some capacities to handle 100 requests + 100 replies
[19:41:38] <The_8472> one UDP announce is 3 packets vs. 200
[19:42:12] <erdgeist> The_8472: Yeah, it's a pity that tracker udp announce does not support announcing multiple torrents in one packez
[19:42:13] <The_8472> so doing 200 announces could create 40k packets traveling through the intarwebs
[19:42:23] <The_8472> via DHT
[19:43:03] <erdgeist> The_8472: who'm exactly do you send those announces to? I.e. how do you discover your first neighbours?
[19:43:04] <The_8472> so it could take 20-30 minutes or so just to do the announces. And if many people would do it then the DHT traffic would rise from ~1kB/s to... more.
[19:43:19] <The_8472> those are 2 very different questions
[19:44:01] <The_8472> lookups are iterative, so the packets get spread all over teh DHT. but the final steps are the nodes where it'll be stored.
[19:44:02] <erdgeist> The_8472: I don't get it. You're just saying that DHT can _not_ replace tracker announces?
[19:44:11] <The_8472> no, i'm not
[19:44:17] <erdgeist> The_8472: okay
[19:45:01] <The_8472> as for how to discover your neighbors... any DHT node will do. either via some bootstrap node(s), from peers, from a cached table on your harddisk... anything works
[19:45:44] <erdgeist> The_8472: and if I'm a node, can I decide to store all announces that are sent my way?
[19:46:03] <The_8472> erdgeist, i don't understand your question
[19:46:38] <The_8472> i assume you don't know how DHTs, especially how Kademlia works?
[19:46:49] <erdgeist> The_8472: If I understand the DHT idea correctly, there's several nodes holding the information. All others just do know, which of their neighbourghs know a more specific prefix.
[19:48:12] <The_8472> hrrm, yes, those are the basics
[19:48:50] *** anakh has joined #bittorrent
[19:48:52] <erdgeist> So what exactly stops me from saying that I want to store all 160bits
[19:49:03] <erdgeist> store+provide
[19:49:42] <The_8472> every node has an ID. you are only responsible for and will only asked to take care of values that are "near" your ID
[19:50:19] <The_8472> but with the mainline DHT that ID can be chosen freely, thus you could insert a bunch of nodes near a specific key (e.g. a torrent hash you want to DoS) and thus absorb all traffic for that particular key
[19:50:36] <The_8472> to take over the entire keyspace you'd have to do a lot more than you have to do for a single key
[19:50:42] *** gilles has joined #bittorrent
[19:52:15] <erdgeist> The_8472: Hmmm. If I _know_ all the info_hashes, cant I simply generate IDs that make me the best match?
[19:53:49] <The_8472> things are done redundantly. so being the best match alone does no good
[19:54:14] <The_8472> things are stored on the 8 closest nodes to the key +- some noise
[19:54:46] <The_8472> so if you want to hijack 1 million torrents you basically have to run 8 million nodes
[19:55:02] <erdgeist> The_8472: well, I don't want to do harm but provide additional storage to make up for nodes behind firewalls/NAT
[19:55:05] <The_8472> and if you want to run that many nodes there are more efficient attacks on the DHT
[19:55:13] <anakh> well, one piece of code could masquerade as 8 million different IDs..
[19:55:31] <anakh> but we aren't out to do harm heh
[19:55:34] <The_8472> anakh, things are usually filtered by IP
[19:55:43] <The_8472> so you'd need that many IPs too
[19:55:51] <anakh> IPv6 support ... ?
[19:55:59] <The_8472> brand new, barely supported
[19:56:10] <The_8472> but yes, IPv6 causes even more security headaches
[19:56:13] <anakh> per ip:port or just per ip ?
[19:56:18] <anakh> (im working on a similar project as erd)
[19:56:27] <The_8472> depends on the implementation, really
[19:56:42] <erdgeist> The_8472: So _is_ there a way to start multiple requests?
[19:56:54] <erdgeist> The_8472: Or do you do that, anyway?
[19:57:22] <anakh> erdgeist: grab all udp traffic to your port for the /24 and you have 256 addrs.. good start :)
[19:57:30] <anakh> (yes, .0 and .255 would be usable)
[19:57:59] <erdgeist> anakh: I'd want to make it very tiny, deployable everywhere
[19:58:10] <The_8472> you lost me again
[19:58:26] <anakh> ah, i dont care about deployability really
[19:58:48] <anakh> btw, next week im gonna play with BT accelerating @ my isp
[19:58:59] <The_8472> <erdgeist> The_8472: well, I don't want to do harm but provide additional storage to make up for nodes behind firewalls/NAT <- while that's not really necesary for now it would be better to just randomly scatter long-lived nodes throughout the DHT at random IDs
[19:59:20] <anakh> since here global transit == expensive and sparse, internal traffic == cheap fiber
[19:59:35] <erdgeist> The_8472: okay
[19:59:41] <The_8472> anakh, you're assuming that there is more than 1 or 2 people downloading the torrent at the same time?
[20:00:05] <anakh> the_8472: uhm which conversation did you ask that question in.. dht or acceleration :)
[20:00:28] <erdgeist> The_8472: and the protocol does not allow multiple IDs on the same IP to be secure agains spoofing attacks...
[20:00:31] <The_8472> erdgeist, the DHT relies on uniform distribution of nodes. having nodes cluster around particular IDs has not been studied and thus could have negative effects
[20:00:57] <anakh> lets try and see then :)
[20:01:07] <anakh> and get a paper published if it leads to total meltdown!
[20:01:32] <The_8472> erdgeist, the protocol is mute on that aspect. it's up to implementations to handle that... but it's strongly discouraged behavior
[20:01:45] <anakh> actually i think it'd be pretty easy to bring much of global dht down for a determined attacker
[20:01:51] <The_8472> anakh, about acceleration
[20:02:01] <anakh> the_8472: ah..
[20:02:04] <anakh> well
[20:02:22] <anakh> ill only have it kick in once a certain number of local clienst are announcing the same infohash
[20:02:35] <anakh> the isp transproxies http so its easy to proxy tracker requests
[20:02:54] <DWKnight> bep23?
[20:03:04] <DWKnight> no
[20:03:06] <DWKnight> wrong one
[20:03:08] <anakh> when > magicnr is reached, the accelerator kicks in and starts leeching from the present local nodes
[20:03:10] <DWKnight> bep 22
[20:03:16] <DWKnight> http://bittorrent.org/beps/bep_0022.html
[20:03:57] <anakh> + local nodes gets added to the peers from the tracker(s)
[20:04:22] <The_8472> regarding running multiple nodes on 1 IP. you could probably get away with running them with vastly different IDs. but running multiple nodes with very similar IDs on 1 IP is a big no-no
[20:04:28] <anakh> and accelerator is nailed as part of all responses for torrents it accels
[20:04:32] <erdgeist> The_8472: I'd not do that
[20:04:47] <anakh> thats ok.. i have a /24 at home :)
[20:05:15] <The_8472> <anakh> the isp transproxies http so its easy to proxy tracker requests <- urgh. great. you do know that trackers need to know the proper external IP of a peer? proxying is a horrible thing to do
[20:05:39] <The_8472> not to mention that private trackers won't like that... not that i care
[20:05:43] <anakh> the_8472: well isp is gonna trans proxy regardless of what we do .. :)
[20:05:55] <DWKnight> anakh: israeli ISPs tried that
[20:05:57] <anakh> like i said, global transit is very expensive here ..
[20:06:00] <erdgeist> The_8472: opentbittorrent now is able the use X-Forwarded-For: Header
[20:06:06] <erdgeist> The_8472: still it's very spoofable
[20:06:08] <DWKnight> and failed in a HORRIDLY broken manner
[20:06:20] <anakh> dwknight: so lets see if we fail in a similar broken manner then :)
[20:06:43] <The_8472> did someone just say "let's reinvent the squared wheel"?
[20:06:49] <DWKnight> yes
[20:07:02] <anakh> this isp has kinda special circumstances like i said
[20:07:04] <DWKnight> except they're going to try for 3-sides
[20:07:34] <erdgeist> Well, there IS a way to just be a tracker proxy. If you're the ISP, anyway, you can then also deploy the proxy-bittorrent-client and be good
[20:07:37] <anakh> 1. transparent http proxy isnt going anywhere 2. high speed within network but not outside
[20:07:40] <The_8472> heh, polygonal wheels work better with increased numbers of edges, not decreased ones
[20:07:56] <anakh> the_8472: hahaha thats gonna be my new motto
[20:07:59] <erdgeist> The_8472: if the amount of edges is 1, youre best off ;)
[20:08:15] <The_8472> a circle is not a polygon
[20:08:27] <anakh> <weird project #4711> - improving the square wheel, because polygonal wheels work better with more edges!
[20:08:38] <The_8472> so, what you want is a regular polygon with an infinite number of edges
[20:08:44] <DWKnight> the closest you get to a circle in logo, you have 360 edges
[20:08:48] <erdgeist> The_8472: it is. Its a polygon with infinite number of edges
[20:09:24] <The_8472> yes, but you said 1 instead of ?
[20:09:27] <anakh> http://mathworld.wolfram.com/Circle.html :P
[20:09:54] <anakh> A circle can also be viewed as the limiting case of a regular polygon with inradius r and circumradius R as the number of sides n approaches infinity (a figure technically known as an apeirogon).
[20:10:16] <erdgeist> The_8472: That'd be a very funny wheel
[20:11:01] <The_8472> anyway, back to the issue... what are you actually trying to achieve?
[20:11:47] <erdgeist> Prepare a bailout strategy. To remove the single point of failure that a tracker is while promoting DHT
[20:13:18] <The_8472> getting more users to use clients with DHT support or get client devs who haven't done it yet to include DHT into their client would be good
[20:13:41] <anakh> the_8472: think of what he/we are trying to do as providing supernodes a bit like trackers are provided today
[20:14:10] <The_8472> the DHT is not designed for such things. it assumes a smooth distribution of nodes throughout the keyspace
[20:14:19] *** gilles has quit IRC
[20:14:34] <DWKnight> dht is more decentralized than supernode-style networks like gnutella
[20:15:10] <The_8472> the only nodes that experience more load than average are those that are the closest ones to highly popular keys.
[20:15:40] <The_8472> and even that does not require supernodes. in the azureus DHT we have key diversification to cover that issue
[20:16:08] <The_8472> in the mainline DHT it would require some trickery... but i think it would be possible to spread the load over more nodes too
[20:17:17] <The_8472> the only nodes that are really of more importance than others are the boostrap nodes. but they're exchangeable. you just need to plug them into the clients
[20:17:23] <The_8472> so anyone could run them
[20:17:53] <The_8472> really, right now there are other - more important - things to fix on the mainline DHT than load issues
[20:18:51] <erdgeist> The_8472: problems I can contribute to?
[20:18:53] <alus> such as?
[20:19:29] <anakh> what about fixing the fact that DHT nodes can be used as DoS amplifiers .. ? :)
[20:19:35] <The_8472> well, lack of scrapes is the most important functional shortcoming when it comes to replacing trackers
[20:19:55] <The_8472> everything else are mostly DoS/security issues
[20:19:59] <erdgeist> The_8472: what do you need scrapes for?
[20:20:22] <The_8472> a) indexing sites (so that users can assess the liveness of a torrent) b) queues within clients
[20:20:28] <erdgeist> The_8472: tracker responds with everything you need in its announce replies
[20:20:51] <The_8472> <The_8472> well, lack of scrapes is the most important functional shortcoming when it comes to replacing trackers
[20:20:55] <DWKnight> except when the torrent isn't in an active state
[20:21:05] <The_8472> and yes, that too
[20:22:53] <erdgeist> The_8472: btw: does azureus use the downloaded-key in announce replies?
[20:23:29] <The_8472> yes
[20:23:40] <The_8472> we display it as "Completed: ..."
[20:24:08] <erdgeist> The_8472: Well, we included it when we noticed, that clients sent announce/scrape-pairs
[20:24:34] <erdgeist> The_8472: For the only reason for scrapeing was getting downloaded count
[20:25:34] *** goussx has quit IRC
[20:25:50] <DWKnight> biggest bandwidth-saver I ever implemented on the scrape side was the support for having multiple torrent-specific scrapes in a single request
[20:25:55] *** goussx has joined #bittorrent
[20:26:22] <erdgeist> DWKnight: multiscrapes you mean?
[20:26:52] <The_8472> that's even more of an issue with the DHT. implementing scrapes is one thing, doing scrapes for 100s of torrents in parallel... ugh
[20:26:53] <erdgeist> DWKnight: charles@Transmission would like to see multi-announces, to save time when shutting down
[20:27:23] <The_8472> how about just using HTTP pipelining instead...
[20:27:36] <erdgeist> The_8472: I've implemented HTTP keep alive
[20:27:39] <The_8472> even UDP announces can be pipelined to some extent by reusing the token
[20:27:49] <anakh> scrape info can be stored distributed..
[20:27:51] <erdgeist> The_8472: but still, HTTP headers waste a lot of bw
[20:28:12] <erdgeist> The_8472: does Azureus support keep-alive?
[20:28:19] <The_8472> erdgeist, bandwidth is probably not the issue on shutdown, TCP connection setup and teardown is probably slower
[20:28:29] <The_8472> we could support it, it's off though i think
[20:28:30] <erdgeist> The_8472: yes
[20:28:38] <anakh> as we both know the primary bottleneck on a BT tracker is the damn TCP stack :-)
[20:28:53] <erdgeist> The_8472: Hmmm, I've implemented it and want to switch it on, soonish
[20:29:09] <erdgeist> The_8472: but not without keeping an eye on the impact it has
[20:29:22] <DWKnight> [3:28:44pm] <anakh> as we both know the primary bottleneck on a BT tracker is the damn TCP stack :-) <-- network card drivers are next
[20:29:28] <erdgeist> DWKnight: no
[20:29:40] <DWKnight> other way around?
[20:29:41] <erdgeist> DWKnight: tcp stack is the single most disturbing factor
[20:29:42] <The_8472> well, we just close the connection right now, so it shouldn't cause (much) additional costs if the server supports it but goes unused
[20:29:43] <anakh> nope
[20:29:56] <DWKnight> I know we haven't really hit any cpu-bound systems yet on the tracker side of things
[20:29:58] <anakh> if you use good nics with good drivers then drivers certainly wont be a problem
[20:30:09] <erdgeist> The_8472: It's a tradeoff. It would be nice to only keep alive, if you plan on sending multiple requests
[20:30:14] <anakh> i mean ive routed 200-300Kpps and several Gbps with Intel NICs
[20:30:19] <anakh> why would announces be any different
[20:30:26] <erdgeist> The_8472: We shut down the socket as soon as our answer is out
[20:30:35] <anakh> (in a not-that-highend box)
[20:30:40] <anakh> (3 years ago)
[20:30:44] <erdgeist> The_8472: to save file descriptors and get socket states removes asap
[20:31:07] <erdgeist> The_8472: in the moment we switch on keep-alive, those sockets stay open
[20:31:12] <The_8472> hrrm, then we can't easily make use of it. only scrapes are bunched together. announces don't share common timing or anything like that
[20:31:17] <erdgeist> The_8472: which is a lot of wood with 20k connections/s
[20:31:27] <anakh> i experimented with writing my own userland tcp stack because of the TCP stack bottlenecks but the problem ended up being packet losses when doing kernel<>userland IO
[20:31:27] <erdgeist> The_8472: on shutdown they do
[20:31:30] <anakh> even with zerocopy
[20:31:34] <erdgeist> The_8472: and on startup, too
[20:31:37] <The_8472> well, if the client closes the connection then you can close the socket too ^^
[20:32:01] <anakh> => phonecall from isp at 3 am "what the hell are you doing that's crashing our cisco 124xx?"
[20:32:15] <erdgeist> The_8472: it's easier to just close it than to wait for the client to start the teardown
[20:32:20] <The_8472> erdgeist, i'm talking about code. the announces don't know about each other on the code side
[20:32:28] <erdgeist> The_8472: why not?
[20:32:35] <erdgeist> The_8472: It is one client, isn't it
[20:32:36] <The_8472> because there is no need
[20:32:39] <anakh> which is one of the reasons i wanna do this with dht, 1 "supernode" could handle a lot more than 1 tracker
[20:32:40] <erdgeist> The_8472: transmission can do it
[20:32:46] <anakh> because the protocol is a tad more efficient
[20:32:49] <The_8472> i didn't say it's impossible
[20:32:58] <The_8472> i'm just saying things aren't implemented like that
[20:33:07] <erdgeist> The_8472: Do you do a clean event=stopped when quitting azureus?
[20:33:16] <The_8472> yes
[20:33:33] <erdgeist> The_8472: so you're waiting for _all_ responses, too before finally shutting down?
[20:33:58] <erdgeist> The_8472: maybe you should then queue and sort all startup and shutdown announces
[20:34:56] <The_8472> yes, maybe. but turning on keepalive is just changing 1 line of code. actually coordinating the announces just doesn't happen. they _might_ reuse the connection by coincidence
[20:35:13] <erdgeist> The_8472: you outsource that to curl?
[20:35:32] <The_8472> to java's http url connection class
[20:35:49] <The_8472> which caches keep-alive connections
[20:36:15] <erdgeist> The_8472: so on shutdowns it would bundle them, by itself?
[20:36:21] <The_8472> possibly
[20:36:36] *** mxs has quit IRC
[20:36:40] *** mxs_ has joined #bittorrent
[20:37:21] <The_8472> the thing is, if you close the connection your end as soon as the answer is sent then idk if they're sent in a timely manner
[20:37:32] <The_8472> and how the re-use behavior is
[20:37:55] <The_8472> pipelining and keepalive are not the same after all
[20:38:06] <erdgeist> The_8472: well, I would stop closing the connection, if the client says keep-alive
[20:38:10] <erdgeist> The_8472: yes and no
[20:38:12] <burris> The_8472, mainline DHT was in private beta when az announced theirs...  pretty funny that you blame bram and the mainline people for NIH and rolling their own
[20:38:23] <erdgeist> The_8472: you cant use pipelining without keep-alive
[20:38:54] <The_8472> burris, we were first to market. what is done in private beta... cannot be divined by those outside those private circles
[20:39:04] <The_8472> not to mention that ours was public... nightly builds and all
[20:39:16] <The_8472> erdgeist, you can use keep-alive without pipelining
[20:39:23] <The_8472> which is exactly the point which i was making
[20:39:24] <erdgeist> The_8472: yes
[20:39:43] <erdgeist> The_8472: and the _still_ would be better
[20:39:52] <erdgeist> The_8472: s/the/that/
[20:39:59] <The_8472> well, keep-alive is easier then
[20:40:52] <erdgeist> I'll try it and if openbittorrent crashes, I'll roll it back :)
[20:40:59] <The_8472> burris, not to mention that NIH does absolutely apply to the extended messaging protocols or pex.
[20:41:10] <The_8472> hahaha
[20:43:03] <alus> what? mainline followed with extended messaging and pex after uT and LT already supported it
[20:43:12] <alus> also see: protocol encryption
[20:43:29] <The_8472> yes, protocol encryption is how it should be done.
[20:43:31] <alus> AZ is the odd-man out with an extension protocol
[20:43:37] <The_8472> huh?
[20:43:46] <The_8472> we had the az messaging protocol long before LTEP was invented
[20:44:07] <The_8472> it was introduced the same time we added the az DHT
[20:45:22] <The_8472> pex came 1 or 2 releases later i think
[20:46:34] <burris> sounds like you're jealous that BT mostly ignores az's aspirations to control the protocol
[20:46:58] <The_8472> 2005.05.02 | Azureus 2.3.0.0
[20:46:59] <The_8472> FEATURE: Core | Inter-client peer exchange [Nolar]
[20:47:01] <erdgeist> Ouhm, what have I gotten myself into here?
[20:47:30] <The_8472> burris, huh?
[20:48:18] <erdgeist> Does anyone out there still use brams python client, at all?
[20:48:48] <The_8472> no, if they use a python client they use bittornado i think
[20:49:28] <erdgeist> The_8472: and what exactly does Bram sell, now?
[20:49:35] <The_8472> burris, how is the fact that we invent a custom extension (az messaging + pex) different from libtorrent inventing it too, later... and incompatibilty
[20:49:46] <TheSHAD0W> Well, BitTornado doesn't have DHT, and given TPB's latest move it may be seriously deprecated pretty soon.
[20:49:48] 
[20:50:07] <erdgeist> TheSHAD0W: What exactly is TPB's latest move?
[20:50:25] <TheSHAD0W> They're dropping their trackers and relying entirely on DHT.
[20:50:39] <TheSHAD0W> As well as going with magnet-type links.
[20:50:41] <erdgeist> TheSHAD0W: no, they don't
[20:50:51] <TheSHAD0W> No?
[20:51:00] <The_8472> then they don't believe their own propaganda ^^
[20:51:06] <erdgeist> TheSHAD0W: No.
[20:51:24] <erdgeist> TheSHAD0W: There is this community-funded openbittorrent.com project
[20:51:53] <TheSHAD0W> http://torrentfreak.com/the-pirate-bay-tracker-shuts-down-for-good-091117/
[20:53:12] <The_8472> though i must say that torrentfreak is not the best source of news... it tends to be sensationalistic
[20:54:10] <TheSHAD0W> I first went looking for a press release on the TPB site, couldn't quickly find one.
[20:54:29] <The_8472> it's always on their blog
[20:54:46] <TheSHAD0W> I don't read Swedish.  :-P
[20:55:14] <The_8472> it's mostly english
[20:55:19] <erdgeist> Ernesto is not a very good journalist, no
[20:55:23] <TheSHAD0W> Oh, where is it?
[20:55:30] <burris> erdgeist, people now use bram's BitTorrent/uTorrent clients in very great numbers
[20:55:32] <TheSHAD0W> Ah, there.
[20:55:33] <The_8472> http://thepiratebay.org/blog
[20:55:55] <erdgeist> burris: they bought uTorrent?
[20:56:06] <burris> erdgeist, three years ago
[20:56:10] <TheSHAD0W> ...
[20:56:15] <TheSHAD0W> Can't read it.
[20:56:16] <erdgeist> burris: Hopefully they improved that client
[20:56:16] * DWKnight digs erdgeist out of his cave
[20:56:21] <anakh> hm
[20:56:21] <TheSHAD0W> It's not coming up on my browser.
[20:56:23] *** anakh is now known as anakata
[20:56:27] <anakata> guess im more well known this way :)
[20:56:36] <TheSHAD0W> Ooo.
[20:56:49] <The_8472> ah yes ^^
[20:56:49] <erdgeist> The blog is empty
[20:56:55] <TheSHAD0W> You're the author of hypercube?
[20:56:58] <burris> erdgeist, BT is just rebadged uT now
[20:57:02] <anakata> theshadow: yeah
[20:57:08] <TheSHAD0W> Nice...
[20:57:10] <anakata> didnt have time to keep supporting it though
[20:57:22] <TheSHAD0W> I went looking for you once, trying to find out how you'd licensed it...
[20:57:27] <erdgeist> burris: uT is the only client we'd ever had to patch our HTTP parser for
[20:57:28] <TheSHAD0W> You have some very protective friends.  ^__^
[20:57:28] <anakata> oh
[20:57:32] <anakata> i now i have a license!
[20:57:46] <erdgeist> opentracker has a very simple licence ;)
[20:57:47] <anakata>  * This is free to use in any product, commercial or non-commercial, closed or open source, as long as
[20:57:51] <anakata>  * the following conditions are met:
[20:57:53] <anakata>  * a)
[20:57:56] <anakata>  *   You are NOT affiliated with the RIAA, MPAA, MPA, IFPI, or any similar organization in any way.
[20:57:59] <anakata>  * b)
[20:58:02] <anakata>  *   You are NOT affiliated with any of the following Swedish government entities in any way:
[20:58:02] <The_8472> pastebin...
[20:58:05] <anakata>  *   - Skatteverket / Riksskatteverket / Skattemyndigheten / Kronofogdemyndigheten / Kronofogden
[20:58:09] <anakata>  *   - Polisen / Polismyndigheten / Rikskriminalpolisen / Lanskriminalpolisen
[20:58:10] <erdgeist> Too late :/
[20:58:12] <anakata>  *   - Aklagarmyndigheten / Domstolsverket
[20:58:16] <anakata>  * c)
[20:58:18] <anakata>  *   Credit is given to "Estoy Ltd. Seychelles IBC <http://www.estoykh.com>"
[20:58:19] <erdgeist> *scroll*
[20:58:21] <anakata> (sorry for long paste :))
[20:58:45] <TheSHAD0W> Hehe.
[20:58:48] <burris> you don't need a license to use software, since using an authorized copy of software isn't an exclusive right of copyright holders
[21:00:44] <erdgeist> burris: What's your point here?
[21:00:58] <erdgeist> burris: you're not really buying the legales aspects of the license?
[21:01:40] <anakata> well if you belong to any of the groups prohibited according to it i you do per definition believe in a strict copyright regime for digital media :)
[21:02:40] <erdgeist> anakata: no, you don't. you just prented to in whichever circumstances make you the most money
[21:02:51] <anakata> ah right
[21:03:54] <The_8472> they believe in fair use too, if they can include it in their own productions after all
[21:04:27] <burris> reminds me of those "welcome to my krad bbs, if you're a cop or journalist please disconnect now"
[21:04:36] <anakata> i'd definitely sue if it was violated though!
[21:05:18] <anakata> demand a civil-party search warrant, IPRED information judgement, temporary injunction, etc
[21:05:47] <The_8472> and face hordes of overpaid lawyers?
[21:05:49] <erdgeist> anakata: eheh. which would -- of course -- be totally successful
[21:06:27] <anakata> no, but which would cost them a lot of time and money
[21:06:34] <anakata> and be funny as hell
[21:06:56] <The_8472> which they then just include in their calculations for their next extortion campaign
[21:08:12] <anakata> consiering how pissed off mr danowsky got over my little "DDo$" hack i came up with when i was drunk on a satellite connetion at the edge of civilization i can't really imagine how pissed they would be at orchestrated lega flooding..
[21:08:26] <anakata> legal*
[21:08:38] <anakata> oh well
[21:08:42] <anakata> more tech, less legalese!
[21:09:24] <The_8472> <anakata> more tech, less legalese! <- excellent approach
[21:09:49] <erdgeist> The_8472: *nod*
[21:09:59] <anakata> whats a good low-weight linux bt client that does DHT well ?
[21:10:09] <anakata> funnily enough i rarely use bt myself :p
[21:10:21] <TheSHAD0W> For *nix?  Or Windows?
[21:10:30] <anakata> *nix
[21:10:41] <TheSHAD0W> ...
[21:10:46] <TheSHAD0W> None.  :-P
[21:10:58] <erdgeist> anakata: transmission, soonish
[21:11:00] <TheSHAD0W> Well, maybe there's a libtorrent derivative out there.
[21:11:04] <anakata> im not gonna fucking start vmware to do bt!
[21:11:17] <anakata> besides vmware eats more memory than physically available about half the times i start it :PP
[21:11:20] <TheSHAD0W> utorrent will run in wine...
[21:11:35] <TheSHAD0W> vuze will run in Linux, but calling it low-weight would be an error...
[21:11:37] <anakata> could setup rdesktop to some win box at the office on monday
[21:12:10] <The_8472> well, you could make a standalone version of the mainline dht plugin for vuze, it's fairly independent code
[21:12:19] <TheSHAD0W> Even BitTornado has some "weight" issues.
[21:12:26] <anakata> i want a known reference client for testing :p
[21:12:37] <anakata> im not gonna develop dht stuff with my code at both ends of the communication
[21:12:53] <TheSHAD0W> utorrent is "the" reference client ATM, and it'll run in wine.
[21:12:57] <anakata> cool
[21:13:04] <erdgeist> burris: are you involved with uT-development?
[21:13:07] <anakata> yeah i know utorrent is kinda reference for win
[21:13:15] <anakata> and ludde is a nice guy :)
[21:13:37] <anakata> spotify launch party couldve had more booze though ..
[21:13:52] <DWKnight> EVERY launch party can have more booze
[21:14:00] <burris> DWKnight++
[21:14:07] <DWKnight> either by volume
[21:14:09] <DWKnight> or by quality
[21:14:11] <burris> erdgeist, nope
[21:14:27] <anakata> actually there is a limit
[21:14:39] <anakata> i once was at a party that ended up with me arrested for attempted murder... :p
[21:15:01] <anakata> ok wtf
[21:15:02] <TheSHAD0W> o__O
[21:15:15] <anakata> i hit 'Install' in the installer and nothing happens except i get this error
[21:15:19] <The_8472> there even is a physical limit. too much booze and the schwarzschild radius would exceed it's own volume (if contained in any compact body such as a sphere)
[21:15:21] <anakata> fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls"
[21:16:04] * TheSHAD0W has a copy of an early utorrent beta
[21:16:09] <TheSHAD0W> Dated 2004...
[21:16:32] <anakata> hm maybe vmware wont eat my soul if i add like 8gb swap..
[21:16:47] <TheSHAD0W> Why won't you use wine?
[21:17:02] <TheSHAD0W> It's bloaty but nowhere like vmware...
[21:18:23] <anakata> i just tried and it didnt work :(
[21:18:47] <TheSHAD0W> Really?
[21:18:48] <TheSHAD0W> Hm.
[21:18:52] <DWKnight> what ut/wine versions?
[21:19:05] <anakata> latest ut
[21:19:12] <anakata> wine says wine-1.0
[21:19:16] <anakata> probably ancient as fuck
[21:19:23] <anakata> i only upgrade if actually neccessary
[21:20:14] <anakata> and oh regarding not upgrading, there doesnt happen to be any BT client for IBM OS/360? :P
[21:20:39] <TheSHAD0W> Got a Python interpreter for it?  ^__^
[21:20:48] <anakata> is COBOL close enough? :PP
[21:20:57] <anakata> this aint *ix :)
[21:21:13] <anakata> the architecture/design is quite exactly 100% upside down
[21:21:22] <anakata> for example, out of the box the system doesnt have multitasking
[21:21:35] <anakata> or any multiuser capabilities
[21:21:54] <anakata> you have to run the Time Sharing Option module to get that
[21:22:14] <anakata> and it doesnt exactly have 'sockets'..
[21:22:20] <The_8472> what does it do when it sees more than 1 CPU? ^^
[21:22:48] <anakata> well when you boot os/360 it enters batch mode
[21:23:03] <anakata> think mid-70's, university, students feeding punched cards to a mainframe
[21:23:27] <The_8472> ah yes, i have read about that in history books
[21:23:37] <The_8472> i think 1 or 2 chapters after hand-axes
[21:23:58] <anakata> im currently trying to get os/360 compilation (well, assembly) going in an emulator
[21:24:13] <anakata> there's something about 1.9 million lines of archaic ASM...
[21:31:18] <anakata> by the way, for the next version of BT, can someone please please replace benc :)
[21:34:03] <alus> with ebencode? :D
[21:34:03] <TheSHAD0W> Bencode?
[21:34:07] <alus> or json
[21:34:13] <alus> but json sucks - it requires escaping
[21:34:16] <anakata> with something i design based on esbuf_serialize()!
[21:34:30] <alus> anakata: what is that
[21:34:41] <anakata> my serializing/unserializing functions :p
[21:34:49] <alus> are they length-prefixed?
[21:35:02] <anakata> generally yes
[21:35:07] <alus> well that would be fine then
[21:35:09] <anakata> unless for fixed len datatypes
[21:35:13] <alus> sure
[21:35:14] <TheSHAD0W> http://estoykh.com/opensource/esbuf/
[21:35:17] <anakata> they currently dont have built-in nesting though
[21:35:31] <DHE> is bencoding really that bad?
[21:35:33] <anakata> but its easy to do with an external layer
[21:35:42] <The_8472> <anakata> by the way, for the next version of BT, can someone please please replace benc :) <- why? bencoding only lacks a few data types imo
[21:35:53] <The_8472> parsing it is pretty straightforward and can be done single-pass
[21:36:02] <anakata> dhe: it just doesnt feel like its meant to 1) be decoded as effectively as possible and 2) be decoded in a language that doesnt have built-in associative arrays
[21:36:45] <TheSHAD0W> If the language doesn't have associative arrays, then it's going to be a pain whatever you do.
[21:36:50] <The_8472> indeed
[21:37:05] <alus> anakata: what do you mean by effective decoding?
[21:37:08] <The_8472> and decoding is actually pretty fast with bdecoding if you optimize your implementation a bit
[21:37:40] <DHE> I made something pretty decent in PHP. It was my teach-myself-PHP project and it worked out perfectly. It couldn't have been that bad.
[21:37:45] <The_8472> unless you insist on zero-copy behavior
[21:37:52] <erdgeist> Ahh, I still like it
[21:38:02] <anakata> alus: performance?
[21:38:06] <anakata> code size?
[21:38:11] <erdgeist> I have abstracted it away in C, without copying
[21:38:18] <anakata> ya its definitely doable
[21:38:26] <anakata> thats not the problem
[21:38:51] <erdgeist> and it's got very fast caching accessors
[21:38:53] <anakata> writing an XML parser was just several hours of intense agony
[21:38:56] <anakata> benc cant be any worse
[21:39:16] <The_8472> bencoding is way simpler than XML parsing
[21:39:19] <alus> anakata: http://barnesc.blogspot.com/2006/01/rencode-reduced-length-encodings.html
[21:39:33] <erdgeist> well, it's sorted alphabetically.
[21:39:40] <anakata> for one- or two-byte keys you can do some nice integer tricks atleast
[21:39:45] <alus> anakata: btw no way did you write a fully compliant XML parser ;)
[21:39:53] <TheSHAD0W> anakata: I know you're a great coder, but don't reinvent the wheel; there are several C codecs out there.
[21:40:12] <anakata> when you now what data to expect
[21:40:16] <anakata> alus: heh no
[21:40:33] <anakata> theshadow: i need them to use my buffer/memory mgmt
[21:40:43] <anakata> thats one of the primary reasons i wrote my own xml lib
[21:40:54] <The_8472> wrap malloc?
[21:41:08] <anakata> it doesnt exactly work that way :)
[21:41:19] <anakata> besides i generally dont trust other peoples stuff
[21:41:27] <The_8472> people even implemented garbage collection for C by replacing malloc and free...
[21:41:35] <anakata> thats related to what i do
[21:41:56] <anakata> it uses a concept called 'contexts'
[21:42:02] <anakata> all allocated buffers belong to a context
[21:42:04] <The_8472> anyway, bencoding is not really bad. maybe a bit unflexible... but we have tons of maps (associative arrays) to throw around in bittorrent
[21:42:12] <The_8472> so it's quite appropriate for that use
[21:42:15] <anakata> one context can be for example one program module, one connection, one function, etc
[21:42:35] <The_8472> 2 words: garbage collector
[21:42:46] <anakata> i want full manual control though
[21:43:11] <The_8472> well, D provides garbage collection + manual memory management
[21:43:35] <anakata> i don't code C because i want stuff to happen by magic :p
[21:43:56] <alus> yeah manual memory control is nice, even if there is a GC
[21:44:02] <erdgeist> I only code C because I don't want stuff magically happen
[21:44:31] <TheSHAD0W> C is great because of its low level.
[21:44:44] <The_8472> well, i prefer stuff to happen magically, if it's in a well-specified way. like the convention-over-configuration stuff in grails
[21:44:50] <TheSHAD0W> Gives you the best possible efficiency and predictability.
[21:44:52] <anakata> i code either c, asm or shellscript
[21:44:55] <anakata> thats the 3 levels i need :)
[21:44:59] <TheSHAD0W> But I prefer Python because I'm damn lazy.  :-P
[21:45:11] <The_8472> C is just beautified asm imo
[21:45:18] <The_8472> way too unproductive
[21:45:53] <The_8472> good for high-performance stuff... but you have to do way too much manually where it's not necessary
[21:45:55] <anakata> asm is pretty productive on its own .. ? :P
[21:46:24] <erdgeist> The_8472: Depends on the level of abstraction you can provide through libraries
[21:47:40] <The_8472> another thing that always perplexed me about C is that it claims to be low-level... and yet has not a single function to let me check overflows after arithmetic operations
[21:48:41] <anakata> yeah, that and bitwise rotation
[21:48:52] <anakata> though overflow handling isnt entirely platform independent
[21:49:15] <The_8472> well, compilers optimize rotation if you do a << x | a >> n-x
[21:49:25] <erdgeist> It's a macro assembler and can only abstract what processors provide
[21:49:30] <alus> anakata: have you looked at Go?
[21:49:50] <anakata> Go?
[21:50:03] <alus> http://golang.org/
[21:56:23] *** GTHK has joined #bittorrent
[21:57:50] <anakata> thanks but no thanks
[21:58:04] <alus> haha
[21:58:19] <alus> the type system is neat though
[21:58:24] <alus> and uh, coroutines are good
[21:58:35] *** nGTHK has joined #bittorrent
[22:06:47] *** The_8472 has quit IRC
[22:06:58] <anakata> heh me and erdgeist had a discussion on formats for serializing earlier, and he said that even with an entirely binary format you'll still have overhead because of big/little endian... so of course i had to check if gcc -O3 doesnt properly use BSWAP on x86/64 so endianness conversions only means a few cycles extra :)
[22:07:17] *** The_8472 has joined #bittorrent
[22:07:19] <anakata> i think i still havent gotten over my youth of doing gfx for 486 and early pentium :P
[22:08:51] <alus> aren't you optimizing a bit beyond the speed of transfering the data over the network anyway?
[22:09:06] <anakata> back then network meant 28k8 dialup!
[22:09:07] <anakata> :D
[22:10:05] <anakata> oh the nostalgia... timing with the horizontal retrace and doing various tricks with the gfx card between each line
[22:11:14] <anakata> any interrupts enabled such as normal 18.2Hz timer == instant fail :)
[22:13:02] <anakata> though you could get enough spare cpu time to do a round of PIO adlib/soundblaster music playing in the mainloop provided that you werent doing raster tricks with the entire monitor.. i remember that i used this to do effects in textmode apps
[22:13:06] <anakata> nostalgiaaaaaa :(
[22:13:25] <alus> anakata: do we need to put you back in your rockingchair?
[22:13:36] <anakata> kids of today blah blah blah blah !
[22:13:38] <anakata> young whippersnapper !
[22:14:02] * The_8472 grins and enables double buffering
[22:14:33] <anakata> did a fun version of double buffering when doing effects in 80x25 textmode
[22:14:48] <anakata> changed it to 160x25 (with 80x25 visible)
[22:15:53] *** GTHK has quit IRC
[22:16:16] <anakata> ok, how do you change the damn tmp dir of vmware ?!
[22:16:34] <alus> rm -rf
[22:23:14] *** gilles has joined #bittorrent
[22:25:21] <anakata> so, what would happen if you manually created/edited torrents so that your dht host:port would be included in nodes?
[22:26:02] <The_8472> nothing special, dht implementations may use those nodes to bootstrap their DHT if they couldn't bootstrap so far
[22:26:03] <anakata> couldnt you make sure you actually get included in all lookups?
[22:26:10] <The_8472> no
[22:26:32] <The_8472> wouldn't be necessary anyway
[22:28:33] <anakata> oh well will see what i can accomplish
[22:28:57] <anakata> if global dht has a meltdown a la mabell 1990 then you know who caused it :p
[22:50:52] *** bt42 has quit IRC
[23:18:41] *** gilles has quit IRC
[23:24:11] *** MassaRoddel has quit IRC
[23:27:25] *** anakata has quit IRC
[23:44:35] *** nGTHK is now known as GTHK
[23:54:19] *** HandheldPenguin is now known as HandheldPenguin`
[23:54:39] *** HandheldPenguin` is now known as HandheldPenguin
[23:55:07] *** HandheldPenguin is now known as HandheldPenguin`





top