Using Thrift with C++

The Thrift C++ libraries are built using the GNU tools. Follow the instructions in the top-level

In case you do not want to open another file, do this thrift src:

./configure (--with-boost=/usr/local)
sudo make install

Thrift is divided into two libraries.

Linking Against Thrift

After you build and install Thrift the libraries are installed to /usr/local/lib by default. Make sure this is in your LDPATH.

On Linux, the best way to do this is to ensure that /usr/local/lib is in your /etc/ and then run /sbin/ldconfig.

Depending upon whether you are linking dynamically or statically and how your build environment it set up, you may need to include additional libraries when linking against thrift, such as librt and/or libpthread. If you are using libthriftnb you will also need libevent.


If your C++ environment implements C++11 or later, thrift will automatically use std::shared_ptr. Otherwise you will need the boost library to provide a shared_ptr implementation for C++ environments pre-C++11. If you are linking against code that expects to be using boost::shared_ptr, you can define the preprocessor variable FORCE_BOOST_SMART_PTR for your build of thrift to make it use boost instead of std for a number of memory related classes. See thrift/stdcxx.h for more.

libevent (for libthriftnb only)

Using Thrift with C++ on Windows

Both the autoconf and cmake build systems are able to automatically detect many system configurations without the need to specify library locations, however if you run into problems or want to redirect thrift to build and link against your own provided third party libraries:

BOOST_ROOT : For boost, e.g. D:\boost_1_55_0 OPENSSL_ROOT_DIR : For OpenSSL, e.g. D:\OpenSSL-Win32

only required by libthriftnb:

LIBEVENT_ROOT_DIR : For Libevent e.g. D:\libevent-2.0.21-stable

See /3rdparty.user for more details.

The same linking guidelines described above for libthriftnb apply to windows as well.

Linking Against Thrift

You need to link your project that uses thrift against all the thrift dependencies; in the case of libthrift, boost and for libthriftnb, libevent.

In the project properties you must also set HAVE_CONFIG_H as force include the config header: "windows/confg.h"


The same dependencies for shared_ptr as described above apply to windows as well.

boost thread

libevent (for libthriftnb only)

Notes on boost thread (static vs shared):

By default lib/cpp/windows/force_inc.h defines:

#define BOOST_ALL_NO_LIB 1

This has for effect to have the host application linking against Thrift to have to link with boost thread as a static library.

If you wanted instead to link with boost thread as a shared library, you'll need to uncomment those two lines, and recompile.

Windows version compatibility

The Thrift library targets Windows XP for broadest compatbility. A notable difference is in the Windows-specific implementation of the socket poll function. To target Vista, Win7 or other versions, comment out the line

#define TARGET_WIN_XP.

Named Pipes

Named Pipe transport has been added in the TPipe and TPipeServer classes. This is currently Windows-only. Named pipe transport for NIX has not been implemented. Domain sockets are a better choice for local IPC under non-Windows OS's. NIX named pipes only support 1:1 client-server connection.



This SSL only supports blocking mode socket I/O. It can only be used with TSimpleServer, TThreadedServer, and TThreadPoolServer.


There're two main classes TSSLSocketFactory and TSSLSocket. Instances of TSSLSocket are always created from TSSLSocketFactory.

PosixSSLThreadFactory creates PosixSSLThread. The only difference from the PthreadThread type is that it cleanups OpenSSL error queue upon exiting the thread. Ideally, OpenSSL APIs should only be called from PosixSSLThread.

How to use SSL APIs

This is for demo. In real code, typically only one TSSLSocketFactory instance is needed.

shared_ptr<TSSLSocketFactory> getSSLSocketFactory() {
  shared_ptr<TSSLSocketFactory> factory(new TSSLSocketFactory());
  // client: load trusted certificates
  // client: optionally set your own access manager, otherwise,
  //         the default client access manager will be loaded.

  // server: optionally setup access manager
  // shared_ptr<AccessManager> accessManager(new MyAccessManager);
  // factory->access(accessManager);

client code sample

shared_ptr<TSSLSocketFactory> factory = getSSLSocketFactory();
shared_ptr<TSocket> socket = factory.createSocket(host, port);
shared_ptr<TBufferedTransport> transport(new TBufferedTransport(socket));

server code sample

shared_ptr<TSSLSocketFactory> factory = getSSLSocketFactory();
shared_ptr<TSSLServerSocket> socket(new TSSLServerSocket(port, factory));
shared_ptr<TTransportFactory> transportFactory(new TBufferedTransportFactory));


