{% extends "_layout.html" %} {% block title %}I2P Status Notes for 2006-01-10{% endblock %} {% block content %}

I2P Status Notes for 2006-01-10

-----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:
 http://syndiemedia.i2p.net/blog.jsp?
  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 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 http://freedomarchive.i2p/ (for you lazy
folks without I2P installed, you can use Tino's inproxy via
http://freedomarchive.i2p.tin0.de/).  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-----
{% endblock %}