130 lines
5.4 KiB
HTML
130 lines
5.4 KiB
HTML
<pre>-----BEGIN PGP SIGNED MESSAGE-----
|
|
Hash: SHA1
|
|
|
|
Hi all, sorry for being late...
|
|
|
|
* Index:
|
|
|
|
1) 0.4
|
|
2) Capacity and overload
|
|
3) Website updates
|
|
4) I2PTunnel web interface
|
|
5) Roadmap and todo
|
|
6) ???
|
|
|
|
* 1) 0.4
|
|
|
|
As I'm sure you've all seen, the 0.4 release came out the other day
|
|
and overall, its going pretty well. Its hard to believe it was 6
|
|
months since 0.3 came out (and a year since the 1.0 SDK was
|
|
released), but we've come a long way, and y'all's hard work,
|
|
enthusiasm, and patience has done wonders. Congrats, and thanks!
|
|
|
|
Like any good release, as soon as it hit the door we found some
|
|
problems, and over the last few days we've been accumulating bug
|
|
reports and patching like mad (you can watch [1] the changes as
|
|
they're fixed). We do still have a few more bugs left to squash
|
|
prior to pushing out the next rev, but that should be done in
|
|
the next day or so.
|
|
|
|
[1] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</a>
|
|
|
|
* 2) Capacity and overload
|
|
|
|
We've seen some fairly skewed allocations of tunnels for the last few
|
|
releases, and while some of those are bug related (two of those fixed
|
|
since 0.4 came out), there is still a general algorithm question out
|
|
there - when should a router stop accepting more tunnels?
|
|
|
|
A few revs back, we added throttling code to reject requests to
|
|
participate in a tunnel if the router was overloaded (the local
|
|
message processing time exceeds 1s), and that has helped
|
|
substantially. However, there are two aspects to that simple
|
|
algorithm that aren't addressed:
|
|
= when our bandwidth is saturated, our local processing time may
|
|
still be fast, so we'd continue to accept more tunnel requests
|
|
= when a single peer participates in "too many" tunnels, when they
|
|
fail, it hurts the network more.
|
|
|
|
The first issue is dealt with fairly easily by simply enabling the
|
|
bandwidth limiter (since bandwidth limiting slows down the message
|
|
processing time in accordance to the bandwidth delay). The second
|
|
is more complicated, and both more research and more simulation is
|
|
necessary. I'm thinking something along the lines of
|
|
probabalistically rejecting tunnel requests based on the ratio of
|
|
tunnels participating in and tunnels requested from the network,
|
|
including some base "kindness factor", setting P(reject) = 0 if
|
|
we're participating in less than that.
|
|
|
|
But as I said, more work and simulation is necessary.
|
|
|
|
* 3) Website updates
|
|
|
|
Now that we've got the new I2P web interface, pretty much all of our
|
|
old end user documentation is obsolete. We need some help going
|
|
through those pages and updating them to describe how things are
|
|
now. As duck and others have suggested, we need a new 'kickstart'
|
|
guide above and beyond the <a rel="nofollow" href="http://localhost:7657/">http://localhost:7657/</a> readme -
|
|
something to get people up and into the system.
|
|
|
|
In addition, our new web interface has plenty of room for integrating
|
|
context sensitive help. As you can see on the bundled help.jsp,
|
|
"hmm. we should probably have some help text here."
|
|
|
|
It'd probably be great if we could add 'about' and/or
|
|
'troubleshooting' links to the different pages, explaining what
|
|
things mean and how to use them.
|
|
|
|
* 4) I2PTunnel web interface
|
|
|
|
To call the new <a rel="nofollow" href="http://localhost:7657/i2ptunnel/">http://localhost:7657/i2ptunnel/</a> interface "spartan"
|
|
would be an understatement. We need to do a lot of work to get that
|
|
closer to a usable state - right now the functionality is technically
|
|
there, but you really need to know whats going on behind the scenes
|
|
to make sense of it. I think duck may have some further ideas about
|
|
this to bring up during the meeting.
|
|
|
|
* 5) Roadmap and todo
|
|
|
|
I've been slacking on keeping the roadmap [2] up to date, but the
|
|
fact of the matter is, we've got some further revision ahead of us.
|
|
To help explain what I see as the "big problems", I've put together
|
|
a new task list [3], which goes into some detail on each. I think
|
|
we should be fairly open at this point at reviewing our options and
|
|
perhaps reworking the roadmap.
|
|
|
|
One thing I've forgotten to mention on that todo list is that when
|
|
adding the lightweight connection protocol [4], we can include
|
|
(optional) autodetection of the IP address. This may be 'dangerous'
|
|
(which is why it'll be optional), but it will dramatically reduce the
|
|
number of support requests we get :)
|
|
|
|
Anyway, those issues posted on the todo list are ones we've had
|
|
slated for various releases, and most certainly will not all be in
|
|
1.0 or even 2.0. I've sketched out a few different possible
|
|
prioritization / releases, but I'm not hard set on those yet.
|
|
However, if people can identify other big things down the path, it'd
|
|
be much appreciated, as an unscheduled issue is always a pain in the
|
|
butt.
|
|
|
|
[2] <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a>
|
|
[3] <a rel="nofollow" href="http://www.i2p.net/todo">http://www.i2p.net/todo</a>
|
|
[4] <a rel="nofollow" href="http://www.i2p.net/todo#connection">http://www.i2p.net/todo#connection</a>
|
|
|
|
* 6) ???
|
|
|
|
Ok, thats all I've got for now (good thing too, since the meeting
|
|
starts in a few minutes). Swing on by #i2p on irc.freenode.net,
|
|
www.invisiblechat.com, or irc.duck.i2p at 9p GMT to chat further.
|
|
|
|
-----BEGIN PGP SIGNATURE-----
|
|
Version: PGP 8.1
|
|
|
|
iQA/AwUBQT4ijhpxS9rYd+OGEQLGsQCg5nvwnBMw4nQaV6/d9loWZjWZhJkAoNxq
|
|
qS8j385jn3Xj4wIJCPimEX01
|
|
=jVx+
|
|
-----END PGP SIGNATURE-----
|
|
|
|
|
|
</pre>
|