AccessManager defines a callback interface. It has three callback methods:

(a) Decision verify(const sockaddr_storage& sa);

(b) Decision verify(const string& host, const char* name, int size);

(c) Decision verify(const sockaddr_storage& sa, const char* data, int size);

After SSL handshake completes, additional checks are conducted. Application is given the chance to decide whether or not to continue the conversation with the remote. Application is queried through the above three "verify" method. They are called at different points of the verification process.

Decisions can be one of ALLOW, DENY, and SKIP. ALLOW and DENY means the conversation should be continued or disconnected, respectively. ALLOW and DENY decision stops the verification process. SKIP means there's no decision based on the given input, continue the verification process.

First, (a) is called with the remote IP. It is called once at the beginning. "sa" is the IP address of the remote peer.

Then, the certificate of remote peer is loaded. SubjectAltName extensions are extracted and sent to application for verification. When a DNS subjectAltName field is extracted, (b) is called. When an IP subjectAltName field is extracted, (c) is called.

The "host" in (b) is the value from TSocket::getHost() if this is a client side socket, or TSocket::getPeerHost() if this is a server side socket. The reason is client side socket initiates the connection. TSocket::getHost() is the remote host name. On server side, the remote host name is unknown unless it's retrieved through TSocket::getPeerHost(). Either way, "host" should be the remote host name. Keep in mind, if TSocket::getPeerHost() failed, it would return the remote host name in numeric format.

If all subjectAltName extensions were "skipped", the common name field would be checked. It is sent to application through (c), where "sa" is the remote IP address. "data" is the IP address extracted from subjectAltName IP extension, and "size" is the length of the extension data.

If any of the above "verify" methods returned a decision ALLOW or DENY, the verification process would be stopped.

If any of the above "verify" methods returned SKIP, that decision would be ignored and the verification process would move on till the last item is examined. At that point, if there's still no decision, the connection is terminated.

Thread safety, an access manager should not store state information if it's to be used by many SSL sockets.

SIGPIPE signal

Applications running OpenSSL over network connections may crash if SIGPIPE is not ignored. This happens when they receive a connection reset by remote peer exception, which somehow triggers a SIGPIPE signal. If not handled, this signal would kill the application.

How to run test client/server in SSL mode

The server and client expects the followings from the directory /test/

The file names are hard coded in the source code. You need to create these certificates before you can run the test code in SSL mode. Make sure at least one of the followings is included in "keys/server.crt",

Run within /test/ folder,

     ./cpp/TestServer --ssl &
     ./cpp/TestClient --ssl

If "-h " is used to run client, the above "localhost" in the above keys/server.crt has to be replaced with that host name.


The default implementation of OpenSSLSocketFactory::randomize() simply calls OpenSSL's RAND_poll() when OpenSSL library is first initialized.

The PRNG seed is key to the application security. This method should be overridden if it's not strong enough for you.

Breaking Changes


Older versions of thrift depended on the classes which were used in thrift headers to define interfaces. Thrift now detects C++11 at build time and will prefer to use classes from C++11 instead. You can force the library to build with boost memory classes by defining the preprocessor macro FORCE_BOOST_SMART_PTR. (THRIFT-2221)

In the pthread mutex implementation, the contention profiling code was enabled by default in all builds. This changed to be disabled by default. (THRIFT-4151)

In older releases, if a TSSLSocketFactory's lifetime was not at least as long as the TSSLSockets it created, we silently reverted openssl to unsafe multithread behavior and so the results were undefined. Changes were made in 0.11.0 that cause either an assertion or a core instead of undefined behavior. The lifetime of a TSSLSocketFactory must be longer than any TSSLSocket that it creates, otherwise openssl will be cleaned up too early. If the static boolean is set to disable openssl initialization and cleanup and leave it up to the consuming application, this requirement is not needed. (THRIFT-4164)