[Mono-dev] SSL Channel implementation and SslServerStream

pablosantosluac pablosantosluac at terra.es
Tue Dec 18 08:27:14 EST 2007 

Thanks Sebastien,

Yes, I'm currently doing so: each test starts a single connection first, 
then it starts launching threads!

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 2:30 PM
Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream


> 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
>>
>

More information about the Mono-devel-list mailing list