Interesting things with openSSL programing.

    It's not hard to find a OpenSSL programming tutorial or some example code on the internet, but there are some interesting detail that is not mentioned in most of the articles online.
    A while ago, I was involved in a new project that gave me the chance to play with libSSL for a while, I did read some tutorials and studied some examples on the Internet; but when I was testing the actual source code, I found out that It was quite unstable; the software that I wrote acts unexpectedly as if It has its own mind and wound crash due to segmentation faults or memory violations unpredictably.
    After tracing the actual source code of the OpenSSL library, I figured out a few interesting things that I would like to share.

1.  OpenSSL library could be build without multi-thread support; since most commercial software products are designed with multi-thread, please be sure to check if the library that you're using is build with multi-thread enabled.
2. Even if you have enabled the multi-thread support, OpenSSL library is not thread safe right outside of the box, you have to implement two operations:
1. first is a function that will return the current thread ID.
2. the second is a function that will handle the mutex lock and unlock actuion.
3. the two operation functions mentioned in the previous section should be introduced  to the OpenSSL library by using some provided APIs like:
• CRYPTO_set_id_callback
• CRYPTO_set_locking_callback

if you are looking for a example code you can download the openssl source code and checkout the demo code (crypto/threads/mttest.c), which comes with the  source.

Speeding up TCP connection lost detection in a TCP client application

When we're writing a TCP server, it is very easy to detect connection lost of a remote TCP peer by enabling "TCP keep alive";with this feature enabled, when no data is actually transmitting on the present TCP connection, a "tcp-keep-alive" is sent and a "ack" return from the remote peer is required.
If there is no "ack" after several retries, the connection is  determined as "lost" by the OS.
When connection lost is detected, the system(Linux) will signal you by returning "read data ready" on the "select()" function, but returning a zero length data on "read()".
But, when we're writing a TCP client, the tricky part is: as a client, 90% of the time we always have data to send, so when the connection is lost, the TCP stack automatically retransmits the data; as a result, before "tcp-retransmit" actually timeouts, the "tcp-kee-alive" mechanism will not kick in.
Thus, if you are looking for a way to speed up "TCP connection lost" detection efficiency  in a client application, this "keep alive" mechanism  will do you no good.
A possible approach is to use "ioctl(socket , SIOCOUTQ, &BufferUsedSize)" to return the actual data size that is still waiting in the send queue, if no data has been successfully sent for a certain period of time, than the connection is possibly lost.

reference:
man 7 tcp