Re: Compromize on testnetwork, etc

> 1 day a week, or 1 in 6 hours of my time, would be spent on building the
> test network, building simulations, enhancing the test network, anything
> involving checking out how other P2Ps do things that might be relevant,
> or any related literature (and I'm not saying there necessarily is any;
> this is just an example), using the test network(s) or simulations to
> test out routing tweaks and find out what is really going on, and any
> other more theoretical/exploratory activities on the network.
> 
> The rest of the time would be spent as it is now: debugging, more
> debugging, implementing the Next Big Feature, whatever it happens to be,
> assisting users (this can be productive in both finding bugs and user
> loyalty/donations), merging code between branches, and so on.
> 
> 
> I look forward to a good flamewar; the list has been rather quiet
> lately!

No objections here. A testnet is excellent and much needed...errr...thing :P

--

-- 
[ cruise / casual-tempest.net / transference.org ]
   "quantam sufficit"

Re: Re: debian packages

Richard A. Hecker wrote:
> Archives are kept pristine.  You may notice that freenet has been
> dropped from Debian. The original maintainer is MIA and I plan to upload
> a new package when things stabilize.  I build packages for the stable
> release versions.  I could probably make them available if there was
> sufficient interest.  I took a JAVA class that required me to use the
> SUN JVM but I would not encourage others to pollute their system.

Our almost daily release process isn't particularly comptable with 
systems like Debian which appear to be geared towards less frequent 
releases.

Perhaps a better approach would be to create a "freenet-wrapper" package 
that doesn't actually contain the latest .jar file, but which downloads 
these (and other transient files) as necessary from our website.

Ian.

Re: So, why are we against DHTs?

