Send Devl mailing list submissions to
        devl at freenetproject.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.uprizer.com/mailman/listinfo/devl
or, via email, send a message with subject or body 'help' to
        devl-request at freenetproject.org

You can reach the person managing the list at
        devl-admin at freenetproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Devl digest..."


Today's Topics:

   1. Snapshots (Fred Salzer)
   2. Re: Snapshots (Ian Clarke)
   3. RE: Snapshots (Fred Salzer)
   4. Announcement Protocol (Oskar Sandberg)
   5. Re: Proposal: algorithm for forgetting documents in datastore (Tavin Cole)
   6. Re: Proposal: algorithm for forgetting documents in datastore (Tavin Cole)
   7. Re: Proposal: algorithm for forgetting documents in datastore (Ian Clarke)
   8. Cleaning up Freenet/contrib (Tavin Cole)
   9. Re: Announcement Protocol (Adam Langley)
  10. Re: Announcement Protocol (Adam Langley)
  11. Re: Announcement Protocol (Scott G. Miller)
  12. [Freenet-dev] (sans sujet) (GregoryRbrts at aol.com)
  13. Re: Announcement Protocol (Adam Langley)
  14. GMP/GCJ update. (Mark J. Roberts)
  15. Re: GMP/GCJ update. (Ian Clarke)

--__--__--

Message: 1
From: "Fred Salzer" <[email protected]>
To: <devl at freenetproject.org>
Date: Mon, 29 Jan 2001 15:12:14 -0800
Subject: [freenet-devl] Snapshots
Reply-To: devl at freenetproject.org

The Win snapshot freenet.jar files are about 275K whereas 0.3.6 and 0.3.6.1
freenet.jar are each over 400K. The most recent snapshot that I looked at
was today's. No, I didn't try to run it. :)

Fred



--__--__--

Message: 2
Date: Mon, 29 Jan 2001 16:01:04 -0800
From: Ian Clarke <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Snapshots
Reply-To: devl at freenetproject.org


--UlxN1C6awaFNesUv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Jan 29, 2001 at 03:12:14PM -0800, Fred Salzer wrote:
> The Win snapshot freenet.jar files are about 275K whereas 0.3.6 and 0.3.6.1
> freenet.jar are each over 400K. The most recent snapshot that I looked at
> was today's. No, I didn't try to run it. :)

Interesting, seems the snapshots are working again - they must have
fixed make on Sourceforge.

Ian.

--UlxN1C6awaFNesUv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6dgRAQtgxRWSmsqwRAq9vAJ9QIQKQSJlWf1YAHxy2F2imOAcAGgCfVTQ6
yOkQVVhAYwvDJeNoauViSbw=
=a63V
-----END PGP SIGNATURE-----

--UlxN1C6awaFNesUv--


--__--__--

Message: 3
From: "Fred Salzer" <[email protected]>
To: <devl at freenetproject.org>
Subject: RE: [freenet-devl] Snapshots
Date: Mon, 29 Jan 2001 17:33:20 -0800
Reply-To: devl at freenetproject.org

Except it's not making a complete freenet.jar. It's working now similarly to
how it was working just before it failed completely a month or so ago.

Fred

-----Original Message-----
>Interesting, seems the snapshots are working again - they must have
>fixed make on Sourceforge.

>Ian.



--__--__--

Message: 4
Date: Tue, 30 Jan 2001 03:22:59 +0100
From: Oskar Sandberg <[email protected]>
To: Freenet devl <devl at freenetproject.org>
Subject: [freenet-devl] Announcement Protocol
Reply-To: devl at freenetproject.org


This is a proposal for the node announcement protocol to replace
"inform.php" in 0.4. It may seem a little overly complicated at first, so
read the rational at the bottom before asking about that. Feedback from
the wise (Hal...) would be appreciated.

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/docs/announcement.txt?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=freenet

-- 
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.

Oskar Sandberg
md98-osa at nada.kth.se


--__--__--

Message: 5
Date: Mon, 29 Jan 2001 23:31:46 -0500
From: Tavin Cole <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Proposal: algorithm for forgetting documents in 
datastore
Reply-To: devl at freenetproject.org

