jrandom | 1 Feb 22:03 2005
Picon

weekly status notes [feb 1]


Hi y'all, weekly status time

* Index
1) 0.5 status
2) nntp
3) tech proposals
4) ???

* 1) 0.5 status

There has been lots of progress on the 0.5 front, with a big batch
of commits yesterday.  The bulk of the router now uses the new
tunnel encryption and tunnel pooling [1], and it has been working
well on the test network.  There are still some key pieces left to
integrate, and the code is obviously not backwards compatible, but
I'm hoping we can do some wider scale deployment sometime next week.

As mentioned before, the initial 0.5 release will provide the
foundation on which different tunnel peer selection/ordering
strategies can operate.  We'll start with a basic set of
configurable parameters for the exploratory and client pools, but
later releases will probably include other options for different
user profiles.

[1]http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD

* 2) nntp

As mentioned on LazyGuy's site [2] and my blog [3], we've got a new
(Continue reading)

Tom Kaitchuck | 5 Feb 22:23 2005
Picon

Characteristics of UDP Packet Loss: Effect of TCP Traffic

I saw this a while back, but now that UDP is up and coming, it might be of 
intrest here.
http://www.isoc.org/isoc/whatis/conferences/inet/97/proceedings/F3/F3_1.HTM
jrandom | 8 Feb 16:01 2005
Picon

Re: Characteristics of UDP Packet Loss: Effect of TCP Traffic


Hi Tom,

(finally getting around to list mail)

Their findings regarding the effects of synchronization are quite
interesting, though their recommendations are a bit odd, downplaying
the effects of small messages on overall throughput.  otoh, their
target audience is the RT camp, so I suppose its reasonable.

We will probably want to take into account these effects, having
the UDP transport scale the packet sizes under various congestion
conditions (in addition to PMTU activity).  We aren't really in the
RT camp though, and for things we want to transfer without loss,
we've got a TCP-compatible congestion control algorithm (in the
streaming lib).

Once we've deployed the 0.5 rev, we're going to want to hammer out
all the nuances for the 0.6 UDP transport, so please, keep an eye
out and share your thoughts :)

=jr
jrandom | 8 Feb 21:57 2005
Picon

weekly status notes [feb 8]


Hi y'all, update time again

* Index
1) 0.4.2.6-*
2) 0.5
3) i2p-bt 0.1.6
4) fortuna
5) ???

* 1) 0.4.2.6-*

It doesn't seem like it, but its been over a month since the 0.4.2.6
release came out and things are still in pretty good shape.  There
have been a series of pretty useful updates [1] since then, but no
real show stopper calling for a new release to get pushed.  However,
in the last day or two we've had some really good bugfixes sent in
(thanks anon and Sugadude!), and if we weren't on the verge of the
0.5 release, I'd probably package 'er up and push 'er out.  anon's
update fixes a border condition in the streaming lib which has been
causing many of the timeouts seen in BT and other large transfers,
so if you're feeling adventurous, grab CVS HEAD and try 'er out.  Or
wait around for the next release, of course.

[1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD

* 2) 0.5

Lots and lots of progress on the 0.5 front (as anyone on the i2p-cvs
list [2] can attest to).  All of the tunnel updates and various
(Continue reading)

Matthew P. Cashdollar | 8 Feb 23:39 2005

Re: weekly status notes [feb 8]

jrandom wrote:
> * 4) fortuna
> 
> As mentioned in last week's meeting, smeghead has been churning away
> at a whole slew of different updates lately, and while battling to
> get I2P working with gcj, some really horrendous PRNG issues have
> cropped up in some JVMs, pretty much forcing the issue of having a
> PRNG we can count on.  Having heard back from the GNU-Crypto folks,
> while their fortuna implementation hasn't really been deployed yet,
> it looks to be the best fit for our needs.  We might be able to get
> it into the 0.5 release, but chances are it'll get deferred to 0.5.1
> though, as we'll want to tweak it so that it can provide us with the
> necessary quantity of random data.

What are other projects using for PRNG?  What is Freenet using?  I'd 
guess they have similar requirements.  Why do we need so much PRNG data now?

-Matt
Tom Kaitchuck | 9 Feb 00:36 2005
Picon

Re: weekly status notes [feb 8]

