; invalid...
> >
> > Anyway, what do we want to do here? What about disconnecting from the
> > peer altogether?
> >
> forceDisconnect(false) and tell the user. No?
What's the point of telling the user?
Disconnection has been implemented in r21643
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/2f5eba8d/attachment.pgp>
leased 1155 cannot accept
> such compressed handshakes?
Yes it does.
> If so, r21633 is rather premature and will break
> handshaking with older nodes, no?
It's a "receiver-side" patch... At the moment the new code is active
only where it's really needed (in the case of an anonymous-session
establishment: opennet's announcement)... Meaning that until a few
seednodes have updated new clients won't be able to announce.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/d38cf5f9/attachment.pgp>
se claim copyright
> > > (Copyright 2008 Florent Daigniere, ).
> >
> > IMHO we shouldn't put our names in the sources.
> >
> That is the standard form of a GPL header as recommended by the FSF, and as
> you will see in other GPL'ed apps. No?
I will replace it with the short version wich isn't gpl-compliant then.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/2a1e9a87/attachment.pgp>
On Wed, Aug 6, 2008 at 1:36 AM, Matthew Toseland
wrote:
> Good, but it would be even better to pass in only the narrowly specialised
> object you need, rather than Node (in this case, the PRNG and the
> UserAlertManager).
UserAlertManager have not created yet when we create the datastore.
>
> On
On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
wrote:
> On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
>> On August 5, 2008, Matthew Toseland wrote:
>> > On Sunday 03 August 2008 00:58, you wrote:
>> > > On August 2, 2008, Matthew Toseland wrote:
>> > > > On Saturday 02 August 2008 02:41,
rt --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/25e21042/attachment.pgp>
Ed Tomlinson wrote:
>> Do we need to store the location for each key? (so that we can update
>> the average location when the key is removed)
>> Maybe a running average is just good enough?
>> Or just store an approximated location, not the actual value?
>
> A salted location would work as long as
(eg. less that the routingMissDistance value).
>
> On another topic. For FOF routing, we could also salt locations sent to
friends. Again
> if the salt is less than the routingMissDistance value, I do not think it
will affect routing too
> much... This would make it harder for the reciever of FOF into to figure
out the actual friends.
> Needs simulation though.
>
> > > For requests we'd need something more like a BDRA anyway.
>
> If you use a decaying running average the half life would have to be fairly
large and
> adjusted if the store size changed (we would have to track x, y & n). It
will also tend to distort
> the mean since new kyes will have more effect that old keys - for something
like a store, where
> every key is equally important, this is not a great model.
>
> I this case, I think we _will_ get more meanfull results from a true
average.
>
> How long would it take to recreate the true numbers (maybe from salted keys)
after an unclean shutdown?
It depends on what you use it for. My main interest here is in an accurate and
efficient key location averager that we can use for for example estimating
the incoming requests specialisation. For that we will probably want a
decaying average.
With regards to biasing swapping by the datastore, I would have to see some
detailed simulations, plus I'd want our theoreticians to support it. So far
none of them have expressed an opinion. IMHO the more obvious and urgent
solution is to not swap on opennet, but we need vive to do some simulations
to determine how much impact this would have on a hybrid network.
>
> Thanks
> Ed
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/dd506556/attachment.pgp>
-yet-unreleased 1155 cannot accept
such compressed handshakes? If so, r21633 is rather premature and will break
handshaking with older nodes, no?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/cd5ae717/attachment.pgp>
> >
> > If you are going to use the full GPL header, then please claim copyright
> > (Copyright 2008 Florent Daigniere, ).
>
> IMHO we shouldn't put our names in the sources.
>
That is the standard form of a GPL header as recommended by the FSF, and as
you will see in other GPL'ed apps. No?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/9449b5ee/attachment.pgp>
cipherManager = new CipherManager(newsalt);
> >>
> >> writeConfigFile();
> >> @@ -894,7 +898,7 @@
> >> super.run();
> >>
> >> try {
> >> - while (node.clientCore == null
&& !shutdown) {
> >> + while (node != null && node.clientCore ==
null && !shutdown) {
> >> Thread.sleep(1000);
> >> }
> >> Thread.sleep((int)(CLEANER_PERIOD / 2 +
CLEANER_PERIOD *
> > Math.random()));
> >> @@ -903,6 +907,7 @@
> >> if (shutdown)
> >> return;
> >>
> >> + if (node != null)
> >> node.clientCore.alerts.register(new UserAlert() {
> >> public String anchor() {
> >> return "store-cleaner-" + name;
> >>
> >> ___
> >> cvs mailing list
> >> cvs at freenetproject.org
> >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs
> >>
> >>
> >
> > ___
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/58a43dba/attachment.pgp>
* Matthew Toseland <[EMAIL PROTECTED]> [2008-08-02 20:55:28]:
> On Saturday 02 August 2008 08:10, Florent Daignière wrote:
> > * Matthew Toseland <[EMAIL PROTECTED]> [2008-08-02 01:48:29]:
> >
> > > On Friday 01 August 2008 20:40, Florent Daignière wrote:
> > > > * Matthew Toseland <[EMAIL PROTEC
.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/d426dbd7/attachment.pgp>
* Matthew Toseland <[EMAIL PROTECTED]> [2008-08-06 16:36:20]:
> On Wednesday 06 August 2008 14:53, [EMAIL PROTECTED] wrote:
> > Author: nextgens
> > Date: 2008-08-06 13:53:08 + (Wed, 06 Aug 2008)
> > New Revision: 21631
> >
> > Modified:
> >trunk/freenet/src/freenet/node/PeerNode.java
> >
Ed Tomlinson wrote:
>> Do we need to store the location for each key? (so that we can update
>> the average location when the key is removed)
>> Maybe a running average is just good enough?
>> Or just store an approximated location, not the actual value?
>
> A salted location would work as long as
* Matthew Toseland <[EMAIL PROTECTED]> [2008-08-06 16:32:07]:
> On Wednesday 06 August 2008 16:07, Florent Daignière wrote:
> > * Matthew Toseland <[EMAIL PROTECTED]> [2008-08-05 19:28:25]:
> >
> > > On Tuesday 22 July 2008 15:50, [EMAIL PROTECTED] wrote:
> > > > Author: nextgens
> > > > Date: 20
On Wednesday 06 August 2008 13:06, Ed Tomlinson wrote:
> On August 6, 2008, Daniel Cheng wrote:
> > On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
> > <[EMAIL PROTECTED]> wrote:
> > > On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
> > >> On August 5, 2008, Matthew Toseland wrote:
> > >> > O
On Wednesday 06 August 2008 14:53, [EMAIL PROTECTED] wrote:
> Author: nextgens
> Date: 2008-08-06 13:53:08 + (Wed, 06 Aug 2008)
> New Revision: 21631
>
> Modified:
>trunk/freenet/src/freenet/node/PeerNode.java
> Log:
> bugfix related to bug #1933
>
> Modified: trunk/freenet/src/freenet/no
On Wednesday 06 August 2008 16:07, Florent Daignière wrote:
> * Matthew Toseland <[EMAIL PROTECTED]> [2008-08-05 19:28:25]:
>
> > On Tuesday 22 July 2008 15:50, [EMAIL PROTECTED] wrote:
> > > Author: nextgens
> > > Date: 2008-07-22 14:50:26 + (Tue, 22 Jul 2008)
> > > New Revision: 21304
> > >
* Matthew Toseland <[EMAIL PROTECTED]> [2008-08-05 19:28:25]:
> On Tuesday 22 July 2008 15:50, [EMAIL PROTECTED] wrote:
> > Author: nextgens
> > Date: 2008-07-22 14:50:26 + (Tue, 22 Jul 2008)
> > New Revision: 21304
> >
> ...
> > Added: trunk/freenet/src/freenet/node/SeedServerTestPeerNode.ja
On August 6, 2008, Daniel Cheng wrote:
> On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
> wrote:
> > On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
> >> On August 5, 2008, Matthew Toseland wrote:
> >> > On Sunday 03 August 2008 00:58, you wrote:
> >> > > On August 2, 2008, Matthew Toseland
On August 6, 2008, Daniel Cheng wrote:
> On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
> <[EMAIL PROTECTED]> wrote:
> > On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
> >> On August 5, 2008, Matthew Toseland wrote:
> >> > On Sunday 03 August 2008 00:58, you wrote:
> >> > > On August 2, 200
On Wednesday 06 August 2008 10:25, Daniel Cheng wrote:
> On Wed, Aug 6, 2008 at 1:36 AM, Matthew Toseland
> <[EMAIL PROTECTED]> wrote:
> > Good, but it would be even better to pass in only the narrowly specialised
> > object you need, rather than Node (in this case, the PRNG and the
> > UserAlertMa
On Wed, Aug 6, 2008 at 1:36 AM, Matthew Toseland
<[EMAIL PROTECTED]> wrote:
> Good, but it would be even better to pass in only the narrowly specialised
> object you need, rather than Node (in this case, the PRNG and the
> UserAlertManager).
UserAlertManager have not created yet when we create the
On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
<[EMAIL PROTECTED]> wrote:
> On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
>> On August 5, 2008, Matthew Toseland wrote:
>> > On Sunday 03 August 2008 00:58, you wrote:
>> > > On August 2, 2008, Matthew Toseland wrote:
>> > > > On Saturday 02
* Matthew Toseland <[EMAIL PROTECTED]> [2008-08-05 14:14:02]:
> On Sunday 03 August 2008 10:16, Julien Cornuwel wrote:
> > Hi,
> >
> > I just did a fresh install on Ubuntu 8.04 and I noticed the following
> > problems :
> >
> > - No shotcurts are created on the Desktop or in the Menu.
>
> > Woo
unning average and reset it periodically?
>
> you just need to keep the totals for x and y along with the number of keys
(call this n) . When a
> key is removed from the store subtract its x, y coord and reduce n by 1.
reverse this when adding
> a key...
That could work for the datastore yes, assuming it's persistent; meaning it
will gradually become more inaccurate with unclean shutdowns. and we can't
just wipe it either because then we'd have to reconstruct it from the store
before adding more; maybe it could be integrated with bloom filter
reconstruction for sdiz's store?
For requests we'd need something more like a BDRA anyway.
>
> Ed
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080806/1bfb2f58/attachment.pgp>
27 matches
Mail list logo
