129 lines
5.8 KiB
HTML
129 lines
5.8 KiB
HTML
<pre>-----BEGIN PGP SIGNED MESSAGE-----
|
|
Hash: SHA1
|
|
|
|
Hi y'all, seems that tuesday has rolled around again
|
|
|
|
* Index
|
|
1) Net status
|
|
2) Throughput profiling
|
|
3) Syndie blogs
|
|
4) HTTP persistent connections
|
|
5) I2Phex gwebcache
|
|
6) ???
|
|
|
|
* 1) Net status
|
|
|
|
The past week has seen a lot of bugfixes and enhnacements going on
|
|
in CVS, with the current build sitting at 0.6.1.8-11. The network
|
|
has been reasonably stable, though some outages at different i2p
|
|
service providers led to the occational hiccough. We've finally
|
|
gotten rid of the unnecessarily high router identity churn in CVS,
|
|
and there's a new bugfix to the core that zzz came up with yesterday
|
|
that sounds quite promising, but we'll have to wait and see how it
|
|
impacts things. Two other big things going on in the past week have
|
|
been the new throughput based speed profiling, and some major work
|
|
on Syndie's blog view. As for when we'll see 0.6.1.9, it should be
|
|
out later this week, the weekend at the latest. Keep your ears to
|
|
the usual places.
|
|
|
|
* 2) Throughput profiling
|
|
|
|
We've tested a few new peer profiling algorithms for monitoring
|
|
throughput, but over the last week or so we seem to have settled on
|
|
one that looks quite good. Essentially, it monitors the confirmed
|
|
throughput of individual tunnels over 1 minute periods, adjusting
|
|
the throughput estimates for the peers accordingly. It doesn't try
|
|
to work out an average rate for a peer, since doing so is very
|
|
complicated, due to the fact that tunnels include multiple peers, as
|
|
well as the fact that confirmed throughput measurements often
|
|
require multiple tunnels. Instead, it works out an average peak
|
|
rate - specifically, it measures the three fastest rates that the
|
|
peer's tunnel's were able to transfer at and averages those.
|
|
|
|
The gist of it is that these rates, being measured over a full
|
|
minute, are sustained speeds that the peer is capable of pushing,
|
|
and since every peer is at least as fast as the end to end
|
|
measured rate, its safe to mark each of them as being that fast. We
|
|
had tried another twist on this - measuring overall throughput of a
|
|
peer through tunnels in different periods, and that offered even
|
|
clearer peak rate information, but heavily weighed against those
|
|
peers who weren't already marked as "fast", since "fast" ones are
|
|
used much more frequently (client tunnels only use fast peers). The
|
|
result of that overall throughput measurement was that it gathered
|
|
great data for those adequately stressed, but only the fast peers
|
|
were adequately stressed and there was little effective exploration.
|
|
|
|
Using 1 minute periods and the throughput of an individual tunnel,
|
|
however, seems to yeild more reasonable values. We'll be seeing
|
|
this algorithm deployed in the next release.
|
|
|
|
* 3) Syndie blogs
|
|
|
|
Based on some feedback, further improvements have gone on within the
|
|
blog view to syndie, giving it a distinctly different flavor than
|
|
the newsgroup/forum-like threaded view. In addition, its got a
|
|
whole new capability for defining general blog information through
|
|
the existing Syndie architecture. For an example, check out the
|
|
default "about Syndie" blog post:
|
|
<a rel="nofollow" href="http://syndiemedia.i2p.net/blog.jsp">http://syndiemedia.i2p.net/blog.jsp</a>?
|
|
blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&
|
|
entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800001
|
|
|
|
This only touches on the beginnings of what we can do. The next
|
|
release will let you define your own blog's logo, your own links
|
|
(to blogs, posts, attachments, an arbitrary external URLs), and
|
|
hopefully even more customization. One such customization is
|
|
per-tag icons - I'd like to ship a set of default icons to use
|
|
with standard tags, but people will be able to define icons for
|
|
their own tags for use within their blog, and even override the
|
|
default icons for the standard tags (again, only when people are
|
|
viewing their blog, of course). Perhaps even some style
|
|
configuration to display posts with different tags differently (of
|
|
course, only very specific style customization would be allowed - no
|
|
arbitrary CSS exploits with Syndie, thankyouverymuch :)
|
|
|
|
There's still a lot more I'd like to do with the blog view that
|
|
won't be in the next release, but it should be a good kick to get
|
|
people playing with some of its capabilities, which will hopefully
|
|
let y'all show me what *you* need, rather than what I think you
|
|
want. I may be a good coder, but I'm a bad psychic.
|
|
|
|
* 4) HTTP persistent connections
|
|
|
|
zzz is a maniac, I'm telling you. There's been some progress on a
|
|
long requested feature - support for persistent HTTP connections,
|
|
allowing you to send multiple HTTP requests over a single stream,
|
|
receiving multiple replies in return. I think someone first asked
|
|
for this two years ago or so, and it could help with some types of
|
|
eepsite(I2P Site) or outproxying a bunch. I know the work isn't done yet, but
|
|
its coming along. Hopefully zzz can give us a status update during
|
|
the meeting.
|
|
|
|
* 5) I2Phex gwebcache
|
|
|
|
I have heard reports of progress on getting gwebcache support back
|
|
into I2Phex, but I don't know how it stands at the moment. Perhaps
|
|
Complication can give us an update on that tonight?
|
|
|
|
* 6) ???
|
|
|
|
There's lots going on, as you can see, but if there are other things
|
|
y'all'd like to bring up and discuss, swing on by the meeting in a
|
|
few minutes and give a shout. As an aside, one neat site I've been
|
|
watching lately has been <a rel="nofollow" href="http://freedomarchive.i2p/">http://freedomarchive.i2p/</a> (for you lazy
|
|
folks without I2P installed, you can use Tino's inproxy via
|
|
<a rel="nofollow" href="http://freedomarchive.i2p.tin0.de/">http://freedomarchive.i2p.tin0.de/</a>). In any case, see y'all in a
|
|
few minutes.
|
|
|
|
=jr
|
|
-----BEGIN PGP SIGNATURE-----
|
|
Version: GnuPG v1.4.1 (GNU/Linux)
|
|
|
|
iD8DBQFDxBHHWYfZ3rPnHH0RAo6SAJ0UpdXqV0a/X6MDNtiMXesk2OCQ6gCfUY9d
|
|
O4wXeggK4HJFFY3qioGTjlU=
|
|
=EWqU
|
|
-----END PGP SIGNATURE-----
|
|
|
|
|
|
</pre>
|