gnutls-devel
[Top][All Lists]
Advanced

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

Re: interface


From: Nikos Mavroyanopoulos
Subject: Re: interface
Date: Sat, 26 Feb 2000 22:43:26 +0200
User-agent: Mutt/1.0i

On Sat, Feb 26, 2000 at 01:39:59PM +0530, Tarun Upadhyaya wrote:

> however, an init function should be used anyway as GNUTLS_STATE could be
> initialized to different values based on client's environment params,
> preferences for this session etc. (or will this be handled by the
> gnutls_init later down with other initializations?)
Well, i agree that gnutls_init should handle all these. So lets remove
that malloc.

> > [in case we support session resuming:
> > GNUTLS_SESSIONS *sessions=malloc(20*SIZEOF_SESSION);
> > /* keep a buffer of the last 20 sessions. A single session should
> >  * have a timestamp, so it will expire in a few hours
> >  *
> >  * in case of client:
> > GNUTLS_SESSIONS *session=malloc(1*SIZEOF_SESSION);
> I am not very experienced but 20 sessions looks like an overkill to me
> in most cases. Can we replace that with a sorted list or something?

Well i do not think that it is really needed. The server may do
after every session:
 i++;
 sessions=realloc(sessions, i*SIZEOF_SESSION); 
in order to fit all sessions he needs.

We may also add the functions:
int gnutls_how_many_expired_sessions(GNUTLS_SESSIONS * sessions);
int gnutls_strip_expired_sessions(GNUTLS_SESSIONS* old_sessions, 
GNUTLS_SESSIONS* new_sessions);
which will copy old_sessions to new sessions removing the expired sessions.

so the user can:
new_sessions=malloc( 
(current_session_num-gnutls_how_many_expired_sessions(sessions)) * 
SIZEOF_SESSION);
gnutls_strip_expired_sessions(sessions, new_sessions);

We can however make gnutls_clear_expired_sessions() to automatically allocate
the space it needs, but i do not think that calling malloc() in a library
function is a good idea. If you have any other idea one these functions,
i'd like to hear... I do not like them:)

> Also, why should client keep only one session? I dont know but are there
> absolutely no circumstances when client would like to revert to a
> previously negotiated session?
This is one the client implementation side. It has nothing to do
with the library. The client can hold as many sessions as it likes.


> with warm regards
> tarun

-- 
Nikos Mavroyanopoulos
mailto:address@hidden


reply via email to

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