Networking always played a vital role in software industry. We are now in a situation where we cannot live without integrating some kind of network stack into modern softwares. Why is it so important? Because nowadays data no longer resides locally on individual systems rather is being stored on remote sites for which we name it as cloud storage. Nobody cares about the location where it is kept. They just need to get the data whenever they ask for it and no matter where it is stored. This retrieval of data from those data centres and presenting them to users involves the networking layer i.e, client requests the data and server serves it. But how many of us have thought above the implementation of such client-server softwares and their subsequent validation? As we all know, such software products will have to undergo thorough round of testing procedures to make it foolproof. Here comes the importance of socket_wrapper project.

Pre-loading and socket_wrapper
It is a FOSS project aimed at helping the functional test coverage for client-server network stack passing all socket communications using unix domain sockets. As the name suggests it is a wrapper around almost all socket related network calls issued in a client-server model. A wrapper must do something extra than defined. Apart from standard socket library tasks, how come socket_wrapper is able to do this extra work is the question and the answer is the pre-loading technique.

It is commonly used whenever you want to implement a customized version of a particular library call. The concept is as simple as intercepting the actual call before it hits the standard implementation all the way down. This technique is derived from the existing functioning model for Dynamic linker where it loads and links the required shared libraries at run time. On Unix-like systems that uses ELF for dynamic library linking offers a modified way of defining LD_PRELOAD and LD_LIBRARY_PATH environment variables which can adjust the search location for shared libraries during run time. Thus a customized version of a particular library function can be invoked prior to the actual call to its standard implementation and thereby achieves the task of a wrapper in all forms. The real advantage of writing such wrappers is that we can keep track of more context of what’s happening in addition to the standard procedures.

You can think of socket_wrapper as a bundle of such customized versions of socket library functions which can thus be pre-loaded and consumed easily during functional testing of a client-server software. Now let’s see what extra work socket_wrapper is doing as a wrapper. For better understanding I would like you to read a little bit on communication domains and protocols in socket programming as a pre-requisite. Internet is a network of computer networks. Although various inter-networking protocols exists, TCP/IP has become the dominant protocol among them. Even though these kind of softwares require communication using TCP/IP between processes on different hosts it would be way more easier if we could simulate such communications on a single host as if they reside on different machines. Here comes the importance of Unix domain sockets. It allows communication between processes on the same host system.

socket_wrapper redirects all communications happening via IPv4/IPv6 sockets and emulate those using traditional unix domain sockets. This extra work involves creation of sockets by translating IP addresses to a special name and look for it in a pre-defined location whenever server opens a port or a client wants to connect in a networking stack. The whole of socket_wrapper code base maintains this extra information in two basic structures namely, socket_info and socket_info_fd. It also make use of some pre-defined environment variables for specifying the location for creation of sockets, the default interface IP to be used and so on. Additionally we can analyze the traffic between client and server using this nice feature of socket_wrapper to dump all network traffic to a specified file. This is very helpful in debugging issues encountered while validating the software.

The role of socket_wrapper is very significant in running the self-test suite designed for the Samba project, which is a unix level implementation of SMB protocol for standard interoperability with Windows. Thus samba project is a heavy consumer of socket_wrapper. Apart from samba, there are many others who relies on this project to test their client-server software. Besides socket_wrapper, there are other wrappers like nss_wrapper, uid_wrapper, resolv_wrapper and pam_wrapper which are all under the parent project named cwrap.

Improvements to the project
There is always an opportunity in every project to make improvements to current code base so as to support more features. socket_wrapper is not so different. But when it comes to socket_wrapper thread safety is always a question. Hm.. But not any more. Chances are very high that the next release of socket_wrapper(may happen soon) will get this support added so that multi-threaded softwares can safely pre-load libsocket_wrapper.so and operate without any trouble.

Making socket_wrapper thread safe is also a requirement for implementing the concept of fd-passing within it. Some of you might think: “Isn’t this support already available with unix domain sockets?”. The answer is Yes in general(See my previous article on fd-passing). But it is not as easy as we think to enforce such a concept into socket_wrapper. Why? Because socket_wrapper maintains every other information to a TCP/IP socket connection in addition to establishing an underlying connection using unix domain sockets. We cannot just merely pass the relevant socket file descriptor to the other process and be done with it. The file descriptor as well as the whole TCP/IP socket meta data will have to be received at the other end. Then only further communications can be continued smoothly. There are designs already put up which roughly explain on how this can be achieved after socket_wrapper becomes thread safe. We can expect this support also to land in upcoming releases. fd-passing support within socket_wrapper also helps Samba project to make their self-test suite capable of running Multichannel(a feature from SMB protocol version 3) enabled tests in near future.

socket_wrapper is currently available in standard packaging formats from Debian, Fedora, OpenSUSE so that its easy to install for anyone who would like to give a shot on it. Please do visit the project home page and grab further configuration details from manual page.