On Sat, Apr 24, 2010 at 18:29, James Mansion <ja...@mansionfamily.plus.com>wrote:
> 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. The memory usage alone has a huge impact on the machine, from load tests we see about 4MB usage per thread, and that's a huge incline, there's probably an option to change the created stack sizes though i didn't look into it yet. In my expected scenarios i'm expecting to have many idle connections at any time, so i don't see any problem aiming (at least) at c10k. The co-process idea is good, see my comment below. > >> 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. I have reasonable c/++ skills, no problem there :) But i find myself a little clueless about how to do the 'bridging' you are referring to, though it seems to be the simplest solution. Feels that a coprocess management will take much more work and debugging (more processes, IPC, safety etc.), i'd like to keep it simple if possible with a small dll bridging the gap. can you point out the way or maybe give a sample of how such a brige would be built ? > - 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. It was the first thing i checked - they also go the (*two!) threads per connection route - and it doesn't work too well, at least for me, i ran into some issues with it and it's also much too cluttered for my taste.* *regarding this issue, i checked it out and there isn't any reference in it to the applink problem, i'm pretty sure it has the same issue (it took me some load testing to reproduce it on our project so they probably haven't gotten around to face it)* Thank! Amit.
