Re: libjcpuid and libjbigi for amd64

On Sun, 27 Feb 2005 10:22:43 -0500, Ed Tomlinson <tomlins@...>
wrote:

> Hi,
> 
> Has anyone built the resources below for amd64?  Suspect this is going
> to be a more commonly reported 'error'.
> 
> I am trying the IBM sdk since sun's 64 bit version is a bit fakely
> with freenet - will see about IBM's.
> 
> TIA
> Ed

I've been meaning to do this, now that I finally have Sun's JDK 1.5.0
installed under FreeBSD on my amd64 box.  I'm actually still running
my node on my older 32-bit Athlon box for now.  I've just been too busy
juggling too many things lately. 

Soon as I can get around to it, I'll report my results here.

--

-- 
Conrad J. Sabatier <conrads@...> -- "In Unix veritas"

Re: A more elegant way to shutdown a node?

On Sat, 26 Feb 2005 13:21:58 +0300, Edgar Friendly wrote:

>>>>>> "Conrad" == Conrad J Sabatier <conrads@...>
>>>>>> writes:
> 
>> If such a facility already exists, please forgive my ignorance, but it
>> seems to me we need a better way to shutdown a node than just sending it
>> a kill signal.  A very busy node will not always respond in a reasonable
>> time to a SIGHUP, and a SIGKILL can cause massive loss of data (I've
>> seen 6,000+ keys disappear from my datastore between runs on occasion).
> 
>> Any ideas on how a nice, clean, data-safe shutdown command might be
>> implemented?
> 
> There have been suggestions of a FCP message in the past.  Enough people
> wanted it authenticated, that we had to come up with a way to protect it. 
> Noone could agree on a secure enough way of doing that, so it didn't get
> done.
> 
> I'm working behind the scenes on how to use BEEP with SASL and TLS to
> implement a Node<->Node protocol.  It'll be a while before I understand
> exactly how these really fit together to actually post any kind of
> protocol specification, but in theory it should be easy to use these for
> any and all communicatin, authentication and encryption we might need.
> 
> Thelema

If a node is too busy to react to SIGHUP in a timely manner, then how
could it possibly process an FCP (or any other protocol) message any
faster ? Especially if it needs to perform (presumably cryptographic)

Re: Re: More packet loss

When was the last time anyone posted source code? :)

On Thu, Feb 24, 2005 at 03:32:30PM -0500, Ken Corson wrote:
> In the interest of _decreasing_ the signal to noise ratio on devl, I 
> hereby retract my earlier critical statement. Let's continue to use this 
> mailing list purely for posting and reviewing source code.
> 
> End of Thread.
> 
> junk@... wrote:
> >I think he might have a point. If reliable delivery is needed (as recent 
> >discussions on packet loss seem to suggest), why not use the existing 
> >transport with decades of testing and proven reliability (i.e. TCP) 
> >rather than pouring Freenet's limited development resources into 
> >re-inventing the wheel
> >
> >-- jeek
> >
> >Todd Walton wrote:
> >
> >>On Thu, 24 Feb 2005 13:31:43 -0500, Ken Corson
<jkcorson@...> 
> >>wrote:
> >> 
> >>
> >>>/me covers his ears against the oncoming roar of "UDP will make Freenet
> >>>significantly faster, able to leap tall firewalls with a single packet,
> >>>blah blah..."
> >>>  
> >>

Re: Re: More packet loss

Yes, there are reliable datagram protocols. However we'd want to encrypt
it at the right layer, so we'd probably want to implement it ourselves.

In any case, I'm not convinced that we need reliable datagram delivery.
At the moment I am exploring what we can do without it.

On Fri, Feb 25, 2005 at 07:55:11PM +0000, Todd Walton wrote:
> On Fri, 25 Feb 2005 13:32:22 +0000, junk@...
> <junk@...> wrote:
> > might it not be better just to take TCP as it comes, rather than
> > re-implement large portions of it just to avoid one feature we don't
> > especially need?
> 
> Is there a TCP-lite implementation out there?  If somebody has already
> done TCP without ordering we might could use it?
> 
> -todd
> 
> On Fri, 25 Feb 2005 13:32:22 +0000, junk@...
> <junk@...> also wrote:
> 
> > Fair enough - obviously we want the right tools for the job and that
> > includes not using a heavyweight protocol if we can make do with a
> > lighter one - but it seems to me like the requirements are creeping up
> > from a thin layer over UDP, to re-implementing large parts of TCP.
> > Current requirements seem to include:
> >    - reliable delivery
> >    - rate control
> > 
> > In fact, the only major feature we *don't* want from TCP seems to be

Re: A more elegant way to shutdown a node?

On Fri, Feb 25, 2005 at 09:41:34PM -0600, Conrad J. Sabatier wrote:
> If such a facility already exists, please forgive my ignorance, but it
> seems to me we need a better way to shutdown a node than just sending it
> a kill signal.  A very busy node will not always respond in a reasonable
> time to a SIGHUP, and a SIGKILL can cause massive loss of data (I've
> seen 6,000+ keys disappear from my datastore between runs on occasion).

That's a bug. It will not be fixed, because 0.7 has a different
datastore.
> 
> Any ideas on how a nice, clean, data-safe shutdown command might be
> implemented?
--

