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

[Harry Holt]

Thanks for this patch - I'm going to try some testing on my own project.

I am unable to compile this, though, as I am getting CLS-compliance
errors.  The Assembly is marked as compliant but the SslStreamBase
class includes a "read" object and a "Read" method (differing only in
case).

Is it just me?  I'm using VS 2003 to compile - maybe mcs doesn't check
for compliance?

Thx... HH

On 8/25/05, Sebastien Pouliot <sebastien at ximian.com> wrote:
> 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
> synchronous).
> 
> > 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
> conditions.
> 
> 4. Commit (both the patch and your SocketHell tests). Hopefully we can
> do all this before the next release.
> 
> Many thanks!
> --
> Sebastien
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>