228 lines
19 KiB
HTML
228 lines
19 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}I2P Development Meeting 158{% endblock %}
|
|
{% block content %}<h3>I2P dev meeting, November 29, 2005</h3>
|
|
<div class="irclog">
|
|
<p>15:25 < jrandom> 0) hi</p>
|
|
<p>15:25 < jrandom> 1) Net status and 0.6.1.6</p>
|
|
<p>15:25 < jrandom> 2) Syndie</p>
|
|
<p>15:25 < jrandom> 3) I2P Rufus 0.0.4</p>
|
|
<p>15:25 < jrandom> 4) ???</p>
|
|
<p>15:25 < jrandom> 0) hi</p>
|
|
<p>15:25 * jrandom waves</p>
|
|
<p>15:25 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html</p>
|
|
<p>15:26 * bar hands jrandom a baf</p>
|
|
<p>15:26 < c3rvantes> not yet!</p>
|
|
<p>15:26 * jrandom winds up</p>
|
|
<p>15:26 < jrandom> er...</p>
|
|
<p>15:26 < jrandom> lets hit the first few agenda items first :) 1) Net status and 0.6.1.6</p>
|
|
<p>15:27 < jrandom> lots of things have been updated in the last few releases, but the network still seems reasonably stable. </p>
|
|
<p>15:28 < jrandom> we've had some serious spikes in router participation on a few routers, though thats pretty harmless</p>
|
|
<p>15:28 <+legion> cool, I agree net status is getting better. Also yeah why not drop tcp for 0.6.1.7</p>
|
|
<p>15:28 < jrandom> (er, spikes in tunnel participation, that is)</p>
|
|
<p>15:29 <@cervantes> you're not kidding</p>
|
|
<p>15:29 < jrandom> not sure legion. there may be some users out there limited to tcp only, but i seem to recall that there was only one or maybe two of those</p>
|
|
<p>15:29 <+legion> well I've noticed with 0.6.1.5 the router would sometimes restart on its own.</p>
|
|
<p>15:29 <+Complication> Mine's been swinging withint reasonable limits, 100 to 250 participating tunnels</p>
|
|
<p>15:29 < jrandom> I can't think of any great reason to keep it, and I can think of a few to drop it</p>
|
|
<p>15:30 < jrandom> cool Complication</p>
|
|
<p>15:30 < jrandom> (those numbers are fairly average, according to stats.i2p/, but remember, numbers like that can damage anonymity, so shouldn't really be given out, especially not in logged meetings ;)</p>
|
|
<p>15:30 <+Complication> My old Celeron is still auto-restarting every 10 hours or so</p>
|
|
<p>15:30 <+Complication> Otherwise it's better connected than ever before</p>
|
|
<p>15:30 < Pseudonym> what are the reasons to drop it?</p>
|
|
<p>15:31 <+Complication> TCP is expensive</p>
|
|
<p>15:31 <@cervantes> my router is shagged out</p>
|
|
<p>15:31 <+Complication> In terms of threads per connections</p>
|
|
<p>15:31 <@cervantes> Complication: multiply that by 10 and you get my router's current range ;-)</p>
|
|
<p>15:31 <+legion> Mines been swinging within 200-400 participating tunnels, so it seems better than ever.</p>
|
|
<p>15:32 <+Complication> cervantes: ouchie ouchie</p>
|
|
<p>15:32 <+Complication> I've seen a freak accident which caused 2000 participating tunnels, but that was in Summer</p>
|
|
<p>15:32 < jrandom> Pseudonym: performance (cpu/memory, better scheduling due to our semireliable requirements), maintainability, more effective shitlisting</p>
|
|
<p>15:32 <+Complication> A single spike which never repeated again</p>
|
|
<p>15:32 <+legion> yeah, with some past versions there were such spikes</p>
|
|
<p>15:32 < jrandom> Complication: we've had > 2000 tunnel spikes with this last rev</p>
|
|
<p>15:33 < jrandom> but hopefully 0.6.1.7 will take care of that</p>
|
|
<p>15:33 <+legion> Well those are some good reasons to drop tcp :)</p>
|
|
<p>15:33 < jrandom> but, again, the spikes in tunnel participation is fine, as most of them aren't used</p>
|
|
<p>15:34 <@cervantes> Pseudonym: there only seems to be one or two routers still using tcp on the network</p>
|
|
<p>15:34 < jrandom> it may also be a good idea to drop tcp in this rev too, since it doesn't have other major changes. that way we can see how it affects things pretty clearly</p>
|
|
<p>15:34 < jrandom> (and can reenable it if necessary)</p>
|
|
<p>15:35 < Pseudonym> if there are only two routers using it, I can't imagine it would have much effect either way</p>
|
|
<p>15:35 < Pseudonym> (except for there being two less routers on the network)</p>
|
|
<p>15:35 <@cervantes> 2 disgruntled customers</p>
|
|
<p>15:35 < jrandom> well, the transport does show up in some odd situations, which is one of the reasons i want to disable it :)</p>
|
|
<p>15:35 <+Complication> I hope they won't take it very personally</p>
|
|
<p>15:36 <+Complication> It's really nasty of certain ISP's to filter UDP.</p>
|
|
<p>15:36 <+Complication> Nasty, and completely senseless.</p>
|
|
<p>15:36 < jrandom> (e.g. when a router is hosed, people mark their SSU transport as failing, and as such, they fall back on the tcp transport)</p>
|
|
<p>15:36 * Pseudonym loves his ISP. no restrictions</p>
|
|
<p>15:37 <+Complication> So without TCP, one would see how UDP handles it alone?</p>
|
|
<p>15:37 <+Complication> "with no auxiliary wheels" :P</p>
|
|
<p>15:37 <+legion> huh so how do we get around such nasty filtering without tcp?</p>
|
|
<p>15:38 < jrandom> exactly Complication :)</p>
|
|
<p>15:38 < jrandom> legion: we don't</p>
|
|
<p>15:38 < jrandom> (restricted routes)</p>
|
|
<p>15:38 <+Complication> Well, aren't there a number of useful apps besides file-sharing programs, which also use UDP packets sized above DNS packets?</p>
|
|
<p>15:39 <+legion> :( doesn't sound good</p>
|
|
<p>15:39 <+Complication> Sized similarly to the smallest packet size I2P uses?</p>
|
|
<p>15:39 < jrandom> eh legion, its not a problem</p>
|
|
<p>15:39 < jrandom> Complication: streaming protocols</p>
|
|
<p>15:39 <+Complication> One cannot block UDP directly, ever, without crippling DNS.</p>
|
|
<p>15:39 <+Complication> One can limit the packet size.</p>
|
|
<p>15:40 <+legion> ok, it did sound like it could be</p>
|
|
<p>15:40 <+Complication> VoIP?</p>
|
|
<p>15:40 < jrandom> it'd be a problem if it were widespread - if the internet community in general banned udp</p>
|
|
<p>15:40 <+Complication> Hmm, does VoIP use big or small packets?</p>
|
|
<p>15:40 < jrandom> but if its just a few isps, we can treat them like restricted routes</p>
|
|
<p>15:40 <+Complication> Or did you mean more like... video spreaming?</p>
|
|
<p>15:40 <+legion> I'd think it'd use a mix of both</p>
|
|
<p>15:41 < jrandom> both Complication, RTSP runs over UDP, and real runs over RTSP iirc</p>
|
|
<p>15:41 <+Complication> s/p/s</p>
|
|
<p>15:42 <+legion> So on to the next item?</p>
|
|
<p>15:42 <+Complication> cat /etc/services | grep -c udp</p>
|
|
<p>15:42 <+Complication> 227</p>
|
|
<p>15:43 < jrandom> I'm still not sure if we'll drop tcp in 0.6.1.7, but probably. </p>
|
|
<p>15:43 < jrandom> aye, anyone have anything else on 1)? if not, lets jump on to 2) Syndie</p>
|
|
<p>15:43 <+Complication> Meaning, there are at least 227 apps (some possibly obsolete or LAN apps) which use UDP</p>
|
|
<p>15:44 < jrandom> bah, this is the intarweb. all you need is proxied HTTP access</p>
|
|
<p>15:44 < jrandom> I don't have much to add to 2) beyond whats in the mail (and whats on Syndie)</p>
|
|
<p>15:44 <+legion> I'm convinced, yeah drop it. :)</p>
|
|
<p>15:44 < jrandom> anyone have anything re: syndie they want to bring up?</p>
|
|
<p>15:45 <+legion> I've nothing to say about 2) either.</p>
|
|
<p>15:45 * Complication is reading "how Syndie works"</p>
|
|
<p>15:46 <+Complication> One little UI effect, keeps surprising me. :D</p>
|
|
<p>15:46 <+Complication> When I expand a thread of messages, it always gets me by surprise that the active message moves to become the topmost in the list. :P</p>
|
|
<p>15:47 <+Complication> But you can proabably safely ignore that. I'm just very picky, and a creature of habit. :P</p>
|
|
<p>15:47 <@cervantes> the threading model is something that's being discussed at length</p>
|
|
<p>15:47 <@cervantes> ;-)</p>
|
|
<p>15:47 <+Complication> I'll get used to it. :)</p>
|
|
<p>15:48 <+Complication> cervantes: in Syndie? I gotta find that thread. :)</p>
|
|
<p>15:48 <@cervantes> I don't like that either - but it could well change</p>
|
|
<p>15:48 < jrandom> yeah, thats kind of kooky I suppose</p>
|
|
<p>15:48 <+legion> yeah</p>
|
|
<p>15:48 <@cervantes> "subject: syndie threading"</p>
|
|
<p>15:49 <+Complication> Besides, if the expanded message were the bottom-most, it *would* have to move anyway.</p>
|
|
<p>15:49 <+Complication> 'Cause otherwise it'd be stuck there.</p>
|
|
<p>15:50 < jrandom> well, the nav at the bottom shows 10 *threads* at a time, not 10 messages. so it could expand the bottom thread</p>
|
|
<p>15:50 * cervantes is testing some different threading UI style implementations atm</p>
|
|
<p>15:51 < jrandom> wikked</p>
|
|
<p>15:51 < jrandom> yeah, ideally we'll be able to switch them around in css, or if not, on the server side</p>
|
|
<p>15:52 <@cervantes> or rather "threading navigation styles"</p>
|
|
<p>15:53 <@cervantes> hmm my tests use pure html nested unnordered lists by default</p>
|
|
<p>15:53 <@cervantes> you can layer on as much css and javascript as your need or want</p>
|
|
<p>15:53 < jrandom> any eta on when we can see some mockups?</p>
|
|
<p>15:53 <@cervantes> (however it's only a proof of concept, not an actual ui implementation)</p>
|
|
<p>15:54 <@cervantes> I do most of my coding during I2P meetings ;-)</p>
|
|
<p>15:54 < jrandom> heh</p>
|
|
<p>15:54 <@cervantes> perhaps the first mockup will be ready this evening</p>
|
|
<p>15:54 * jrandom schedules daily meetings</p>
|
|
<p>15:54 < jrandom> wikked</p>
|
|
<p>15:54 <@cervantes> curses :)</p>
|
|
<p>15:55 < jrandom> ok, anyone have anything else for 2) syndie?</p>
|
|
<p>15:55 < jrandom> if not, lets move on to 3) I2P Rufus 0.0.4</p>
|
|
<p>15:56 < jrandom> I don't have much to add beyond whats in the mail - Rawn/defnax, y'all around?</p>
|
|
<p>15:56 <+legion> so how good is 0.0.4? What problems remain if any?</p>
|
|
<p>15:57 * jrandom hasn't a clue</p>
|
|
<p>15:58 <+legion> Maybe one of its users can answer. Does it seem good and stable?</p>
|
|
<p>15:58 < jrandom> ok, seems Rawn and defnax are away atm. if anyone has any questions/comments/concerns regarding I2P Rufus, swing on by the forum and post 'em away</p>
|
|
<p>15:58 <+legion> darn, guess we'll have to.</p>
|
|
<p>15:59 <+legion> on to 4)?</p>
|
|
<p>15:59 < jrandom> aye, so it seems. ok, 4) ??? </p>
|
|
<p>15:59 <+Complication> I haven't tried I2P Rufus, unfortunately.</p>
|
|
<p>16:00 < jrandom> anyone have anything else they want to bring up?</p>
|
|
<p>16:00 < jrandom> (c'mon, we've got to drag this out so cervantes can do some more work!)</p>
|
|
<p>16:00 <+legion> yeah, what sort of interesting stuff is coming down the pipe?</p>
|
|
<p>16:00 <+bar> is there anywhere i could read more about "restricted routes"?</p>
|
|
<p>16:00 <+bar> (i *have* searched)</p>
|
|
<p>16:01 <+legion> Maybe we could even discuss i2phex?</p>
|
|
<p>16:01 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD</p>
|
|
<p>16:01 * cervantes poises his mouse over the close button</p>
|
|
<p>16:01 < jrandom> er, #future.restricted</p>
|
|
<p>16:02 < jrandom> plus the how_* pages & todo</p>
|
|
<p>16:02 < jrandom> (on the web)</p>
|
|
<p>16:02 <+Complication> Heh, I2P seems to have skipped a build :D</p>
|
|
<p>16:02 <+Complication> :D</p>
|
|
<p>16:02 <+bar> thanks</p>
|
|
<p>16:02 <+Complication> - public final static long BUILD = 1;</p>
|
|
<p>16:02 <+Complication> + public final static long BUILD = 3;</p>
|
|
<p>16:03 < jrandom> legion: some hacking on the netDb, performance mods, restricted routes, streaming improvements, eepproxy improvements, tunnel improvements, etc. lots of stuff, but nothing ready yet</p>
|
|
<p>16:03 <+legion> huh, odd</p>
|
|
<p>16:03 < jrandom> anything to bring up re: i2phex legion?</p>
|
|
<p>16:03 < jrandom> Complication: yeah, intended. I forgot to increase it for BUILD = 2</p>
|
|
<p>16:03 <+Complication> (not that it matters for anything, just wondering if I've seen this rare occasion before :)</p>
|
|
<p>16:04 <+legion> sweet, sounds great, thanks!</p>
|
|
<p>16:04 < jrandom> oh, that reminds me... it'd be cool if someone wanted to dig into looking at revamping our webpage</p>
|
|
<p>16:05 * jrandom doesnt want to think about it, but its got to be done sooner or later</p>
|
|
<p>16:05 <+legion> yeah, there is</p>
|
|
<p>16:05 <+legion> would it be worthwhile to update i2phex at this point to the latest phex cvs code?</p>
|
|
<p>16:06 <+Complication> Not sure, I haven't heard from Redzara recently</p>
|
|
<p>16:06 < jrandom> last I recall, redzara was waiting on gregorz's updates to phex</p>
|
|
<p>16:06 < jrandom> (so we could have a fairly clean update/extension)</p>
|
|
<p>16:08 <+legion> huh, then why have i2phex?</p>
|
|
<p>16:08 <+Complication> Just in case?</p>
|
|
<p>16:08 < jrandom> hmm?</p>
|
|
<p>16:08 < jrandom> i2phex is an extension to phex</p>
|
|
<p>16:08 <+legion> Seems like they wanted there to just be phex with a i2p extension</p>
|
|
<p>16:09 < jrandom> extension, as in, modification to a very small number of bits</p>
|
|
<p>16:09 < jrandom> er, s/bits/components/. so we can easily update the code whenever the phex devs fix things</p>
|
|
<p>16:10 <+legion> if so then it shouldn't take much work for me to update it to the latest cvs code, though I know it will.</p>
|
|
<p>16:10 < jrandom> last I heard in the forum was that the plan is to have I2Phex and Phex be separate applications, but they'd share a majority of code</p>
|
|
<p>16:10 < jrandom> aye legion, that'd be great, but last I heard, Gregor hadn't finished the modifications to Phex yet</p>
|
|
<p>16:11 < jrandom> (which is what redzara was waiting on)</p>
|
|
<p>16:11 <+legion> ah I see</p>
|
|
<p>16:11 < jrandom> so, the alternative is to either help Gregor out or continue modifying the existing I2Phex codebase</p>
|
|
<p>16:12 <+legion> well then if I don't wait and just update i2phex with new code, there would be no need for redzara continue</p>
|
|
<p>16:12 < jrandom> well, not really. </p>
|
|
<p>16:12 < jrandom> updating I2Phex to the current Phex code would be great, yes</p>
|
|
<p>16:13 < jrandom> but as soon as the Phex developers update their Phex code, we're out of sync again</p>
|
|
<p>16:13 <+legion> ok, I'll probably get to it sometime tonight or within a couple days.</p>
|
|
<p>16:13 < jrandom> wikked</p>
|
|
<p>16:13 <+legion> That is fine.</p>
|
|
<p>16:14 <+legion> Really I'm not looking to have i2phex remain in sync with phex code, it's just that it sounds like the cvs contains fixes which i2phex could certainly use.</p>
|
|
<p>16:15 <+legion> Also I'm really looking to drop out any phex code and features which i2phex doesn't need.</p>
|
|
<p>16:15 < jrandom> cool</p>
|
|
<p>16:16 <+legion> As to any new features and fixing anything that is still not working like the upload queues... Well I've already looked into getting the webcaches working, but have much more to do.</p>
|
|
<p>16:17 < jrandom> word. yeah, phex used to have working gwebcache support, but sirup disabled it, as it wasn't necessary at first</p>
|
|
<p>16:17 <+legion> I do plan on adding jeti to i2phex eventually.</p>
|
|
<p>16:17 < jrandom> neat</p>
|
|
<p>16:18 * jrandom has never used jeti, and I hope it stays an optional component, but supporting more things is cool</p>
|
|
<p>16:18 <+legion> Yeah it can be optionally, users will be able to download a jeti2phex ;)</p>
|
|
<p>16:19 < jrandom> word</p>
|
|
<p>16:19 <+legion> There still is much we can do with i2phex, though it is working great as it is.</p>
|
|
<p>16:20 <+legion> So far keeping a client connected, up and running for 24/7 is possible and easy.</p>
|
|
<p>16:21 < jrandom> yeah, I've had some good success with it... "backing up my licensed recordings"</p>
|
|
<p>16:21 <+legion> heh :)</p>
|
|
<p>16:22 < jrandom> ok, anyone else have anything for the meeting?</p>
|
|
<p>16:23 * cervantes wheels in the chinese gong</p>
|
|
<p>16:23 <+legion> Seems like I'm forgetting something... hmm</p>
|
|
<p>16:24 <+legion> Oh yeah, any ideas on how we can reduce the amount of memory i2p and i2phex consumes?</p>
|
|
<p>16:25 <+Complication> Well, the TCP transport takes a bit</p>
|
|
<p>16:25 < jrandom> one could run both in the same jvm</p>
|
|
<p>16:25 <+Complication> If that is going, it will free a bit</p>
|
|
<p>16:26 <@cervantes> take some ramsticks out of your machine</p>
|
|
<p>16:26 < cat-a-puss> anyone with any experence with javolution know if it would help? http://javolution.org/</p>
|
|
<p>16:26 < jrandom> (clients.config in the i2p install dir defines the main class and arguments to launch clients)</p>
|
|
<p>16:26 <+legion> So if we ran both in the same jvm and when tcp goes, could we bring it down to under 50mb?</p>
|
|
<p>16:27 < jrandom> no idea legion. depends on what you mean by 50MB as well. RSS/VSS/etc</p>
|
|
<p>16:27 < jrandom> I really wouldn't recommend running both in one JVM though, unless you keep both running all the time, since shutting down one would kill the other</p>
|
|
<p>16:27 <@cervantes> legion: limiting bandwith and capping participants might also help</p>
|
|
<p>16:27 < jrandom> aye, what cervantes said</p>
|
|
<p>16:28 < cat-a-puss> it would seem to me that if we know exactly how many of some type of object we are eventually likely to use, it would help prevent overzellous jvm allocation</p>
|
|
<p>16:28 <+Complication> Right, it makes those different allocations, which I've never really managed to make sense of</p>
|
|
<p>16:28 < jrandom> aye, we do some of that cat-a-puss (see net.i2p.util.ByteCache)</p>
|
|
<p>16:29 <+Complication> (but as said, Java is a very new thing to me)</p>
|
|
<p>16:29 < jrandom> I've glanced at javolution before, but it seems to have made a lot of progress. i'll give 'er another look</p>
|
|
<p>16:30 < cat-a-puss> jrandom:I know some people at my work use it and are happy with it, though they don't care about memory allocation</p>
|
|
<p>16:31 < jrandom> well, it really wouldn't save any memory, but would help cut down on GC churn</p>
|
|
<p>16:31 <+legion> Well I personally don't care much about memory allocation, however many people do.</p>
|
|
<p>16:31 < jrandom> ooh, and its BSD licensed too</p>
|
|
<p>16:31 < cat-a-puss> right</p>
|
|
<p>16:31 < jrandom> legion: memory allocation means performance</p>
|
|
<p>16:32 <+legion> er, oh, memory consumption then</p>
|
|
<p>16:33 <+legion> Many people are so very happy with utorrent because of it's very small memory footprint.</p>
|
|
<p>16:33 < jrandom> ah, oh, yeah. we can tweak it down the line, but since i2p runs within the default jvm sizes, i'm not too worried (as we've got lots of room for tweaking)</p>
|
|
<p>16:34 < jrandom> ok, anyone have anything else for the meeting?</p>
|
|
<p>16:35 <+legion> nah I'm good...</p>
|
|
<p>16:37 * jrandom winds up</p>
|
|
<p>16:37 * jrandom *baf*s the meeting closed</p>
|
|
</div>
|
|
{% endblock %} |