On Mon, Jan 29, 2001 at 03:53:45PM +0100, Neil Barsema wrote:
> Hi All,
> 
> Up until now the only factors in determining what files to drop from
> the datastore have been size and popularity.
> 
> An other factor that would be nice to take into account is
> scarceness. Now this is the exact oposite of popularity so it is a
> bit tricky.
> But it would be nice as it would put to rest all those people who
> think Freenet loses their files too quickly.
> 
> The aproach I suggest is to reward a file for being close to the
> network percieved keyspace(s) of the node.

But files that are *not* close to the node's keyspace will tend to
drop out of the cache (if they ever make it in there) because requests
for those keys won't be routed to that node.  So what could be gained
from applying extra rewards to the close files?

-- 

// Tavin Cole


--__--__--

Message: 6
Date: Mon, 29 Jan 2001 23:40:58 -0500
From: Tavin Cole <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Proposal: algorithm for forgetting documents in 
datastore
Reply-To: devl at freenetproject.org

On Sun, Jan 28, 2001 at 10:52:10PM -0500, Scott G. Miller wrote:
> > > (I'm sure there's a nicer way to express this as a continuous function 
> > > using an integral, but I can't think of it at the moment.  Anyway, you
> > > get the idea.)
> > 
> > Sure, although I don't think we should be decaying P until something is
> > at least a day or two old.
> 
> Why are we decaying by real time anyway?  Shouldn't we ditch time in favor
> of a 'time' measured by requests and inserts passing through the node?

This is an excellent point.  We wouldn't even need to decay P at all --
there would simply be a practical limit on how far back in time the node
can remember.

-- 

// Tavin Cole


--__--__--

Message: 7
Date: Mon, 29 Jan 2001 23:15:18 -0800
From: Ian Clarke <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Proposal: algorithm for forgetting documents in 
datastore
Reply-To: devl at freenetproject.org


--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Jan 29, 2001 at 11:40:58PM -0500, Tavin Cole wrote:
> This is an excellent point.  We wouldn't even need to decay P at all --
> there would simply be a practical limit on how far back in time the node
> can remember.

The more people discuss this, the more it starts to sound like a L.R.U
cache which is what we have right now.

Ian.

--RnlQjJ0d97Da+TV1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6dmoGQtgxRWSmsqwRAvhDAJsHw/T3hAgqMSKnoCi3HMgTrYOo6gCeJUTf
1EHNMVytkAG7xU2EeTniUgo=
=T+fl
-----END PGP SIGNATURE-----

--RnlQjJ0d97Da+TV1--


--__--__--

Message: 8
Date: Tue, 30 Jan 2001 02:10:02 -0500
From: Tavin Cole <[email protected]>
To: devl at freenetproject.org
Subject: [freenet-devl] Cleaning up Freenet/contrib
Reply-To: devl at freenetproject.org

I think it was the consensus on this list that we move everything out
of Freenet/contrib except attacks and fproxy.  So I am going to delete
all the extra stuff from the experimental branch.  Anything that needs
to be saved should be placed in the Contrib module before we merge
experimental back into the trunk.

Does this sound okay to everyone?

-- 

// Tavin Cole


--__--__--

Message: 9
Date: Tue, 30 Jan 2001 02:53:21 -0800
From: Adam Langley <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Announcement Protocol
Reply-To: devl at freenetproject.org

On Tue, Jan 30, 2001 at 03:22:59AM +0100, Oskar Sandberg wrote:
> This is a proposal for the node announcement protocol to replace
> "inform.php" in 0.4. It may seem a little overly complicated at first, so
> read the rational at the bottom before asking about that. Feedback from
> the wise (Hal...) would be appreciated.

I take it that in "hash(x1 + hash(x0))" , the + is append, not add.

"Each node on the route back the message and continues to append it's closest 
key to x (excluding the previous). "
Does this mean excluding *all* the prev references? or just the last one. I 
guess all of them (makes more sense)

Other than that this has been generally agreed on the list before I think.
Nothing jumps out at me as being a mistake, I'll give it a think. First
impressions are very good.

AGL




--__--__--

Message: 10
Date: Tue, 30 Jan 2001 05:46:03 -0800
From: Adam Langley <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Announcement Protocol
Reply-To: devl at freenetproject.org

On Tue, Jan 30, 2001 at 03:22:59AM +0100, Oskar Sandberg wrote:
> This is a proposal for the node announcement protocol to replace
> "inform.php" in 0.4. It may seem a little overly complicated at first, so
> read the rational at the bottom before asking about that. Feedback from
> the wise (Hal...) would be appreciated.

