94 lines
7.0 KiB
HTML
94 lines
7.0 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}I2P Development Meeting 142{% endblock %}
|
|
{% block content %}<h3>I2P dev meeting, August 9, 2005</h3>
|
|
<div class="irclog">
|
|
<p>13:11 < jrandom2p> 0) hi</p>
|
|
<p>13:11 < jrandom2p> 1) 0.6.0.2</p>
|
|
<p>13:11 < jrandom2p> 2) roadmap update</p>
|
|
<p>13:11 < jrandom2p> 3) ???</p>
|
|
<p>13:11 < jrandom2p> 0) hi</p>
|
|
<p>13:11 * jrandom2p waves</p>
|
|
<p>13:11 <+detonate> hi</p>
|
|
<p>13:11 < jrandom2p> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000839.html</p>
|
|
<p>13:12 < jrandom2p> ok, jumping in briefly to [1-2] before the freeforall..</p>
|
|
<p>13:12 < jrandom2p> 1) 0.6.0.2</p>
|
|
<p>13:12 < jrandom2p> its out. and stuff</p>
|
|
<p>13:12 < jrandom2p> anyone have any questions/comments/concerns w/ 0.6.0.2?</p>
|
|
<p>13:13 < jrandom2p> if not, moving on to 2) roadmap update</p>
|
|
<p>13:13 < jrandom2p> the, er, roadmap has been updated. and stuff ;)</p>
|
|
<p>13:14 < duck> you aussie</p>
|
|
<p>13:14 <+bla> jrandom: There still are intermittent problems contacting a destination, even when it's normally up</p>
|
|
<p>13:14 * postman can second this</p>
|
|
<p>13:14 * detonate can third that</p>
|
|
<p>13:14 <+bla> jrandom: E.g., forum.i2p works fine, then after a few minutes it doesn't, and requires a few reloads</p>
|
|
<p>13:15 * bla firsted it ;)</p>
|
|
<p>13:15 < jrandom2p> hmm, aye, i've heard reports of that. with 0.6.0.2 as well, right?</p>
|
|
<p>13:16 <+postman> indeed sir</p>
|
|
<p>13:16 <+bla> Yes, 0.6.0.2</p>
|
|
<p>13:16 <+bla> Could be netDb trouble, or poor selection of peers to put in tunnels (or something else)</p>
|
|
<p>13:16 < jrandom2p> 'k</p>
|
|
<p>13:17 < jrandom2p> the tunnel peer selection has been pretty bad lately, as has netDb store flooding</p>
|
|
<p>13:17 < jrandom2p> (see your /oldstats.jsp for tunnel request failure counts)</p>
|
|
<p>13:18 <+bla> Now that we use UDP/SSU, peer classification seems to be better than before: a number of peers I _know_ to be fast, usually show up under the "fast" section on the profile pafe</p>
|
|
<p>13:19 < jrandom2p> nice</p>
|
|
<p>13:19 < jrandom2p> 0.6.0.2 added some tunnel rejection code based on the netDb that it should have been doing before (refusing to join if we can't find the next hop), so the increase in rejections is expected</p>
|
|
<p>13:19 <+bla> Though I really should get going at the classification algorithms again... ;)</p>
|
|
<p>13:20 < jrandom2p> i've been doing profile/stat analysis, but no solid results yet</p>
|
|
<p>13:21 < jrandom> that would be cool bla :)</p>
|
|
<p>13:25 < jrandom2p> ok, anything else on 2) roadmpa update? :)</p>
|
|
<p>13:26 < jrandom2p> if not, moving on to 3) ???</p>
|
|
<p>13:26 <+detonate> do you think it would be useful to shitlist peers with high failure/duprecv rates compared to the mode?</p>
|
|
<p>13:27 < jrandom> hmm, i'm not sure about that - if the failure/dup rates are too high to be useful, we should just transfer slowly and carefully</p>
|
|
<p>13:27 < jrandom> as long as messages are getting through, messages are getting through</p>
|
|
<p>13:28 < jrandom> there's a reason why we haven't used stats on direct peer communication as part of our profiling - depending upon them would make us vulnerable to some easy and powerful attacks (acting differently to different peers and see who uses you, etc)</p>
|
|
<p>13:29 <+detonate> hmm</p>
|
|
<p>13:29 <+detonate> ok</p>
|
|
<p>13:29 < jrandom> but perhaps we need to drop sessions for peers who are in such congested cons</p>
|
|
<p>13:29 <+detonate> good point</p>
|
|
<p>13:34 < jrandom> ok, anyone else have something to bring up for 3) ???</p>
|
|
<p>13:34 < luckypunk> o,oh, maybe you should wait ti leveryone is back</p>
|
|
<p>13:34 < luckypunk> before asking critical questions :P</p>
|
|
<p>13:35 < jrandom2p> bah, they've got the mailing list ;)</p>
|
|
<p>13:35 < luckypunk> well</p>
|
|
<p>13:35 < luckypunk> i guess this is the right place to whine</p>
|
|
<p>13:36 < luckypunk> I2P still uses a bit of CPU</p>
|
|
<p>13:36 < luckypunk> but not as much as before</p>
|
|
<p>13:36 < luckypunk> true, i haven't run it since the 5.0 days</p>
|
|
<p>13:36 < luckypunk> but yeah</p>
|
|
<p>13:36 < luckypunk> er</p>
|
|
<p>13:36 < luckypunk> 0.5.0</p>
|
|
<p>13:36 < jrandom2p> cool, which of your boxes works with it?</p>
|
|
<p>13:36 < luckypunk> er</p>
|
|
<p>13:36 < luckypunk> ffs</p>
|
|
<p>13:36 < luckypunk> i haven't used it since 0.6.0.0</p>
|
|
<p>13:36 < luckypunk> it works fine with the pentium 2</p>
|
|
<p>13:37 < luckypunk> the default nice value mens it tends to crashif i do anything too CPU intensive for too long as I2P gets CPU starved</p>
|
|
<p>13:38 <+detonate> hmm, i guess there could be a space in the router console network config to hardwire the introducers, once there are introducers, if the user prefers</p>
|
|
<p>13:39 < jrandom2p> are you on 0.6.0.2 now luckypunk?</p>
|
|
<p>13:39 <@smeghead> detonate: that's trusted route stuff... later on in the roadmap :)</p>
|
|
<p>13:39 < luckypunk> no</p>
|
|
<p>13:39 < luckypunk> i haven't run it since 0.6.0.0</p>
|
|
<p>13:39 <@smeghead> *restricted route</p>
|
|
<p>13:40 < luckypunk> but it's CPU use seemed much less.</p>
|
|
<p>13:40 <+detonate> heh, it should be there as soon as there's introducers :)</p>
|
|
<p>13:40 < jrandom2p> ah yeah detonate, the introducer selection could certainly be configurable, but it'll probably be a hidden advanced config option ;)</p>
|
|
<p>13:41 < jrandom2p> luckypunk: 0.6.0.1 cut out a lot of crypto, and 0.6.0.2 should help further. give it a try sometime, it may handle it better</p>
|
|
<p>13:41 < luckypunk> ok</p>
|
|
<p>13:41 <@smeghead> what if an introducer doesn't want you selecting them all the time?</p>
|
|
<p>13:41 < luckypunk> i have the feeling I2P would on a dedicated mid range pentium now.</p>
|
|
<p>13:41 < jrandom> smeghead: then they say "fuck off, i'm not going to serve as an introducer for you"</p>
|
|
<p>13:42 < jrandom> and peers will have multiple introducers, so it'll be balanced</p>
|
|
<p>13:42 < jrandom> (and its only 2 packets to wire up a new peer, not all packets communicated)</p>
|
|
<p>13:44 <+detonate> if introducers worked differently you could do a majority vote between them to decide which ones are working, but as it stands that doesn't make sense</p>
|
|
<p>13:45 < ant> <jme___> q. where can i find a description of this voting system ?</p>
|
|
<p>13:45 < jrandom> majority doesnt make any sense</p>
|
|
<p>13:45 * jrandom doesnt trust voting any further than i can throw it</p>
|
|
<p>13:45 < jrandom> (especially in light of sybil)</p>
|
|
<p>13:45 < jrandom> an introducer is working if a new peer can contact you through it</p>
|
|
<p>13:47 <+detonate> what's the status of vanguard, that's sort of related</p>
|
|
<p>13:47 <+detonate> while smeghead is around</p>
|
|
<p>13:51 < jrandom> ok, if there isn't anything else...</p>
|
|
<p>13:51 * jrandom winds up </p>
|
|
<p>13:51 * jrandom *baf*s the meeting closed</p>
|
|
</div>
|
|
{% endblock %} |