Shea Parkes wrote:
> (Maybe this should go in tech mailing list

That is one thing in your email I can wholeheartedly agree with.

Ian.

Re: Compromize on testnetwork, etc

Toad wrote:
> Hi. We've talked about test networks; I think test network is a good
> idea. Oskar is pretty big on simulations; I can see what he's getting at
> but I plomp for testnet for various reasons. There are attack models I'd
> like to run once we have a working testnet, but more importantly, we
> need to know what's going on with routing, and that can happen much more
> easily with testnet. 

I have no issue with a testnet in principal, provided that it is created 
in parallel with addressing more immediate concerns - which seems to be 
your proposal.

Having said that, I would much rather see some specific examples of 
experiments that we can do with the test network, and questions that we 
need a testnet to answer, rather than just vague "lets try it and all 
our questions will be answered".

Additionally, I think there is still lots we can learn through 
appropriate examination of real network nodes - and I don't see a 
burning need for us to overload ourselves with data from hundreds of 
nodes when we still have trouble interpreting data from just one.

> I look forward to a good flamewar; the list has been rather quiet
> lately!

Sorry to disappoint.

Ian.

Re: More routing inaccuracy, restarts

On Wed, 30 Jun 2004 21:45:17 +0100, Toad wrote:

> Recently I discovered a scenario that is not properly dealt with by the
> current code:
> We get as far as a transfer.
> The source node gets a failure from its source node, and returns a
> CB_RESTARTED.
> We then wait for a QueryRestarted.
> If we don't get one, we fail and go on to the next node; right now this
> is counted as an early timeout, but it shouldn't be.
> If we do get one, we essentially wait for the request to go through all
> over again, but with less HTL.
> 
> If you don't want to wade through the maths, go to the end of this
> message, and read the conclusions.
> 
> I discovered that the current estimate formula was:
> estimate = tSuccess + tFailure / pFailure.

So the less likely we are to fail, the higher the estimate will be,
meaning this is a worse node ? Doesn't make sense...

Are you sure you didn't mean tSuccess + tFailure / pSuccess ?

> The idea here is to calculate the time it will take to get the data if
> we just keep on retrying, and we always have the same chance of
> succeeding. We assume we retry on the target node, because that simplifies
> things, and it is the target node we are interested in when sorting.

Well, your formula is not counting that; if this is what the code really

Re: Re: debian packages

On Thu, 01 Jul 2004 14:30:26 +0100, Ian Clarke wrote:

> Richard A. Hecker wrote:
>> Archives are kept pristine.  You may notice that freenet has been
>> dropped from Debian. The original maintainer is MIA and I plan to upload
>> a new package when things stabilize.  I build packages for the stable
>> release versions.  I could probably make them available if there was
>> sufficient interest.  I took a JAVA class that required me to use the
>> SUN JVM but I would not encourage others to pollute their system.
> 
> Our almost daily release process isn't particularly comptable with 
> systems like Debian which appear to be geared towards less frequent 
> releases.
> 
> Perhaps a better approach would be to create a "freenet-wrapper" package 
> that doesn't actually contain the latest .jar file, but which downloads 
> these (and other transient files) as necessary from our website.

Or simply set up a cron job to update the node at 5:00 each morning.

Hmm... On second thought, this has a high likelihood of bringing down the
server. Maybe you could set up a permanent BitTorrent seed and tracker,
that could be used to download the new node ? Debian includes the
BitTorrent client.

Of course, the best solution would be to download the new node from
Freenet, but that has the what-if-our-private-key-is-stolen -problem.

BTW. Why does the Environment page claim that the JVM has only allocated
62 MB when top claims that the RSS is 110 MB (and the total size 472 MB -

Re: I hate Sun

Toad schrieb:

> <toad__> however they have introduced some major bugs too
> <toad__> in the BigInteger support
> <toad__> these affect routing...
> <toad__> we don't get misrouting, we just get NullPointerExceptions and
> NumberFormatExceptions in JVM code...
> <toad__> which generally can't be worked around

With the 1.5 beta 2 I didn't see anything like this running unstable for about
12 hours. So, is it possible that those bugs are fixed there? Or was it just
luck?

Re: Re: debian packages

On Thu, Jul 01, 2004 at 02:30:26PM +0100, Ian Clarke wrote:
> Richard A. Hecker wrote:
> >Archives are kept pristine.  You may notice that freenet has been
> >dropped from Debian. The original maintainer is MIA and I plan to upload
> >a new package when things stabilize.  I build packages for the stable
> >release versions.  I could probably make them available if there was
> >sufficient interest.  I took a JAVA class that required me to use the
> >SUN JVM but I would not encourage others to pollute their system.
> 
> Our almost daily release process isn't particularly comptable with 
> systems like Debian which appear to be geared towards less frequent 
> releases.
> 
> Perhaps a better approach would be to create a "freenet-wrapper" package 
> that doesn't actually contain the latest .jar file, but which downloads 
> these (and other transient files) as necessary from our website.

Or simply automatically build a DEB along with the other snapshots, and
set up the directories so that it works for updating... how hard would
that be? I suppose we'd need to generate a new Packages file each time?
--

-- 
Matthew J Toseland - toad@...
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

_______________________________________________
Devl mailing list
Devl@...
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: Re: More routing inaccuracy, restarts

On Thu, Jul 01, 2004 at 05:12:53PM +0300, Jusa Saari wrote:
> On Wed, 30 Jun 2004 21:45:17 +0100, Toad wrote:
> 
> > Recently I discovered a scenario that is not properly dealt with by the
> > current code:
> > We get as far as a transfer.
> > The source node gets a failure from its source node, and returns a
> > CB_RESTARTED.
> > We then wait for a QueryRestarted.
> > If we don't get one, we fail and go on to the next node; right now this
> > is counted as an early timeout, but it shouldn't be.
> > If we do get one, we essentially wait for the request to go through all
> > over again, but with less HTL.
> > 
> > If you don't want to wade through the maths, go to the end of this
> > message, and read the conclusions.
> > 
> > I discovered that the current estimate formula was:
> > estimate = tSuccess + tFailure / pFailure.
> 
> So the less likely we are to fail, the higher the estimate will be,
> meaning this is a worse node ? Doesn't make sense...
> 
> Are you sure you didn't mean tSuccess + tFailure / pSuccess ?

D'oh, you're right!
> 
> > The idea here is to calculate the time it will take to get the data if
> > we just keep on retrying, and we always have the same chance of
> > succeeding. We assume we retry on the target node, because that simplifies

Re: So, why are we against DHTs?

On Wed, Jun 30, 2004 at 01:56:15PM -0700, Shea Parkes wrote:
> You get one huge positive from a DHT though.  A great
> working scalable distributed data store.  I'm just not
> knowledgable enough to know if you can tack on
> anonymity well enough.

Do you? Are there any? That actually work for large scale storage?
--

-- 
Matthew J Toseland - toad@...
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

_______________________________________________
Devl mailing list
Devl@...
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl