[00:05:52] <The_8472> and it's extra delay. above the baseline
[00:05:58] <The_8472> i always have to remind myself of that somehow
[00:07:36] <alus> yes
[00:08:39] <alus> but we don't differntiate between packet sizes when taking measurements
[00:08:52] <alus> so if the application sends only one byte, and a packet leaves, that affects the new minimum
[00:09:08] <kitsoran> Stupid router sacrifices dhcp before dropping packets >-<
[00:09:29] <alus> so the delay should be greater than one full-sized packet, or you'll get a groundhog effect
[00:15:32] <The_8472> what about adjusting the delay measurement for packet sizes?
[00:15:49] <alus> thought about it. too hard. gave up
[00:16:13] <The_8472> i see
[00:17:02] <The_8472> probably one of those "works asymptotically" things
[00:50:53] *** ProperNoun has joined #bittorrent
[00:51:40] *** ProperNoun has quit IRC
[00:51:40] *** ProperNoun has joined #bittorrent
[00:52:54] *** init0_ is now known as init0
[01:01:28] *** medecau has quit IRC
[01:22:17] *** The_8472 has quit IRC
[01:42:45] *** ProperNoun has quit IRC
[01:43:03] *** ProperNoun has joined #bittorrent
[01:43:07] *** ProperNoun has joined #bittorrent
[01:52:24] *** kitsoran has quit IRC
[01:59:57] *** kitsoran has joined #bittorrent
[02:28:00] *** K`Tetch has joined #bittorrent
[02:28:01] *** K`Tetch has joined #bittorrent
[02:35:48] *** freakazoid has joined #bittorrent
[03:16:20] *** ProperNoun has quit IRC
[03:22:56] *** Gottaname|Mobili has joined #bittorrent
[03:25:07] *** kitsoran has quit IRC
[03:40:46] *** goussx has quit IRC
[03:53:38] *** goussx has joined #bittorrent
[04:37:51] *** freakazoid has quit IRC
[05:37:37] *** kitsoran has joined #bittorrent
[06:51:00] *** Switeck has quit IRC
[06:54:58] *** MassaRoddel has quit IRC
[07:12:22] *** MassaRoddel has joined #bittorrent
[07:43:35] *** multi-d has quit IRC
[07:46:06] *** kitsoran has quit IRC
[08:17:43] *** gde33 has joined #bittorrent
[08:25:34] *** ygrek has joined #bittorrent
[08:32:39] *** ygrek has quit IRC
[08:45:41] *** ygrek has joined #bittorrent
[09:09:48] *** hydri has quit IRC
[09:50:39] *** ygrek has quit IRC
[10:07:42] *** goussx has quit IRC
[10:51:06] *** andar has quit IRC
[11:22:17] *** andar has joined #bittorrent
[12:02:01] *** Gottaname|Mobili has quit IRC
[12:10:31] *** init0_ has joined #bittorrent
[12:11:51] *** init0 has quit IRC
[12:27:38] *** ygrek has joined #bittorrent
[12:33:26] *** stalled has quit IRC
[12:42:08] *** stalled has joined #bittorrent
[13:25:45] *** chelz has quit IRC
[13:35:59] *** ygrek has quit IRC
[13:59:12] <Tanguy> Hello.
[13:59:48] <Tanguy> I have another question about the DHT. Do keys, that is, infohashes, expire after some time unused?
[14:00:42] <Tanguy> For instance, if I publish a file, it will get tracked by the node closest to its infohash. If that file was just a test, and that nobody uses it, will it stay forever in the DHT?
[14:01:02] <Tanguy> And will the DHT keep growing forever?
[14:06:34] *** stalled has quit IRC
[14:15:38] *** stalled has joined #bittorrent
[14:57:58] <f[x]> Tanguy, you need to republish every 15 min or so
[14:58:04] <f[x]> it is mentioned in BEP
[15:14:12] <Tanguy> Okay, thank you, I must have missed that.
[15:14:47] <Tanguy> Now, last question, the DHT highly relies in the cooperation of all the peers, doesn't it?
[15:15:37] <Tanguy> For instance, an attacker could deliberately join the DHT with an ID equal to the infohash of a file I am publishing, and answer crap instead of tracking it as it would be supposed to do.
[15:21:39] <Tanguy> f[x]: In fact what did not seem obvious to me is that the node closest to a given infohash should remove this infohash when it has no associated peer. But in fact, I suppose it is obvious, because no entry and empty entry can mean the same thing.
[15:22:24] <f[x]> Tanguy, yes there are some attacks with malicious nodes but you need more than one close to be successful
[15:22:40] <f[x]> remember that popular ids are stored on more than one node (for caching purposes)
[15:23:16] <Tanguy> That is right.
[15:23:27] <Tanguy> Okay, I think I know what I needed about the DHT.
[15:24:40] <Tanguy> I am not coding a BitTorrent client, but simply trying to understand the DHT before I start using it in replacement of trackers, and documenting the way I am using it.
[15:25:24] <Tanguy> And by the way, I wrote a metainfo generator, in order to create trackerless torrents, because I did not find an existing one, at least packaged in Debian.
[15:25:53] <Tanguy> I that can be of any use: <http://tanguy.ortolo.eu/blog/article15/new-gentorrent>.
[15:31:54] <Tanguy> I also implemented the Merkle tree extension. I do not know if it is much used, in fact I suspect that it is not widely supported, and given that it is incompatible, not widely used.
[15:34:28] <f[x]> the more clients support merkle trees the more it will be used in future I guess
[15:35:52] <Tanguy> Certainly. Anyway, there is now at least one metainfo generator supporting it, though I did not test it extensively.
[15:35:58] <Tanguy> :-)
[15:44:31] *** ygrek has joined #bittorrent
[15:46:19] *** mxs has quit IRC
[15:46:22] *** mxs_ has joined #bittorrent
[15:46:22] *** mxs_ has joined #bittorrent
[15:46:32] *** mxs_ is now known as mxs
[15:52:18] *** BentMyWookie_ has joined #bittorrent
[15:54:44] *** BentMyWookie has quit IRC
[15:54:44] *** BentMyWookie_ is now known as BentMyWookie
[16:37:59] *** freakazoid has joined #bittorrent
[16:38:40] *** traviscj has quit IRC
[16:42:54] <Tanguy> The next thing I want to implement is magnet links generation. Is there a decent specification anywhere? The most detailed document I found is the Wikipedia page.
[17:03:52] *** traviscj has joined #bittorrent
[17:36:22] *** freakazoid has quit IRC
[17:52:17] *** goussx has joined #bittorrent
[18:33:57] *** goussx has quit IRC
[18:40:13] *** traviscj has quit IRC
[18:46:23] *** goussx has joined #bittorrent
[18:47:54] *** traviscj has joined #bittorrent
[18:51:44] *** goussx has quit IRC
[18:57:26] *** traviscj has quit IRC
[19:08:06] *** freakazoid has joined #bittorrent
[19:08:44] *** goussx has joined #bittorrent
[19:20:54] *** ygrek has quit IRC
[19:22:00] *** mxs has quit IRC
[19:22:01] *** mxs_ has joined #bittorrent
[19:22:01] *** mxs_ has joined #bittorrent
[19:22:03] *** mxs_ is now known as mxs
[19:31:32] *** traviscj has joined #bittorrent
[19:38:14] *** traviscj has quit IRC
[19:38:52] *** traviscj has joined #bittorrent
[19:43:25] *** Switeck has joined #bittorrent
[19:51:27] *** freakazoid has quit IRC
[20:02:00] *** freakazoid has joined #bittorrent
[20:12:04] *** kitsoran has joined #bittorrent
[20:35:47] *** radioman-lt has joined #bittorrent
[21:14:36] *** KyleK_ has joined #bittorrent
[21:23:09] *** The_8472 has joined #bittorrent
[21:24:21] *** freakazoid has quit IRC
[21:29:37] *** freakazoid has joined #bittorrent
[21:32:08] *** Switeck has quit IRC
[21:35:43] <TheSHAD0W> http://www.fiercewireless.com/story/bittorrent-actually-network-capacity-savior/2011-06-30
[21:37:21] *** goussx has quit IRC
[21:41:42] <The_8472> if commercial entities consider ledbat support i consider that a good thing(tm)
[22:10:16] *** freakazoid has quit IRC
[22:11:54] <Tanguy> Do you know if there is a way to represent the metainfo nodes entry (for DHT initialization) in a magnet link?
[22:12:26] <Tanguy> I would imagine something like xs=bt://node:port (URL-encoded, of course) but is that specified or adopted?
[22:13:08] <Tanguy> Perhaps btdht:// instead, in fact.
[22:14:14] <DWKnight> there is no nodes definition in magnets
[22:14:43] <Tanguy> This is not cool.
[22:14:49] <Tanguy> Is there a way to propose one?
[22:15:02] <alus> bittorrent.org
[22:15:26] <Tanguy> I am coding a metainfo and magnet link generator, this is why I am asking.
[22:16:24] <Tanguy> Okay, I shall ask on the forums, first to see whether or not it is worth doing a BEP.
[22:17:04] <Tanguy> Perhaps this could be the occasion of specifying magnet links for BitTorrent, actually, because they do not seem to be.
[22:17:34] <alus> that seems unrelated
[22:17:39] *** KyleK_ has quit IRC
[22:17:57] <Tanguy> What seems unrelated to what?
[22:18:02] <alus> "btih" is specification enough that you need to speak BitTorrent to use that magnet uri
[22:18:42] <Tanguy> Well, there is a way to indicate other stuff that can be used by a BitTorrent client.
[22:18:44] <alus> adding a "dhtnode" paramater seems like a good thing, and can stand by itself as a BEP
[22:18:49] <Tanguy> For instance, tr=, for trackers.
[22:19:20] <Tanguy> I think xs= would be more appropriate. Anyway this is what would have to be discussed.
[22:20:05] <alus> "xs="?
[22:20:09] <alus> for the dht node address?
[22:20:49] <alus> that seems incorrect. xs is an exact source address
[22:20:54] <Tanguy> In my generator, this is what I am using in magnet links: dn (name), xl (length), xt (infohash), tr (tracker) and as (HTTP direct downoad, aka HTTP seeding, GetRight style, if I am correct).
[22:21:29] <Tanguy> According to Wikipedia, which is the most complete source of information I found about magnet links:
[22:21:39] <Tanguy> "xs" stands for "exact source". It is either an HTTP (HTTPS, FTP, FTPS, etc.) download source for the file linked to by the Magnet link, the address of a P2P source for the file or the address of a hub (in the case of DC++).
[22:21:52] <Tanguy> <http://en.wikipedia.org/wiki/Magnet_link#P2P_.28xs.29>
[22:22:05] <DWKnight> dht nodes don't necessarily have the file
[22:22:07] <alus> sure, so you could put an http url in xs=
[22:22:18] <DWKnight> so no, xs wouldn't be appropriate for a dht bootstrap
[22:22:20] <Tanguy> Neither do DC++ hubs.
[22:22:55] <alus> DC++ hubs are not global
[22:23:03] <Tanguy> Well, then it has been a mistake to include DC++ hubs in it.
[22:23:09] <Tanguy> > This link connects a DirectConnect client immediately to the hub in question.
[22:23:16] <Tanguy> Ooops, wrong paste.
[22:23:33] <alus> arguably, yes. putting DC++ urls there was not correct
[22:23:40] <Tanguy> > For this link a client tries to connect directly and asks for the file and/or its sources
[22:23:53] <Tanguy> and/or its sources: this seems to match DHT nodes.
[22:23:56] <alus> unless you can ask that DC++ hub for the file by name
[22:24:03] <alus> no, DHT nodes don't route for you
[22:24:23] <Tanguy> They do not, but you still ask them.
[22:24:39] <Tanguy> And they either reply, or give other closer nodes, don't tey?
[22:24:43] <Tanguy> they*
[22:25:53] <Tanguy> Anyway, tracker address has been put in a special magnet field, so I guess the same should be done for DHT nodes for consistency.
[22:26:20] <Tanguy> I was just trying to find whether or not an existing field could do it, because it would be better than introducing a new one.
[22:26:29] <Tanguy> Anyway, this will be subject of discussion.
[22:27:10] <alus> there's not a particular reason not to add a new field. people have to add support for what that field means
[22:27:28] <Tanguy> That's right, indeed.
[22:27:46] <Tanguy> So, I guess I have everything I needed. Thanks.
[22:30:13] *** ygrek has joined #bittorrent
[22:32:18] *** mick_laptop has quit IRC
[22:32:18] *** mick_laptop has joined #bittorrent
[22:32:43] *** goussx has joined #bittorrent
[22:33:26] *** mick_laptop has left #bittorrent
[22:36:03] *** snooplsm has joined #bittorrent
[22:36:44] <snooplsm> I'm working on bittorrent client for class.  Right now i'm stuck on the handshake portion.  I send my handshake request to the client but I am not sure what I am to expect back.
[22:36:59] <snooplsm> I am expecting a message in the format:  <length prefix><message ID><payload>?
[22:37:33] <snooplsm> The reason I ask is that I am using DataInputStream and am reading an integer, however that integer is fairly large in size.
[22:41:30] <The_8472> you're expecting a handshake.
[22:43:02] <Tanguy> By the way, when using a magnet link, how does the client get the metainfo? Do DHT nodes responsible for a torrent also store the full metainfo?
[22:45:35] <The_8472> read BEP9
[22:46:31] <Tanguy> Got it.
[22:57:25] <snooplsm> The_8472: thanks
[22:57:31] <snooplsm> just figured that out in wireshark
[23:00:00] <The_8472> *pats* well done, son. normally they don't think of that.
[23:45:40] *** ygrek has quit IRC

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