[gnutls-dev] Generating/regenerating params

[Stephen Frost]

* Nikos Mavroyanopoulos (nmav at gnutls.org) wrote:
> On Sat, Mar 06, 2004 at 02:19:31AM -0500, Stephen Frost wrote:
> >   We then have a local (per thread) context which copies the cred from 
> >   the global context, but just the pointer (there isn't a function to
> >   copy the whole thing...).
> There is no need to copy the whole thing, since the credentials
> are only read by the sessions. They are never modified.

Sure, but if I could make the creds structure local to each thread I'd
solve the param generation problem.

> >   What's the right way to do this?  Have multiple threads going and
> >   still periodically regenerate the rsa/dh params without breaking
> >   anything or leaking memory or anything?  Is it safe to just init the
> >   rsa/dh params and then just change them with generate2 or import_raw?
> >   Will that break existing connections or other threads which are
> >   setting up their connections?  Do I still need to call set_XX_params?
> 
> Currently there is no easy way to renew that parameters in multithreaded 
> applications. I was thinking into adding functions or callbacks to set those 
> parameters per session. Would this solve your problem?

I *think* I've stumbled across a reasonable solution for the moment.
From what I can tell, params are only used during setup/handshake.  What
I've done is basically lock around the setup/handshake routine and just
generate/reread/cache the params before setup/handshake and then free
them after.  There's currently no function to free the params when
they're stored inside the credentials structure so I have to track the
params pointers seperately (not that big a deal since they're only
needed through one function which does the setup/handshake, but it'd be
nice if there was way to free *just* the params in the credentials
struct).

Do you see any problem with this approach?

BTW: I'm not too inclined to agree with the 'thread-safe' feature claim
on the webpage. :)

	Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/attachments/20040309/a6e227f7/attachment.bin