Hi,
I'm planning to use stunnel to do stress testing of my application. I decided to use stunnel because I've noticed that full-duplex has been added to version 3.2 (around 1999) and my application handles high throughput. AFAIK Stunnel uses openssl. Also I know that openssl doesn't handle fullduplex traffic very well. In fact without any tricks, half-duplex is most what I could get from openssl. As the full-duplex feature has been added to stunnel in 1999 (so long time ago) can you confirm that it is still there and full-duplex is still supported? If it is a case, how it is possible that stunnel handles fullduplex?
Krzysztof Kwiatkowski
On 2013-09-05 17:50, Krzysztof Kwiatkowski wrote:
I'm planning to use stunnel to do stress testing of my application. I decided to use stunnel because I've noticed that full-duplex has been added to version 3.2 (around 1999) and my application handles high throughput. AFAIK Stunnel uses openssl. Also I know that openssl doesn't handle fullduplex traffic very well. In fact without any tricks, half-duplex is most what I could get from openssl. As the full-duplex feature has been added to stunnel in 1999 (so long time ago) can you confirm that it is still there and full-duplex is still supported? If it is a case, how it is possible that stunnel handles fullduplex?
Well... It depends on how you define "tricks". Doing full duplex data transfer was definitely nontrivial. Handling of half-closed connections was was even harder. My solution boils down to a state machine implemented with asynchronous handling of read/write/close events using non-blocking sockets. All the details you need are within the transfer() function in the src/client.c file.
Mike
-
Krzysztof Kwiatkowski -
Michal Trojnara