Well, I'm not the wise - but I'd read it anyway

What exactly is a node reference? PublicKey+Addr1+...+AddrN?

"Bob1 first checks that he has no previous references to Alice in his 
store. If he does he sends back:"

What is this check? Just the address? (which is bad because node might
want to reannounce if the store is lost) or a match of the PK? (which,
 is much better)

 "Reason=1"
 What other reasons could there be? And do we really need to give a 
 reason if there are other reasons?

 "randomly picks a reference out of his routing table,
 Bob2, to which he sends the message as follows"
 I assume the message is handled as normal with respect to Timeouts
 and QueryRestarts?

 "AnnouncementReply
 <common fields - including DataLength>
 ReturnValue=xN
 Data
 pkencrypt[Alice pk](r),encrypt[r](xN, sign[BobN](xN), Address[BobN]))
 "

 Why put the data in a trailing feild? Keep it in the headers and parse
 it normally.

 "ReturnValue=xN"
 hash(xN)?, cos below it's hash (xN-1 + xN)

 "Address[BobN]"
 NodeReference BobN?

 "AnnouncementExecute
 <common fields - including DataLength>
 RefSignatue=Sign[Alice](x)
 Data
 x1
 x2
 .
 .
 .
 xN
 "

 Again, make feilds 
 Nonce.1=x1
 Nonce.2=x2

 and keep it out of the trailing feild so that we don't have to write
 new parsers.

 AGL



--__--__--

Message: 11
Date: Tue, 30 Jan 2001 10:55:37 -0500
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Announcement Protocol
From: "Scott G. Miller" <[email protected]>
Reply-To: devl at freenetproject.org


--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

>  "AnnouncementReply
>  <common fields - including DataLength>
>  ReturnValue=3DxN
>  Data
>  pkencrypt[Alice pk](r),encrypt[r](xN, sign[BobN](xN), Address[BobN]))
>  "
>=20
>  Why put the data in a trailing feild? Keep it in the headers and parse
>  it normally.
You can't parse it, its encrypted.  And its likely to be fairly long.  xN
is going to be at least 160 bits (40 hex characters), signature is
up to 2048 bits (512 characters), address contains a lot of information as
well. =20


>  "Address[BobN]"
>  NodeReference BobN?
>=20
>  "AnnouncementExecute
>  <common fields - including DataLength>
>  RefSignatue=3DSign[Alice](x)
>  Data
>  x1
>  x2
>  .
>  .
>  .
>  xN
>  "
>=20
>  Again, make feilds=20
>  Nonce.1=3Dx1
>  Nonce.2=3Dx2

Why?  Its just as easy to read the data as ordered newline terminated
fields here.  Better actually, because you don't have to try and match up
the subfield numbers with their sender.=20


--2fHTh5uZTiUOsy+g
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6duP5r9IW4v3mHtQRAkSfAJ9sugY/HoIuvDnFYeAUqqMyrGz9kQCfTo8S
8+uqQTZx5xuy/m+BEofMI0U=
=cfMt
-----END PGP SIGNATURE-----

--2fHTh5uZTiUOsy+g--


--__--__--

Message: 12
From: [email protected]
To: freenet-dev at lists.sourceforge.net
Date: Tue, 30 Jan 2001 12:27:44 EST
Subject: [freenet-devl] [Freenet-dev] (sans sujet)
Reply-To: devl at freenetproject.org

Sirs:

I have been trying unsuccessfully now for three days to run freenet. I 
charged and recharged the program three times first installing the jave 
prerequisite as indicated. I repeadely click ont the rabbit icon with no 
responce. What am I not doing? Please help.
Thanks,

Gregory Roberts

_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/freenet-dev


--__--__--

Message: 13
Date: Tue, 30 Jan 2001 18:23:40 +0000
From: Adam Langley <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Announcement Protocol
Reply-To: devl at freenetproject.org


--fdj2RfSjLxBAspz7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 30, 2001 at 10:55:37AM -0500, Scott G. Miller wrote:
> >  "AnnouncementReply
> >  <common fields - including DataLength>
> >  ReturnValue=3DxN
> >  Data
> >  pkencrypt[Alice pk](r),encrypt[r](xN, sign[BobN](xN), Address[BobN]))
> >  "
> >=20
> >  Why put the data in a trailing feild? Keep it in the headers and parse
> >  it normally.
> You can't parse it, its encrypted.  And its likely to be fairly long.  xN
> is going to be at least 160 bits (40 hex characters), signature is
> up to 2048 bits (512 characters), address contains a lot of information as
> well.

