You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Tomas Restrepo <to...@devdeo.com> on 2007/02/28 16:12:20 UTC

.NET client SSL Patch, Mono

I've been working on the SSL support for the .NET Client and I've now got a
working implementation based on Mentalis.org's library. I had to do some
changes to my original idea of how I wanted to implement it because of the
libraries design, but it seems to work fine, nonetheless.

As part of the patch I did a pretty big refactoring of the core IO/Transport
system in the .NET client, which, among other things, finally introduces
proper Async-IO capabilities to the it (and not just simply non-blocking
socket operations). That said, currently I have the code so that only Reads
are async, while writes remain sync (reason for this is that there *seems*
to be a bug in the Mentalis libraries that causes it to throw arbitrary
IOExceptions when both async reads and writes are done concurrently... with
SSL support disabled all async operations work fine).

What I'd like to do now is ask if someone would mind spending some time
testing the patch, to see if it's ready before official submittion. Any
takers?

While on the topic, I've been running Mono's Migration Analyzer
(http://www.mono-project.com/MoMA) on the project and the results look
pretty promising (though I haven't actually run anything on mono yet). We do
need to resync all mono-develop project files so that they are up to date
with all the other patches, as they've fallen somewhat out of date (finding
a single build-script would be even better).

However, I did notice that, unfortunately, the Mentalis library won't
probably run under mono because it relies on several OS-specific P/Invoke
calls and a few methods not yet fully implemented in mono. However, I've
factored the code in such a way that the Mentalis library is never used if
you don't try to connect using SSL, so we should still be up pretty good for
the normal, non-ssl, case.

P.S: I'm not posting the patch to JIRA yet mostly because I haven't found a
good way of packing it, seeing how it includes binary files and all, making
a simple .diff file not enough).


Tomas Restrepo
tomas.restrepo@devdeo.com
http://www.winterdom.com/weblog/