> >> 3. Because stunnel is (as far as I can tell) a fork-model
> >> application, I am not yet confident it will have the performance
> >> necessary to support the volume of traffic we expect.
>
> > Stunnel uses threads instead of processes if possible.
> > Belibe me, anyway, that thread overhead is very small
> > compared to cryptographic overhead.
>
> Multi-threading makes the server's session cache useable, whereas
> forking applications have to provide some caching callbacks to benefit
> from sessions. So the main use of multi-threading is actually to
> avoid cryptographic overhead.
I am extremely pleased to note, on this topic, that on reading that
stunnel could thread, I compiled it, threads enabled, and it is working
very well indeed, in fact, I believe the performance is better than I had
hoped. It appears that whatever the bug was, it has for some reason,
possibly because its involved somehow in the forking support, gone now,
and the program has been running flawlessly since. I have sent further
information to Michael, and will put aside some time after our project
launch to hunt down the bug in the code.
Richard
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]