[prev in list] [next in list] [prev in thread] [next in thread]
List: mono-devel-list
Subject: Re: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored Ssl
From: Harry Holt <harryholt () gmail ! com>
Date: 2005-08-31 13:12:07
Message-ID: 7c8072a005083106124789c104 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@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
[Attachment #5 (text/html)]
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.<br>
<br>
Won't this:<br>
if (workthreads >= \
(maxworkthreads - 4))<br> \
{<br> \
async = false;<br> }<br>
cause the SSL Stream to use synchronous handshake until threads start getting \
used?<br> <br>
I would also recommend changing this:<br>
protected void checkDisposed()<br>
{<br>
if (this.disposed)<br>
{<br>
throw new ObjectDisposedException("The Stream is
closed.");<br>
}<br>
}<br>
<br>
to this:<br>
protected void checkDisposed()<br>
{<br>
if (this.disposed)<br>
{<br>
throw new
ObjectDisposedException(this.GetType().Name, "The Stream is closed.");<br>
}<br>
}<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> <<a \
href="mailto:sebastien@ximian.com">sebastien@ximian.com</a>> \
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>> I took the plunge and fully \
implemented async Ssl streams for both<br>> client and server. This \
fixes<br>> <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>> \
I've been talking with Sebastien and Carlos about off list. This patch<br>> passes \
the SocketHell tests that I contributed to them last week <br>> (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>> It's also a bit of a re-factor, though \
I only touched two classes and <br>> added one. I pulled most of the \
code out of the individual<br>> SslClientStream and SslServerStream and moved it \
down into a new<br>> abstract SslStreamBase. Client and server are now \
practically the<br>> same implementation. I left all existing \
interfaces present, but <br>> obviously had to add some new ones.<br><br>We always \
"sticked" 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>> The only "gotcha" is if you start running \
low on threadpool threads. <br>> Then the Ssl Stream will fall back to a \
synchronous handshake. The<br>> other option here is to spawn a thread ourselves \
for the handshake<br>> instead of using Delegate.BeginInvoke(), use the IO \
ThreadPool (is <br>> that available to Mono.Security?), or just live with a \
synchronous<br>> handshake. Of course, 99.999% of the time this issue won't occur \
and<br>> won't be a problem unless you have both client and server sharing the \
<br>> same Threadpool causing a deadlock.<br><br>That's not worse than the \
original (where the handshake was always<br>synchronous).<br><br>> I hope this \
helps and gets integrated. It's definitely necessary for<br> > 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>"Only YOU can prevent gray goo<br>(NEVER release nanobot assemblers \
without replication limiting code)" <br><a \
href="http://lizardslounge.org">http://lizardslounge.org</a><br>
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]