2009-02-10 04:15:20 +00:00
|
|
|
<pre>-----BEGIN PGP SIGNED MESSAGE-----
|
|
|
|
Hash: SHA1
|
|
|
|
|
|
|
|
Hi y'all, time for a status update
|
|
|
|
|
|
|
|
* Index:
|
|
|
|
|
|
|
|
1) Net status
|
|
|
|
2) Streaming lib
|
|
|
|
3) 0.4.2
|
|
|
|
4) Addressbook.py 0.3.1
|
|
|
|
5) ???
|
|
|
|
|
|
|
|
* 1) Net status
|
|
|
|
|
|
|
|
After last week's 2-3 day stint of things being pretty congested, the
|
|
|
|
network has come back on track (likely because we stopped stress
|
|
|
|
testing the bittorrent port ;). The network has been pretty reliable
|
|
|
|
since then - we do have a few routers that have been up and running
|
|
|
|
for 30-40+ days, but IRC connections have still had their occational
|
|
|
|
bumps. On the other hand...
|
|
|
|
|
|
|
|
* 2) Streaming lib
|
|
|
|
|
|
|
|
For the last week or so, we've been doing a lot more live testing of
|
|
|
|
the streaming lib on the network and things have been looking pretty
|
|
|
|
good. Duck set up a tunnel with it that people could use to access
|
|
|
|
his IRC server, and over the course of a few days, I only had two
|
|
|
|
unnecessary disconnects (which helped us track down some bugs).
|
|
|
|
We've also had an i2ptunnel instance pointing at a squid outproxy
|
|
|
|
that people have been trying out, and both the throughput, latency,
|
|
|
|
and reliability are much improved when compared to the old lib, which
|
|
|
|
we did side by side.
|
|
|
|
|
|
|
|
All in all, the streaming lib looks to be in good enough shape for a
|
|
|
|
first release. There are a few things left not yet completed, but
|
|
|
|
its a significant improvement on the old lib, and we've got to give
|
|
|
|
you a reason to upgrade later, right? ;)
|
|
|
|
|
|
|
|
Actually, just to tease you (or perhaps inspire you to come up with
|
|
|
|
some solutions), the main things I see coming down the line for the
|
|
|
|
streaming lib are:
|
|
|
|
= some algorithms to share congestion and RTT information across
|
|
|
|
streams (per target destination? per source destination? for
|
|
|
|
all of the local destinations?)
|
|
|
|
= further optimizations for interactive streams (most of the focus
|
|
|
|
in the current implementation is on bulk streams)
|
|
|
|
= more explicit use of the new streaming lib's features in
|
|
|
|
I2PTunnel, reducing the per-tunnel overhead.
|
|
|
|
= client level bandwidth limiting (in either or both directions
|
|
|
|
on a stream, or possibly shared across multiple streams). This
|
|
|
|
would be in addition to the router's overall bandwidth limiting,
|
|
|
|
of course.
|
|
|
|
= various controls for destinations to throttle how many streams
|
|
|
|
they accept or create (we have some basic code, but largely
|
|
|
|
disabled)
|
|
|
|
= access control lists (only allowing streams to or from certain
|
|
|
|
other known destinations)
|
|
|
|
= web controls and monitoring the health of the various streams,
|
|
|
|
as well as the ability to explicitly close or throttle them
|
|
|
|
|
|
|
|
Y'all can probably come up with some other things too, but thats
|
|
|
|
just a brief list of things I'd love to see in the streaming lib,
|
|
|
|
but won't hold up the 0.4.2 release for. If anyone is interested
|
|
|
|
in any of those, please, lemmie know!
|
|
|
|
|
|
|
|
* 3) 0.4.2
|
|
|
|
|
|
|
|
So, if the streaming lib is in good shape, when are we gong to have
|
|
|
|
the release? The current plan is to push it out the door by the
|
|
|
|
end of the week, maybe even as soon as tomorrow. There are a few
|
|
|
|
other things going on that I want to get sorted first, and of
|
|
|
|
course those need to be tested, yadda yadda yadda.
|
|
|
|
|
|
|
|
The big change in the 0.4.2 release will of course be the new
|
|
|
|
streaming lib. From an API perspective, it is identical to the
|
|
|
|
old lib - I2PTunnel and SAM streams automatically use it, but from
|
|
|
|
a packet perspective, it is *not* backwards compatible. This leaves
|
|
|
|
us with an interesting dilemma - there is nothing within I2P
|
|
|
|
requiring us to make 0.4.2 into a manditory upgrade, however people
|
2020-12-05 12:01:37 -05:00
|
|
|
who don't upgrade won't be able to use I2PTunnel - no eepsites(I2P Sites), no
|
2009-02-10 04:15:20 +00:00
|
|
|
IRC, no outproxy, no email. I don't want to alienate our long time
|
|
|
|
users by forcing them to upgrade, but I also don't want to alienate
|
|
|
|
them by having everything useful break ;)
|
|
|
|
|
|
|
|
I'm open to being convinced either way - it would be easy enough to
|
|
|
|
change a single line of code so that the 0.4.2 release won't talk to
|
|
|
|
the older releases, or we could just let it be and have people
|
|
|
|
upgrade whenever they go to the website or forum to bitch about
|
|
|
|
everything being broken. What do y'all think?
|
|
|
|
|
|
|
|
* 4) Addressbook.py 0.3.1
|
|
|
|
|
|
|
|
Ragnarok has come out with a new patch release for his address book
|
|
|
|
app - see <a rel="nofollow" href="http://ragnarok.i2p/">http://ragnarok.i2p/</a> for more info (or perhaps he can give
|
|
|
|
us an update in the meeting?)
|
|
|
|
|
|
|
|
* 5) ???
|
|
|
|
|
|
|
|
I know there's a lot more activity going on - with the bittorrent
|
|
|
|
port, susimail, slacker's new hosting service, among other things.
|
|
|
|
Anyone have anything else to bring up? If so, swing on by the
|
|
|
|
meeting in ~30m in #i2p on the usual IRC servers!
|
|
|
|
|
|
|
|
=jr
|
|
|
|
|
|
|
|
-----BEGIN PGP SIGNATURE-----
|
|
|
|
Version: PGP 8.1
|
|
|
|
|
|
|
|
iQA/AwUBQaOeJxpxS9rYd+OGEQKUCwCg601Jw+mvt+rx0MMMOcNaqlGBExQAoIp7
|
|
|
|
pfi+wfwTumipVNuMFPUm39TK
|
|
|
|
=VwGu
|
|
|
|
-----END PGP SIGNATURE-----
|
|
|
|
|
|
|
|
|
|
|
|
</pre>
|