Amit Ben Shahar wrote:
The .Net.Security.SslStream is not working in asynchronous calls,
meaning we'd have to implement it in a thread-per-connection paradigm,
which is obviously not an option.
Why 'obviously'? You might be surprised by how many threads can be
managed by Windows before it all falls down, especially if you can build
for 64 bit. You can't expect to support an enormous number of
concurrently communicating SSL connections with an event-based system
either. I certainly accept that its desirable to have C10k support.
You always have the option of placing OpenSSL in a coprocess and talking
to it with a message interface over mapped memory. Or you could
investigate rolling your own with the kit available from
System.Security.Cryptography.
2) Why can't you 'compile with the applink.c file'? You need a
talk to it through p/invoke - you may need to write another glue
DLL to do this. If you can locate an OpenSSL implementation that
has been wrapped as a free-threaded COM service, you might find
things easier if you don't know how to write such glue. You could
try looking in Mono's runtime, too, which I suspect delegates to
OpenSsl (tho I haven't checked).
As far as i understood it, openSsl looks for the applink
implementation in the actual application and not in dlls, but i could
have misread that, anyhow i'm not sure i would know how to do that,
can you maybe directly to such an implmentation (free-threaded COM) ?
Why do you think applink support can't be in a DLL? From the look of
what it does, you might need to create additional bridging between it
and your .net code for good integration. Its trying to use C library
functions but none of them look like they aren't available with the DLL
C runtime - though its likely that some of them won't do quite what you
might expect in a non-console application. The important bit seems to be
that applink should be accessing the application's choice of C runtime
version in the case where you are wanting to mix and the openssl dll
wasn't compiled against the same one. Since you can see which runtime
is being used by the .Net runtime, that shouldn't be too hard.
I suspect that you are going to have to write some C or C++ bridging
code. How comfortable are you with that? Microsoft's Managed C++
should be able to help, but you'll give up any likelihood of running on
Mono in that case, while a coprocess with a messaging interface - which
has extra copying costs - can isolate you entirely and a portable
coprocess (or coprocesses - you can mux sessions across several) can be
quite a portable solution.
You are trying to use a C library - you can expect to need C/C++ skills
for this to work well.
- in the meantime i'll try checking in Mono, though i've never ever
looked at it yet. maybe i'll get lucky ;)
thanks
You could also try this: http://openssl-net.sourceforge.net/
I have no idea how well it works - I just stumbled across it.
James
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