-- 
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: A more elegant way to shutdown a node?

On Sat, Feb 26, 2005 at 01:21:58PM +0300, Edgar Friendly wrote:
> 
> I'm working behind the scenes on how to use BEEP with SASL and TLS to
> implement a Node<->Node protocol.  It'll be a while before I
> understand exactly how these really fit together to actually post any
> kind of protocol specification, but in theory it should be easy to use
> these for any and all communicatin, authentication and encryption we
> might need.

Eh?
> 
> Thelema
--

-- 
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: freenet on private network errors

Is this some kind of Route Not Found variant? How many nodes on the
network, and is there much traffic, and what HTL are you using?

On Sun, Feb 27, 2005 at 12:32:09PM -0800, Tejas Kokje wrote:
> Hi,
> 
> Me and my friend are trying to run freenet on private network.  As suggested, we used localIsOK=true in
freenet.conf file. We also deleted seednodes.ref file from one of the nodes before it was online. After
that we downloaded myref.txt of this node, saved it as seednodes.ref and copied it to the other node (We are
just using two nodes right now for simplicity). We also set maxHopsToLive lower than 20 (infact we set it to 5).
> 
> But now, when trying to insert files into the network, the insert command fails quite a lot. It does succeed
> at times, but we cannot observe any pattern. Heres what we get on insertion failure:
> 
> Any help would be appreciated. Once again this is on a private network.
> 
> 
> 
> ON THE WEB Interface:
> 
> The Insert Request failed.
> 
> Reason: Request failed gracefully: freenet.client.WrongStateException: Wrong state: FAILED should
> be DONE: after waiting for next process
> 
> ON THE CLI:
> [root <at> veladero freenet]# freenet.client.WrongStateException: Wrong state: FAILED should be DONE:
> after waiting for next process
>         at freenet.client.PutRequestProcess.getNextRequest(PutRequestProcess.java:200)
>         at freenet.client.AutoRequester.onReachedState(AutoRequester.java:940)

Re: A more elegant way to shutdown a node?

>>>>> "Matthew" == Matthew Toseland <toad@...> writes:

> On Sat, Feb 26, 2005 at 01:21:58PM +0300, Edgar Friendly wrote:
>> 
>> I'm working behind the scenes on how to use BEEP with SASL and TLS to
>> implement a Node<->Node protocol.  It'll be a while before I
>> understand exactly how these really fit together to actually post any
>> kind of protocol specification, but in theory it should be easy to use
>> these for any and all communicatin, authentication and encryption we
>> might need.

> Eh?

BEEP : RFC 3080 & 3081
http://www.faqs.org/rfcs/rfc3080.html
http://www.faqs.org/rfcs/rfc3081.html
SASL : RFC 2222
http://www.faqs.org/rfcs/rfc2222.html
TLS : RFC 2246
http://www.faqs.org/rfcs/rfc2246.html

The idea is to use a lot of framework that's already been designed by
people willing to put in a lot of effort instead of writing a new
solution from scratch.  The actual protocol will be quite similar to
FNP, it'll just use different pieces for handshaking, authentication,
multiplexing channels over a single TCP connection, framing, etc.

At worst, it'll be a learning experience for me.  At best I'll have a
stable node to node protocol with all sorts of pluggable everything
(SASL and TLS are *very* pluggable).

Re: A more elegant way to shutdown a node?

Yes but does it meet our needs? E.g. silent bob? UDP?

On Wed, Mar 02, 2005 at 06:26:02PM +0300, Edgar Friendly wrote:
> >>>>> "Matthew" == Matthew Toseland <toad@...> writes:
> 
> > On Sat, Feb 26, 2005 at 01:21:58PM +0300, Edgar Friendly wrote:
> >> 
> >> I'm working behind the scenes on how to use BEEP with SASL and TLS to
> >> implement a Node<->Node protocol.  It'll be a while before I
> >> understand exactly how these really fit together to actually post any
> >> kind of protocol specification, but in theory it should be easy to use
> >> these for any and all communicatin, authentication and encryption we
> >> might need.
> 
> > Eh?
> 
> BEEP : RFC 3080 & 3081
> http://www.faqs.org/rfcs/rfc3080.html
> http://www.faqs.org/rfcs/rfc3081.html
> SASL : RFC 2222
> http://www.faqs.org/rfcs/rfc2222.html
> TLS : RFC 2246
> http://www.faqs.org/rfcs/rfc2246.html
> 
> The idea is to use a lot of framework that's already been designed by
> people willing to put in a lot of effort instead of writing a new
> solution from scratch.  The actual protocol will be quite similar to
> FNP, it'll just use different pieces for handshaking, authentication,
> multiplexing channels over a single TCP connection, framing, etc.
> 

Re: A more elegant way to shutdown a node?

>>>>> "Matthew" == Matthew Toseland <toad@...> writes:

> Yes but does it meet our needs? E.g. silent bob? UDP?

BEEP rides on top of TCP.  It doesn't need to do silent bob; it's
already stenographed as an encrypted BEEP service.  There is a RFC
describing BEEP over SCTP, which does what we want.

Thelema
--

-- 
E-mail: thelema@...                            Raabu and Piisu
GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7  84B7 D8D7 6ECE 3635 2AAB