122 lines
11 KiB
HTML
122 lines
11 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}I2P Development Meeting 170{% endblock %}
|
|
{% block content %}<h3>I2P dev meeting, February 28, 2006</h3>
|
|
<div class="irclog">
|
|
<p>15:11 < jrandom> 0) hi</p>
|
|
<p>15:11 < jrandom> 1) Net status and 0.6.1.12</p>
|
|
<p>15:11 < jrandom> 2) Road to 0.6.2</p>
|
|
<p>15:12 < jrandom> 3) Miniprojects</p>
|
|
<p>15:12 < jrandom> 4) ???</p>
|
|
<p>15:12 < jrandom> 0) hi</p>
|
|
<p>15:12 * Complication quickly reads notes</p>
|
|
<p>15:12 * jrandom waves</p>
|
|
<p>15:12 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001266.html</p>
|
|
<p>15:12 < jrandom> (and here I was posting the notes more than 15 minutes before the meeting! ;)</p>
|
|
<p>15:13 < jrandom> ok while y'all read those oh-so-exciting bits, lets jump on in to 1) Net status and 0.6.1.12</p>
|
|
<p>15:14 < jrandom> as mentioned, the primary goals of the 0.6.1.10-0.6.1.12 releases seem to have been met, addressing the tunnel creation crypto change and improving creation reliability substantially</p>
|
|
<p>15:16 < jrandom> the bumps we saw at 0.6.1.10 are gone, and irc stability seems quite good again</p>
|
|
<p>15:16 < jrandom> anyone have anything else to bring up for 1) Net status and 0.6.1.12, or shall we mosey on over to 2) Road to 0.6.2?</p>
|
|
<p>15:17 <+Complication> Net status over here: no more going back under 20 KB/s :)</p>
|
|
<p>15:18 < jrandom> cool, yeah 0.6.1.12 fixed a pretty large bug in 0.6.1.11 where it wouldn't exploit the bandwidth available. it should now make better use of available resources</p>
|
|
<p>15:20 < jrandom> ok, lets jump on to 2)</p>
|
|
<p>15:20 < jrandom> as mentioned, there are a few things that need to get sorted before the last functional change is put in place for 0.6.2, but we're making progress on that front</p>
|
|
<p>15:20 < nymisis> net status is fine :)</p>
|
|
<p>15:22 < jrandom> word. there'll be more info available on the specifics of the new peer ordering strategies before they come out, but the gist of them should be clear from their brief mention in the notes</p>
|
|
<p>15:23 < jrandom> anyone have any questions/comments/concerns regarding 2) road to 0.6.2?</p>
|
|
<p>15:23 < postman> jrandom: any testnets this time?</p>
|
|
<p>15:24 < postman> (need any routers, particpants to test stuff)</p>
|
|
<p>15:24 < postman> ?</p>
|
|
<p>15:24 <+Complication> The essence of the matter seemed quite straightforward - to limit opportunity for an adversary to harvest diverse statistical data</p>
|
|
<p>15:25 <+Complication> Sounds like a fairly desirable feature</p>
|
|
<p>15:25 < jrandom> postman: the new stuff should work transparently on the live net using local-only info, so shouldn't need a separate net to test</p>
|
|
<p>15:25 < jrandom> aye, exactly Complication </p>
|
|
<p>15:26 < postman> ok</p>
|
|
<p>15:26 < postman> jrandom: are you bold enough to disclose an ETA for 0.6.2 ? :)</p>
|
|
<p>15:27 < blubb> 1 april</p>
|
|
<p>15:27 < jrandom> well, seeing as today is the end of feb, i'd guess march or april</p>
|
|
<p>15:27 < postman> hehe</p>
|
|
<p>15:27 < jrandom> blubb: we've already got an mi6 backdoor scheduled for then ;)</p>
|
|
<p>15:29 <@cervantes> more like an mi6 catflap</p>
|
|
<p>15:29 <@cervantes> (budget cuts)</p>
|
|
<p>15:29 < postman> in an elephant house</p>
|
|
<p>15:30 < nymisis> That's SIS, not MI6, if you're going to be accurate. :)</p>
|
|
<p>15:30 < jrandom> well, lets just call them Them ;)</p>
|
|
<p>15:31 < jrandom> ok, anything else for 2)?</p>
|
|
<p>15:31 < jrandom> if not, lets shimmy on over to 3) miniprojects</p>
|
|
<p>15:31 <@cervantes> sorry "the firm"</p>
|
|
<p>15:34 < jrandom> ok, I just wanted to point out a few neat things that would be 1) simple to do and 2) really useful</p>
|
|
<p>15:34 <+Complication> On the miniprojects side, I'm not sure if my Syndie reply made it or not, but I'm wondering if I could snatch one.</p>
|
|
<p>15:34 <+Complication> Not sure which one yet. Currently practising a little more Java (doing a micro-project :D) just to have added certainty that when I try, I'll be able to handle one</p>
|
|
<p>15:35 < DeltaQ> hmm if i upp the bw on the console is the chanes immediate or reboot needed?</p>
|
|
<p>15:35 <+Complication> When I get ready with the "micro-project" (assuming of course the table hasn't been cleared yet), I'll try picking one</p>
|
|
<p>15:35 < jrandom> w3wt, great Complication </p>
|
|
<p>15:36 < jrandom> DeltaQ: immediately </p>
|
|
<p>15:36 <@cervantes> isn't 1) syndie scheduler a tie in with 4) Download Manager / eepget scheduler</p>
|
|
<p>15:36 <+Complication> DeltaQ: takes effect almost instantly (within the periods that bandwidth gets averaged over)</p>
|
|
<p>15:37 <@cervantes> seems to me that a more generally functional up and download manager would service both needs</p>
|
|
<p>15:37 < jrandom> cervantes: hmm, not necessarily. 1) is pretty focused, and also includes pushes, while 4) is prety generic</p>
|
|
<p>15:37 <+Complication> cervantes: sounds like it could</p>
|
|
<p>15:37 < jrandom> but yeah, the engine behind both is EepGet</p>
|
|
<p>15:37 < jrandom> (eepget does syndie's http transfers, programatically)</p>
|
|
<p>15:38 < DeltaQ> avg doesnt seem yto go above 13kb/s</p>
|
|
<p>15:38 < DeltaQ> i set 64kb/s with 192 burst down</p>
|
|
<p>15:38 < DeltaQ> 32/64 up</p>
|
|
<p>15:38 <@cervantes> so a generic pushing and pulling eepget with a scheduling and management api...</p>
|
|
<p>15:39 <@cervantes> still, in probably ceases to become a mini-project at that point</p>
|
|
<p>15:39 <+Complication> DeltaQ: the average also depends on how much load your client tunnels (and other peers' participating tunnels) generate</p>
|
|
<p>15:39 <+Complication> sorry, s/average/actual bandwidth</p>
|
|
<p>15:39 < jrandom> cervantes: yeah, there's substantial logic involved in the syndie stuff though.</p>
|
|
<p>15:40 < DeltaQ> heh it finally went up</p>
|
|
<p>15:40 < DeltaQ> 1s: 30.82/29.33KBps</p>
|
|
<p>15:40 < DeltaQ> guess i needed up upp the ul bw</p>
|
|
<p>15:40 < jrandom> DeltaQ: the average will also be affected by how other people view you, which depends upon your actions, not any advertized rate, so it'll take a bit</p>
|
|
<p>15:40 <+Complication> DeltaQ: for pass-though traffic (participating tunnels), what comes in must also get out</p>
|
|
<p>15:41 <+Complication> DeltaQ: so very different ul/dl rates would choke participating traffic to the lower of the two</p>
|
|
<p>15:42 <+Complication> DeltaQ: also, participating traffic depends on how other nodes "perceive" your node's routing capacity</p>
|
|
<p>15:42 < DeltaQ> oki</p>
|
|
<p>15:43 <+Complication> If they think it can route well, they'll ask more often</p>
|
|
<p>15:43 < jrandom> ok, if there's nothing else on 3) miniprojects, lets jump on over to 4) ???</p>
|
|
<p>15:43 < jrandom> anyone have anything else to bring up for the meeting?</p>
|
|
<p>15:43 < DeltaQ> well i am behind a router but i did map port 8887 to this pc</p>
|
|
<p>15:43 <+Complication> If it's new, or has only recently increased in capacity, they're a bit shy</p>
|
|
<p>15:44 < DeltaQ> oh sorry i didnt mean to intervere a meeting ^^</p>
|
|
<p>15:44 <+Complication> Someone asked the other day, about possible attacks based on clock skew. I think I saw your answer about the tunneling part (creation message holds only tunnel validity period, not time from its creator's perspective)...</p>
|
|
<p>15:44 <@cervantes> (thanks for the mention in the status notes) ;-)_</p>
|
|
<p>15:46 <+Complication> So I thought, actually, about asking... which points if any at all, in I2P messaging, could contain time from a sender's perspective?</p>
|
|
<p>15:47 <+Complication> I've not managed to dig myself up-to-date on this, so I'm a bit clueless about it</p>
|
|
<p>15:47 < jrandom> Complication: nothing explicitly says "I think it is now $time", but with sufficient traffic and timing analysis, one could likely narrow it down substantially</p>
|
|
<p>15:48 < jrandom> we do quantize the times at a large period, though not as large as our max clock skew, so there is room there</p>
|
|
<p>15:49 <+Complication> Do you think there would ultimately be any benefit to receive from a more "streamlined" NTP client?</p>
|
|
<p>15:49 <+Complication> One which would / could easier keep skews smaller?</p>
|
|
<p>15:50 < jrandom> well, since the sntp client was introduced into i2p, its been getting better and better so that now we don't see the variation we used to</p>
|
|
<p>15:51 < jrandom> perhaps we could reduce the minimum-skew limit from 10s to perhaps 2 or 3s, or maybe less</p>
|
|
<p>15:51 < jrandom> alternately, we could allow it to look at the ssu clock skews as well to avoid unecessary skews</p>
|
|
<p>15:52 <+Complication> Or alternatively, could it be possible to limit further any opportunity to guess at another peer's possible clock value?</p>
|
|
<p>15:53 * Complication doesn't know which way would be more practical, just suggesting random possibilities :D</p>
|
|
<p>15:53 < jrandom> no, we know the clock skew of directly connected peers</p>
|
|
<p>15:55 < Magii> is there anyway to tell if the update was done successfully?</p>
|
|
<p>15:55 <+Complication> Aha, so session protocol really depends on that info..</p>
|
|
<p>15:55 < tethra> look at your version number</p>
|
|
<p>15:55 <+Complication> Magii: it should file a CRIT like "update verified, restarting to install" in logs</p>
|
|
<p>15:55 < tethra> :/</p>
|
|
<p>15:55 <+Complication> Then, it should count down minutes to a graceful restart</p>
|
|
<p>15:56 <+Complication> And finally restart</p>
|
|
<p>15:57 <+Complication> Oh, sidenote: does the internal NTP client know of a concept like "clock drift rate"?</p>
|
|
<p>15:58 < jrandom> yeah, the version number on the top left corner of http://localhost:7657/index.jsp should be a giveaway :)</p>
|
|
<p>15:58 < jrandom> Complication: no, it doesn't guarantee sequential clock ticks</p>
|
|
<p>15:59 < jrandom> s/sequential/ordered/</p>
|
|
<p>15:59 <+Complication> Nor develop knowledge like "our system clock is 0.00345 times faster than needed"?</p>
|
|
<p>16:00 < jrandom> ah, no, though adding that to net.i2p.util.Clock wouldn't be that hard (wanna miniproject? :)</p>
|
|
<p>16:00 <+Complication> I was thinking of something along those lines</p>
|
|
<p>16:01 <+Complication> I guess I'm now thinking a bit more about it :)</p>
|
|
<p>16:01 <+Complication> Other miniprojects first, though :)</p>
|
|
<p>16:02 < jrandom> ok, anyone have anything else for the meeting?</p>
|
|
<p>16:03 < nymisis> Muffins?</p>
|
|
<p>16:04 < jrandom> no, pancakes</p>
|
|
<p>16:04 < jrandom> (mmMMmm pancakes)</p>
|
|
<p>16:04 < jrandom> speaking of which</p>
|
|
<p>16:04 * jrandom winds up</p>
|
|
<p>16:04 < nymisis> Oh, darn, good point.</p>
|
|
<p>16:04 * jrandom *baf*s the meeting closed</p>
|
|
</div>
|
|
{% endblock %} |