Alice does. But I accept the length argument

> Why?  Its just as easy to read the data as ordered newline terminated
> fields here.  Better actually, because you don't have to try and match up
> the subfield numbers with their sender.=20

Ok - it's only a cosmetic point anyway.

AGL

--=20
Never attribute to malice that which is adequately explained by stupidity.

--fdj2RfSjLxBAspz7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjp3BqwACgkQzaVS3yy2PWBeMACfYnl+OJN7acdx6dVWOa26//04
WpoAnjmvQtDltOeqOQvwOmth1BYSp0KB
=eH/w
-----END PGP SIGNATURE-----

--fdj2RfSjLxBAspz7--


--__--__--

Message: 14
Date: Tue, 30 Jan 2001 12:18:59 -0500 (EST)
From: "Mark J. Roberts" <[email protected]>
To: <devl at freenetproject.org>
Subject: [freenet-devl] GMP/GCJ update.
Reply-To: devl at freenetproject.org

So a couple weeks ago we were talking about adding GMP support to libgcj.

I consulted upon Those Who Know. Here's what I found out:

1) Yes, they want GMP support, configurable with an #ifdef/else.

2) Their MPN.java, which deliberately mimics the GMP API, must be
converted to be a wrapper around native methods through CNI.

[quote]

So the plan is to replace MPN with trivial wrappers around GMP mpn
functions.  For example:

public class MPN
{
  public static native int add_1 (int[] dest, int[] x, int size, int y);
  ....
}

jint gnu::gcj::math::MPN::add_1 (JArray<jint>* dest, JArray<jint>* x,
        jint size, jint y)
{
#ifdef USE_GMP
    return mpn_add_1 ((mp_limb_t *) elements(dest), (mp_limb_t *) elements(x),
        (mp_size_t) size, (mp_size_t) y)
#else
    // Transcription from the Java version.
    jlong carry = (jlong) y & 0xffffffffL;
    for (jint i = 0;  i < size;  i++)
      {
        carry += ((jlong) x[i] & 0xffffffffL);
        dest[i] = (int) carry;
        carry >>= 32;
      }
    return (jint) carry;
#endif
}

[end quote]

3) This is on the RedHat TODO list, but it may be a long time before it's
done.

Okay. This seems rather easy, and I could probably do the bulk of the
work, but I need someone fluent in C to check it out. Volunteers?

BTW, the GCJ in CVS now correctly compiles Fred without any patching. The
BigInteger support is still broken, however.


-- 
Mark Roberts
mjr at statesmean.com




--__--__--

Message: 15
Date: Tue, 30 Jan 2001 10:38:20 -0800
From: Ian Clarke <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] GMP/GCJ update.
Reply-To: devl at freenetproject.org


--vOmOzSkFvhd7u8Ms
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jan 30, 2001 at 12:18:59PM -0500, Mark J. Roberts wrote:
> Okay. This seems rather easy, and I could probably do the bulk of the
> work, but I need someone fluent in C to check it out. Volunteers?

Well, I am not really fluent in any language any more apart from
"Journalist" - so I will leave this to someone else.  Just to say that a
Freenet node binary will be great, since it will allow us to create
easily deployable rpm and deb packages, perhaps paving the way for
getting into these distributions and greatly enhancing Freenet node
deployment on reliable (ie. Linux) machines.

> BTW, the GCJ in CVS now correctly compiles Fred without any patching. The
> BigInteger support is still broken, however.

Beautiful, I can't wait for our first fully-working Fred binary!

Ian.

--vOmOzSkFvhd7u8Ms
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6dwocQtgxRWSmsqwRAs5RAJ9Dq9RN+tFTuJRDmBPUlkyViGKTPQCePm+1
aw7qTU2WO8IvLE0BCt+8Q1M=
=WOjM
-----END PGP SIGNATURE-----

--vOmOzSkFvhd7u8Ms--



--__--__--

_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://www.uprizer.com/mailman/listinfo/devl


End of Devl Digest

Reply via email to