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