[Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored Ssl Streams in Mono.Security

Sebastien Pouliot sebastien at ximian.com
Thu Aug 25 07:28:51 EDT 2005

Hello JD,

On Wed, 2005-24-08 at 21:12 -0700, JD Conley wrote:
> I took the plunge and fully implemented async Ssl streams for both
> client and server.  This fixes
> http://bugzilla.ximian.com/show_bug.cgi?id=75687 as well as other bugs
> I've been talking with Sebastien and Carlos about off list. This patch
> passes the SocketHell tests that I contributed to them last week
> (multi threaded concurrent async streaming through TCP sockets).

Wow! That's the kind of surprise I like when I wake up :-)

> It's also a bit of a re-factor, though I only touched two classes and
> added one.  I pulled most of the code out of the individual
> SslClientStream and SslServerStream and moved it down into a new
> abstract SslStreamBase.  Client and server are now practically the
> same implementation.  I left all existing interfaces present, but
> obviously had to add some new ones.

We always "sticked" to the Fx 1.2 preview specs for the Ssl[Client|
Server]Stream API and didn't planned to change this before implementing
the new SslStream (in System.dll) for 2.0 - BUT this isn't a major
problem if it doesn't break binary compatibility (for current
applications linked with Mono.Security.dll).

> The only "gotcha" is if you start running low on threadpool threads.
> Then the Ssl Stream will fall back to a synchronous handshake. The
> other option here is to spawn a thread ourselves for the handshake
> instead of using Delegate.BeginInvoke(), use the IO ThreadPool (is
> that available to Mono.Security?), or just live with a synchronous
> handshake. Of course, 99.999% of the time this issue won't occur and
> won't be a problem unless you have both client and server sharing the
> same Threadpool causing a deadlock.

That's not worse than the original (where the handshake was always

> I hope this helps and gets integrated.  It's definitely necessary for
> our implementation.

1. I'll review the patch and, in doing so, check for possible binary
compatibility problems. I'm sure Carlos will do likewise;

2. I'll make public a new Mono.Security.dll assembly so that people that
depends on Ssl*Stream may tests it and report any problem/difference;

3. I'll run the regressions tests, the tools under /mcs/class/
Mono.Security/Test/tools/*, to see if it works in previously reported

4. Commit (both the patch and your SocketHell tests). Hopefully we can
do all this before the next release.

Many thanks!

More information about the Mono-devel-list mailing list