dotgnu-pnet
[Top][All Lists]
Advanced

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

Re: [Pnet-developers] SSL/TLS support in pnetlib


From: Chris Smith
Subject: Re: [Pnet-developers] SSL/TLS support in pnetlib
Date: Sat, 31 May 2003 23:01:16 +0100

> On Saturday 31 May 2003 06:06 pm, Gopal V wrote:
>
> > I have just committed the SSL support into HttpWebRequest ... and tested
> > it by downloading a page from https://secure.symonds.net/ which means
we're
> > cool !.
>
> Fantastic!
>
> > I hope I implemented it right ... ie a Session is constructed globally ,
> > which I hope is not wrong ?. This session is destroyed only when we
> > close down the VM because the object containing the Session is held
> > in a static field. Should I generate a new session per hostname ?.
>
> A new session every time.  The session provider can be stored globally,
but it
> isn't really necessary to do that.  The current code is OK, but I suggest
> removing the static for the provider because there's no need.  Call
> "GetProvider()" and then "CreateClientSession()" in the "SecureConnection"
> constructor.  If it ever makes sense to cache providers, we'll do it in
the
> "DotGNU.SSL" assembly instead.

Hmm.
We need control over the session.
Sometimes you want to avoid the SSL handshake, and thus will want to
use the existing SSL_CTX sesssion.
Howerver, you also want to be able to start a new session, particularly
if you've got several connections to remote servers.

I admit I've not looked at the DotGnu SSL code yet.

Generally you want to cache SSL contexts for use over repeat connections to
the same server as this makes DRASTIC perfomance increases.  The server
will force a re-handshake when it deems necessary, so clients don't have to
worry about it too much.
If the session is 'static' then I can't say off the top of my head what'll
happen when
you connect to a different SSL server from the same VM.
Hmm, presumably the session will be invalid and a rehandshake would be
performed.
But that is very dependent on the SSL implementation, and I'd not like to be
quoted on
what'll happen :o)

Regards,
Chris



reply via email to

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