gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Helo's in database?


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Helo's in database?
Date: Sun, 16 Mar 2003 16:47:37 -0500
User-agent: KMail/1.5

You did not quite get the point of the bug. Every peer has currently one to 
three different HELO messages (one per transport). These HELO messages need 
to be updated once in a while since the "expiration time" always changes. 
Then we need to re-compute the RSA signature. The bug was that the RSA 
signature was re-computed "all the time".

I'm about to commit a patch that will cache the signed HELOs in memory and 
re-compute them periodically. Using any form of database for this 
non-persistent 3 kb of data does not make any sense. Note that "foreign" 
HELOs from other peers in data/hosts do not require any updates or 
re-computations.

Christian

On Sunday 16 March 2003 02:10 pm, Jan Marco Alkema wrote:
> Hello Christian, Igor,
>
> >   mtu = transportGetMTU(tsession->ttype);
> >   buffer = MALLOC(mtu);
> >+  /* FIXME: this call literally burns a ton of CPU time.
> >+     We should *cache* all the HELOs that *we* create and
> >+     update the cache periodically (since the expiration time
> >+     changes). Then we should just return cached HELOs from
> >+     the cache instead of re-signing all the time. */
> >   heloEnd = getAdvertisedHELOs(mtu - sizeof(PINGPONG_Message),
> >                            buffer);
>
> Could the HELOs not be stored in a MySQL database? I know that good
> "database management systems" put often asked query's in memory.
>
> I believe in the "compliance thing": Give users the ability to
> enable/disable MySQL for storing HELOs (option in gnunet.conf). If users
> find it better to use MySQL the will turn it on.
>
> Greetings Jan Marco
>
>
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnunet-developers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]