[Mono-dev] SSL Channel implementation and SslServerStream

Tue Dec 18 08:30:19 EST 2007

Hey,

On Tue, 2007-12-18 at 13:13 +0100, pablosantosluac wrote:
> Hi again,
> 
> Ok, forget the last one! It seems I'm getting a huge variation on Linux, but 
> I don't know exactly why. But now I doubt it is really related to the "ssl" 
> code.
> 
> As Sebastien pointed out, on Linux/Mono it seems my "fix" is not necessary 
> at all.
> 
> 
> And this leads me to the second question, related to the one I was 
> discussing with Robert... why there is such a huge difference between runs?
> 
> I'm trying a simple remoting program that just exports a method which waits 
> one second and returns a simple string.
> 
> Ok, having said so, using both a regular tcp channel and a "ssl channel" I'm 
> getting very different times: from completing 200 connections in 7 seconds 
> using SSL to doing the same in 180seconds...
> 
> The same happens with tcp connection: from 2 seconds for 200 connections to 
> more than 90!

Many thing could occurs... How are you doing the timing ? Does it
includes both client and server time ?

If so then there's an optimization that could explain this (or part of
it) variation. As I said in a previous email the SslClientStream
implements session caching. However this works (i.e. save a lot of time)
if a previous *complete* server session exists. 

Now it's possible that too much session are stared simultaneously on the
server, which requires it to do a full session for each (well many)
clients before it can start reuse them. On other runs it's possible a
single session negotiation is completed before others, in this case the
first one can be shared (with *great* performance benefit).

On way to hack around this would be to do a single connection (from each
client to the server) before starting all the threads. That would ensure
a minimum of full (heavy) sessions are done (i.e. a maximum of session
reuse).

> I guess this is related to something its been doing wrong with TCP/IP... 
> ¿?¿?¿?
> 
> 
> Thanks,
> 
> 
> pablo
> 
> 
> 
> 
> ----- Original Message ----- 
> From: "pablosantosluac" <pablosantosluac at terra.es>
> To: "Sebastien Pouliot" <sebastien.pouliot at gmail.com>
> Cc: "mono-devel-list" <mono-devel-list at lists.ximian.com>
> Sent: Tuesday, December 18, 2007 11:18 AM
> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream
> 
> 
> > Hi again Sebastien,
> >
> > I tried to go step by step checking the topics you mentioned.
> >
> > I run my test (opening 200 SSL connections)
> >
> > 1- I tried compiling it with MS/.net 2.0. No difference at all. Same times
> > as 1.1.
> >
> > 2- Run on my box: 1.4 Pentium M with 2GB RAM. (.NET)
> >
> > - Regular mono.security -> 58s
> > - compiled mono.security "caching" (which I think is not general, so a
> > different solution would be needed, but it is valid on my test) the mono
> > internal certification calculation -> 31s
> >
> > 3- Tried on Mono/Linux (Xeon machine).
> > - Regular mono.security -> 94 s
> > - compiled mono.security caching internal X509 certificate generation -> 
> > 47s
> >
> > Ok, I can be doing something wrong in my test, but it really looks like a
> > big performance increase, even on Mono/Linux. The point is actually 
> > caching
> > into the Certificate the internal conversion to the Mono certificate, if
> > possible.
> >
> >
> > Thanks,
> >
> >
> > pablo
> >
> >
> >
> >
> >
> >
> >
> >
> > ----- Original Message ----- 
> > From: "pablosantosluac" <pablosantosluac at terra.es>
> > To: "Sebastien Pouliot" <sebastien.pouliot at gmail.com>
> > Cc: "mono-devel-list" <mono-devel-list at lists.ximian.com>
> > Sent: Tuesday, December 18, 2007 8:28 AM
> > Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream
> >
> >
> >> Hi Sebastien,
> >>
> >> Ok, understood.
> >>
> >> Well, I'll run it with the profiler under mono and let you know where I'm
> >> loosing the time.
> >>
> >> So, yes, I have a big problem when running on .net then... :-(
> >>
> >> Ok, so, if I understand correctly, this RSA property at X509Certificate
> >> class shouldn't take time when running under the mono framework, should
> >> it?
> >> It should be invoked anyway, but wouldn't waste time because the
> >> CryptoServiceProvider is better implemented...
> >>
> >> Thanks,
> >>
> >> pablo
> >>
> >> ----- Original Message ----- 
> >> From: "Sebastien Pouliot" <sebastien.pouliot at gmail.com>
> >> To: "pablosantosluac" <pablosantosluac at terra.es>
> >> Cc: "mono-devel-list" <mono-devel-list at lists.ximian.com>
> >> Sent: Tuesday, December 18, 2007 1:07 AM
> >> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream
> >>
> >>
> >>> Hey,
> >>>
> >>> On Mon, 2007-12-17 at 22:49 +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 ?
> >>>>
> >>>> MS.
> >>>
> >>> well wrong mailing list ;-)
> >>>
> >>> Seriously 1.x frameworks* has a serious design flaw wrt to [RSA|
> >>> DSA]CryptoServiceProvider classes (the former used by the SSL code).
> >>> Each time one you create an instance of it then it *always* creates a
> >>> new keypair - even if it is created to load an existing keypair. This
> >>> makes the classes unusable for server applications.
> >>>
> >>> Mono design is different and a keypair is only created if (and when)
> >>> required.
> >>>
> >>>
> >>> * at least I think it was fixed in 2.0 - I've been bugging them to fix
> >>> this since 1.0 beta2.
> >>>
> >>>> Running with a profiler. Mono results are currently slower, but it 
> >>>> could
> >>>> be related to something else.
> >>>
> >>> If Mono is slower then this is probably elsewhere.
> >>>
> >>>> I'm having problems when creating more than 80
> >>>> threads/sockets. Don't know why yet.
> >>>>
> >>>>
> >>>> >> 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" ?
> >>>>
> >>>> Yes, sorry, 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).
> >>>>
> >>>> Ok, whatever, there's a property called RSA inside the Mono X509
> >>>> certificate. This property gets invoked once per SSL connection,
> >>>> actually
> >>>> calculating the same for each connection,
> >>>
> >>> Well it's not the same since this is a new key pair each time ;-) but
> >>> yes it's unneeded
> >>>
> >>>> because it is just "completing"
> >>>> (AFAIK) the server's certificate, if I'm not wrong, of course. I mean,
> >>>> the
> >>>> certificate you pass to the SSLServerStream gets converted again and
> >>>> again,
> >>>> and consuming time. If this can be cached, then the performance can be
> >>>> really boosted. I think this is *just* the server's certificate, 
> >>>> nothing
> >>>> to
> >>>> do with the client (I guess). And yes, maybe it is not RSA calculation,
> >>>> but
> >>>> this is the name of the property where the time is being spent... at
> >>>> least
> >>>> under MS runtime.
> >>>
> >>> No, as I said, this is probably time "lost" doing unneeded keypair
> >>> generation (but this is not the case for Mono).
> >>>
> >>>> pablo
> >>>>
> >>>>
> >>>>
> >>>> >>
> >>>> >>
> >>>> >> 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
> >>>> >> >
> >>>> >>
> >>>> >
> >>>> > _______________________________________________
> >>>> > 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
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list 
> 