On Tuesday 08 February 2005 02:57 pm, jrandom wrote:
> Hi y'all, update time again
>
> * Index
> 1) 0.4.2.6-*
> 2) 0.5
> 3) i2p-bt 0.1.6
> 4) fortuna
> 5) ???
>
> * 1) 0.4.2.6-*
>
> It doesn't seem like it, but its been over a month since the 0.4.2.6
> release came out and things are still in pretty good shape.  There
> have been a series of pretty useful updates [1] since then, but no
> real show stopper calling for a new release to get pushed.  However,
> in the last day or two we've had some really good bugfixes sent in
> (thanks anon and Sugadude!), and if we weren't on the verge of the
> 0.5 release, I'd probably package 'er up and push 'er out.  anon's
> update fixes a border condition in the streaming lib which has been
> causing many of the timeouts seen in BT and other large transfers,
> so if you're feeling adventurous, grab CVS HEAD and try 'er out.  Or
> wait around for the next release, of course.
>
> [1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD
>
> * 2) 0.5
>
> Lots and lots of progress on the 0.5 front (as anyone on the i2p-cvs
> list [2] can attest to).  All of the tunnel updates and various
(Continue reading)

jrandom | 9 Feb 00:43 2005
Picon

Re: weekly status notes [feb 8]


> What are other projects using for PRNG?  What is Freenet using?  I'd
> guess they have similar requirements.

They have a custom built (GPLed) Yarrow, tied into fred's core.

> Why do we need so much PRNG data now?

Its nothing new - we've always gobbled random #s like mad.  Try
profiling the router or i2ptunnel - you'll see a whole truckload of
CPU time and memory usage from sun's SHA1PRNG.  We've also had
issues before with blackdown's PRNG acting up and hosing the system.
The driving issue here was gcj's PRNG being anything but random.
Rather than go with a PRNG of unknown quality, we need to supply
one of our own.

If there is another solution we can use, I'm all ears

=jr
duck | 9 Feb 21:47 2005
Picon

I2P BT release 0.1.7


What's new?

    * Forgot to import an errno, so the client crashes if the socket blocks.
      Silly but critical.

Get it at http://duck.i2p/i2p-bt/

The sourcecode repository is on cvs.i2p, you can follow the instructions
on http://www.i2p.net/cvs to access it. The module is called i2p-bt.

duck
John Anderson | 12 Feb 18:14 2005

I2P Still Broken Under MacOS

I2P still isn't working under MacOS 10.3 (Panther).  I tried it a couple
of months back and it wasn't working.  I just downloaded the 0.4.2.6
release to see if things may have changed, but still no joy.

Here's some information in case anyone wants to look into it:

- java version is 1.4.2.

- I have 100% verified that port 8887 is reachable from the internet.

- Reseeding doesn't work from the program.  Files are downloaded to the
netDb directory, but subsequently removed (see the second attached log
file at the bottom for likely causes).

I reseeded manually by downloading the router-* files from dev.i2p.net
and putting them into my netDb directory.  Before doing this, I would
get Active: 0/0 connections.  Now I get Active: 0/x, where x is a
continually growing number (presently 32).  Failing is currently 121,
and shitlisted is currently 117.

I turned up the debug level to WARN and captured some of the log file
below from my second run with the netDb directory manually populated:

16:01:50.465 WARN  [BWRefiller1 ] ransport.FIFOBandwidthRefiller:
Refresh delay too fast (0)
16:01:50.904 WARN  [impleAppMain] i2p.crypto.DHSessionKeyBuilder: NO
MORE BUILDERS!  creating one now
16:01:52.137 WARN  [BWRefiller1 ] ransport.FIFOBandwidthRefiller:
Refresh delay too fast (99)
16:01:52.422 WARN  [JobQueue0   ] outer.tunnelmanager.TunnelPool:
(Continue reading)

jrandom | 12 Feb 18:40 2005
Picon

Re: I2P Still Broken Under MacOS


Hi John,

I see two potential issues - crypto taking ab obscene amount of time
(5s to calculate a DH value) and some corruption/loading issues.  The
crypto can be helped out by either building a jbigi instance native
to your platform or grabbing one [1] that Jhor has built [2].

[1] http://dev.i2p.net/~jrandom/libjbigi.jnilib
[2] not yet included with the build as I can't reproduce it, but
    info up  <at>  http://forum.i2p.net/viewtopic.php?t=226

That "Not enough bytes to read the payload" is worrying though,
either suggesting 1) that the file is corrupt or 2) there is a bug
loading on OSX.  Could you try the following:

wget http://dev.i2p.net/i2pdb/routerInfo-YlbtGNB2rprSKZiMQCJdCnQFlTXkA0HhWtDvTFg9HMQ=.dat
echo "logger.record.net.i2p.data.TestData=INFO" >> logger.config
java -cp lib/i2p.jar net.i2p.data.TestData display RouterInfo routerInfo-Yl*

in logs/log-0.txt, it should contain a bunch of data, including the
RouterInfo for YlbtGn... (reachable at dev.i2p.net:4108)

If it doesn't, please send me `uname -a`, the full java
version, and the log output, and i'll dig into it further.

Thanks for your patience.

=jr
(Continue reading)


Gmane