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

[JD Conley]

Harry,

 

The latest patch that I sent to the maintainers doesn't use the delegate
BeginInvoke any more. It uses an asynchronous BeginRead or BeginWrite
call to the innerStream to kick off the handshake in a background
thread.

 

-JD Conley

 

________________________________

From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Harry
Holt
Sent: Wednesday, August 31, 2005 6:12 AM
To: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored
SslStreams in Mono.Security

 

This seems to work fine on W2k.  Running under IIS5.1 on WXP, though, it
always throws an "ObjectDisposedException" in "SSLStreamBase.cs" when a
bind over SSL is attempted.

Won't this:
            if (workthreads >= (maxworkthreads - 4))
            {
                async = false;
            }
cause the SSL Stream to use synchronous handshake until threads start
getting used?

I would also recommend changing this:
        protected void checkDisposed()
        {
            if (this.disposed)
            {
                throw new ObjectDisposedException("The Stream is
closed.");
            }
        }

to this:
        protected void checkDisposed()
        {
            if (this.disposed)
            {
                throw new ObjectDisposedException(this.GetType().Name,
"The Stream is closed.");
            }
        }
which produces a more readable error message.

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 




-- 
====================================================
Robbie the Nanobot says:
"Only YOU can prevent gray goo
(NEVER release nanobot assemblers without replication limiting code)" 
http://lizardslounge.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050902/9c8160c8/attachment.html