[Mono-dev] SSL Channel implementation and SslServerStream

pablosantosluac pablosantosluac at terra.es
Mon Dec 17 15:47:13 EST 2007


Hi again,


Well, the line which is actually consuming 50% of the time is
new MonoX509.X509Certificate(serverCertificate.GetRawCertData());

inside the ServerContext constructor.



Of course it is related to the RSA calculation inside the MonoX509 
certificate. I guess it could be catched 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).



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
> 




More information about the Mono-devel-list mailing list