[Mono-dev] SSL Channel implementation and SslServerStream

[Sebastien Pouliot]

Hey,

On Mon, 2007-12-17 at 21:47 +0100, pablosantosluac wrote:
> Hi again,
> 
> 
> Well, the line which is actually consuming 50% of the time is
> new MonoX509.X509Certificate(serverCertificate.GetRawCertData());
> 
> inside the ServerContext constructor.

Are you running this under Mono or MS runtime ?

> Of course it is related to the RSA calculation inside the MonoX509 
> certificate. 

Please provide additional details as there is no RSA computation
required in the mentioned ctor.

> I guess it could be catched 

you mean "cached" ?

> when attending different clients 
> with the same server certificate, which would improve overall performance 
> (in my previous email I said it was only local to one client, but I was 
> wrong).

As I said this CANNOT be cached between a server and multiple clients (a
little long to explain but it's how SSL is designed).

> 
> 
> Regards,
> 
> 
> 
> pablo
> 
> 
> 
> ----- Original Message ----- 
> From: "Sebastien Pouliot" <sebastien.pouliot at gmail.com>
> To: "pablosantosluac" <pablosantosluac at terra.es>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Monday, December 17, 2007 7:50 PM
> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream
> 
> 
> > Hello Pablo,
> >
> > On Mon, 2007-12-17 at 17:21 +0100, pablosantosluac wrote:
> >> Hi again,
> >>
> >> Well, looking into the ServerContext constructor: the code converts 
> >> between
> >> the System.Security cert to a Mono cert. Ok, this calculation could be
> >> skipped if a server is launching threads with the same certificate. The
> >> performance hit "caching" this one is about a 50% (launching 350 client
> >> threads simultaneously).
> >
> > Sorry but this is confusing. Let me clear this up a bit so the answer
> > will be meaningful when goggled in the future ;-)
> >
> > Converting the certificate between the minimal MS X509Certificate and
> > the Mono.Security X509Certificate is a very simple process. This could
> > be cached but this, alone, won't influence much performance.
> >
> > The key exchange does an expensive RSA operation, but it cannot be
> > cached in ServerContext.
> >
> > Now what *could* help is implementing a session cache in the
> > server[1][2]. However this helps only caching a session between the
> > server and a single client - you cannot share a session between multiple
> > clients.
> >
> > That being said the server code won't scale to support, efficiently, 350
> > sessions. If you need high performance SSL code don't look at a managed
> > implementation (and IMO consider hardware acceleration).
> >
> > [1] the SslClientStream already support session caching
> > [2] contributions welcome
> >
> >>
> >> I'll try to locate the next bottleneck
> >
> > All cryptographic operations, like key exchange, encryption, integrity,
> > will show as a "bottleneck" - but they are exactly what you (should)
> > seek by choosing SSL.
> >
> >>
> >>
> >> pablo
> >>
> >>
> >> ----- Original Message ----- 
> >> From: "pablosantosluac" <pablosantosluac at terra.es>
> >> To: <mono-devel-list at lists.ximian.com>
> >> Sent: Monday, December 17, 2007 4:23 PM
> >> Subject: [Mono-dev] SSL Channel implementation and SslServerStream
> >>
> >>
> >> > Hi all,
> >> >
> >> > I'm implemented a secured TCP remoting channel. I took the current TCP
> >> > Channel as starting point, and used Ssl{Client|Server}Stream to 
> >> > implement
> >> > communication, as Robert Jordan suggested.
> >> >
> >> > Well, it seems it works correctly but I've found the following issue:
> >> > creating each new connection takes time (obviously), but it is 
> >> > basically
> >> > due
> >> > to a call to "new ServerContext" inside the SslServerStream 
> >> > constructor.
> >> >
> >> > The problem, in fact, seems related with the property
> >> > X509Certificate::RSA.
> >> > Each time a new connection is opened, a new certificate is given, and 
> >> > the
> >> > private key used.
> >> >
> >> > Is there a way to actually make all this initialization just once? It
> >> > would
> >> > greatly improve performance both in Mono and .NET.
> >> >
> >> > Any idea?
> >> >
> >> > thanks
> >> >
> >> > pablo
> >> >
> >> > _______________________________________________
> >> > Mono-devel-list mailing list
> >> > Mono-devel-list at lists.ximian.com
> >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >>
> >> _______________________________________________
> >> Mono-devel-list mailing list
> >> Mono-devel-list at lists.ximian.com
> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > 
>