This seems to work fine on W2k.  Running under IIS5.1 on WXP,
though, it always throws an "ObjectDisposedException" in
&quot;SSLStreamBase.cs&quot; when a bind over SSL is attempted.<br>
<br>
Won't this:<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if (workthreads &gt;= (maxworkthreads - 4))<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; async = false;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
cause the SSL Stream to use synchronous handshake until threads start getting used?<br>
<br>
I would also recommend changing this:<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; protected void checkDisposed()<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if (this.disposed)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; throw new ObjectDisposedException(&quot;The Stream is
closed.&quot;);<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
<br>
to this:<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; protected void checkDisposed()<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if (this.disposed)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; throw new
ObjectDisposedException(this.GetType().Name, &quot;The Stream is closed.&quot;);<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
which produces a more readable error message.<br>
<br>
Thx... HH<br><br><div><span class="gmail_quote">On 8/25/05, <b class="gmail_sendername">Sebastien Pouliot</b> &lt;<a href="mailto:sebastien@ximian.com">sebastien@ximian.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello JD,<br><br>On Wed, 2005-24-08 at 21:12 -0700, JD Conley wrote:<br>&gt; I took the plunge and fully implemented async Ssl streams for both<br>&gt; client and server.&nbsp;&nbsp;This fixes<br>&gt; <a href="http://bugzilla.ximian.com/show_bug.cgi?id=75687">
http://bugzilla.ximian.com/show_bug.cgi?id=75687</a> as well as other bugs<br>&gt; I've been talking with Sebastien and Carlos about off list. This patch<br>&gt; passes the SocketHell tests that I contributed to them last week
<br>&gt; (multi threaded concurrent async streaming through TCP sockets).<br><br>Wow! That's the kind of surprise I like when I wake up :-)<br><br>&gt; It's also a bit of a re-factor, though I only touched two classes and
<br>&gt; added one.&nbsp;&nbsp;I pulled most of the code out of the individual<br>&gt; SslClientStream and SslServerStream and moved it down into a new<br>&gt; abstract SslStreamBase.&nbsp;&nbsp;Client and server are now practically the<br>&gt; same implementation.&nbsp;&nbsp;I left all existing interfaces present, but
<br>&gt; obviously had to add some new ones.<br><br>We always &quot;sticked&quot; to the Fx 1.2 preview specs for the Ssl[Client|<br>Server]Stream API and didn't planned to change this before implementing<br>the new SslStream (in 
System.dll) for 2.0 - BUT this isn't a major<br>problem if it doesn't break binary compatibility (for current<br>applications linked with Mono.Security.dll).<br><br>&gt; The only &quot;gotcha&quot; is if you start running low on threadpool threads.
<br>&gt; Then the Ssl Stream will fall back to a synchronous handshake. The<br>&gt; other option here is to spawn a thread ourselves for the handshake<br>&gt; instead of using Delegate.BeginInvoke(), use the IO ThreadPool (is
<br>&gt; that available to Mono.Security?), or just live with a synchronous<br>&gt; handshake. Of course, 99.999% of the time this issue won't occur and<br>&gt; won't be a problem unless you have both client and server sharing the
<br>&gt; same Threadpool causing a deadlock.<br><br>That's not worse than the original (where the handshake was always<br>synchronous).<br><br>&gt; I hope this helps and gets integrated.&nbsp;&nbsp;It's definitely necessary for<br>
&gt; our implementation.<br><br>1. I'll review the patch and, in doing so, check for possible binary<br>compatibility problems. I'm sure Carlos will do likewise;<br><br>2. I'll make public a new Mono.Security.dll assembly so that people that
<br>depends on Ssl*Stream may tests it and report any problem/difference;<br><br>3. I'll run the regressions tests, the tools under /mcs/class/<br>Mono.Security/Test/tools/*, to see if it works in previously reported<br>conditions.
<br><br>4. Commit (both the patch and your SocketHell tests). Hopefully we can<br>do all this before the next release.<br><br>Many thanks!<br>--<br>Sebastien<br><br>_______________________________________________<br>Mono-devel-list mailing list
<br><a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br><a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a>
<br></blockquote></div><br><br clear="all"><br>-- <br>====================================================<br>Robbie the Nanobot says:<br>&quot;Only YOU can prevent gray goo<br>(NEVER release nanobot assemblers without replication limiting code)&quot;
<br><a href="http://lizardslounge.org">http://lizardslounge.org</a><br>