Modern C++ socket library.

Overview

sockpp

Build Status

Simple, modern, C++ socket library.

This is a fairly low-level C++ wrapper around the Berkeley sockets library using socket, acceptor, and connector classes that are familiar concepts from other languages.

The base socket class wraps a system socket handle, and maintains its lifetime. When the C++ object goes out of scope, it closes the underlying socket handle. Socket objects are generally moveable but not copyable. A socket can be transferred from one scope (or thread) to another using std::move().

Currently supports: IPv4, IPv6, and Unix-Domain Sockets on Linux, Mac, and Windows. Other *nix and POSIX systems should work with little or no modification.

All code in the library lives within the sockpp C++ namespace.

Latest News

The library is reaching a stable API, and is on track for a 1.0 release in the near future. Until then, there may be a few more breaking changes, but hopefully those will be fewer than we have seen so far.

On that note, despite being recently refactored and re-versioned at 0.x, earlier implementations of this library have been in use on production systems since ~2003, particularly with remote embedded Linux data loggers. Things that we now call IoT gateways and edge devices. It can be counted on to be reliable.

To keep up with the latest announcements for this project, follow me at:

Twitter: @fmpagliughi

If you're using this library, tweet at me or send me a message, and let me know how you're using it. I'm always curious to see where it's wound up!

Unreleased Features in this Branch

The following updates exist in this branch in the repository, but have yet to be formally released:

  • [#37] socket::get_option() not returning length on Windows.
  • [#39] Using SSIZE_T for ssize_t in Windows
  • Now acceptor::open() uses the SO_REUSEPORT option instead of SO_REUSEADDR on non-Windows systenms. Also made reuse optional.

New in v0.7

This release mainly targeted bug fixes, API inconsistencies, and numerous small features that had been overlooked previously.

  • Base socket class
    • shutdown() added
    • create() added
    • bind() moved into base socket (from acceptor)
  • Unix-domain socket pairs (stream and datagram)
  • Non-blocking I/O
  • Scatter/Gather I/O
  • stream_socket cloning.
  • Set and get socket options using template types.
  • stream_socket::read_n() and write_n() now properly handle EINTR return.
  • to_timeval() can convert from any std::chrono::duration type.
  • socket::close() and shutdown() check for errors, set last error, and return a bool.
  • tcpechomt.cpp: Example of a client sharing a socket between read and write threads - using clone().
  • Windows enhancements:
    • Implemented socket timeouts on Windows
    • Fixed bug in Windows socket cloning.
    • Fixed bug in Windows socket::last_error_string.
    • Unit tests working on Windows
  • More unit tests

Contributing

Contributions are accepted and appreciated. New and unstable work is done in the develop branch Please submit all pull requests against that branch, not master.

For more information, refer to: CONTRIBUTING.md

TODO

  • Unit Tests - The framework for unit and regression tests is in place (using Catch2), along with the GitHub Travis CI integration. But the library could use a lot more tests.
  • Consolidate Header Files - The last round of refactoring left a large number of header files with a single line of code in each. This may be OK, in that it separates all the protocols and families, but seems a waste of space.
  • Secure Sockets - It would be extremely handy to have support for SSL/TLS built right into the library as an optional feature.
  • SCTP - The SCTP protocol never caught on, but it seems intriguing, and might be nice to have in the library for experimentation, if not for some internal applications.

Building the Library

CMake is the supported build system.

Requirements:

  • A conforming C++-14 compiler.
    • gcc v5.0 or later (or) clang v3.8 or later.
    • Visual Studio 2015, or later on WIndows.
  • CMake v3.5 or newer.
  • Doxygen (optional) to generate API docs.
  • Catch2 (optional) to build and run unit tests.

Build like this on Linux:

$ cd sockpp
$ mkdir build ; cd build
$ cmake ..
$ make
$ sudo make install

Build Options

The library has several build options via CMake to choose between creating a static or shared (dynamic) library - or both. It also allows you to build the example options, and if Doxygen is

Variable Default Value Description
SOCKPP_BUILD_SHARED ON Whether to build the shared library
SOCKPP_BUILD_STATIC OFF Whether to build the static library
SOCKPP_BUILD_DOCUMENTATION OFF Create and install the HTML based API documentation (requires Doxygen)
SOCKPP_BUILD_EXAMPLES OFF Build example programs
SOCKPP_BUILD_TESTS OFF Build the unit tests (requires Catch2)

TCP Sockets

TCP and other "streaming" network applications are usually set up as either servers or clients. An acceptor is used to create a TCP/streaming server. It binds an address and listens on a known port to accept incoming connections. When a connection is accepted, a new, streaming socket is created. That new socket can be handled directly or moved to a thread (or thread pool) for processing.

Conversely, to create a TCP client, a connector object is created and connected to a server at a known address (typically host and socket). When connected, the socket is a streaming one which can be used to read and write, directly.

For IPv4 the tcp_acceptor and tcp_connector classes are used to create servers and clients, respectively. These use the inet_address class to specify endpoint addresses composed of a 32-bit host address and a 16-bit port number.

TCP Server: tcp_acceptor

The tcp_acceptor is used to set up a server and listen for incoming connections.

int16_t port = 12345;
sockpp::tcp_acceptor acc(port);

if (!acc)
    report_error(acc.last_error_str());

// Accept a new client connection
sockpp::tcp_socket sock = acc.accept();

The acceptor normally sits in a loop accepting new connections, and passes them off to another process, thread, or thread pool to interact with the client. In standard C++, this could look like:

while (true) {
    // Accept a new client connection
    sockpp::tcp_socket sock = acc.accept();

    if (!sock) {
        cerr << "Error accepting incoming connection: "
            << acc.last_error_str() << endl;
    }
    else {
        // Create a thread and transfer the new stream to it.
        thread thr(run_echo, std::move(sock));
        thr.detach();
    }
}

The hazards of a thread-per-connection design is well documented, but the same technique can be used to pass the socket into a thread pool, if one is available.

See the tcpechosvr.cpp example.

TCP Client: tcp_connector

The TCP client is somewhat simpler in that a tcp_connector object is created and connected, then can be used to read and write data directly.

sockpp::tcp_connector conn;
int16_t port = 12345;

if (!conn.connect(sockpp::inet_address("localhost", port)))
    report_error(conn.last_error_str());

conn.write_n("Hello", 5);

char buf[16];
ssize_t n = conn.read(buf, sizeof(buf));

See the tcpecho.cpp example.

UDP Socket: udp_socket

UDP sockets can be used for connectionless communications:

sockpp::udp_socket sock;
sockpp::inet_address addr("localhost", 12345);

std::string msg("Hello there!");
sock.send_to(msg, addr);

sockpp::inet_address srcAddr;

char buf[16];
ssize_t n = sock.recv(buf, sizeof(buf), &srcAddr);

See the udpecho.cpp and udpechosvr.cpp examples.

IPv6

The same style of connectors and acceptors can be used for TCP connections over IPv6 using the classes:

inet6_address
tcp6_connector
tcp6_acceptor
tcp6_socket
udp6_socket

Examples are in the examples/tcp directory.

Unix Domain Sockets

The same is true for local connection on *nix systems that implement Unix Domain Sockets. For that use the classes:

unix_address
unix_connector
unix_acceptor
unix_socket  (unix_stream_socket)
unix_dgram_socket

Examples are in the examples/unix directory.

Implementation Details

The socket class hierarchy is built upon a base socket class. Most simple applications will probably not use socket directly, but rather use top-level classes defined for a specific address family like tcp_connector and tcp_acceptor.

The socket objects keep a handle to an underlying OS socket handle and a cached value for the last error that occurred for that socket. The socket handle is typically an integer file descriptor, with values >=0 for open sockets, and -1 for an unopened or invalid socket. The value used for unopened sockets is defined as a constant, INVALID_SOCKET, although it usually doesn't need to be tested directly, as the object itself will evaluate to false if it's uninitialized or in an error state. A typical error check would be like this:

tcp_connector conn({"localhost", 12345});

if (!conn)
    cerr << conn.last_error_str() << std::endl;

The default constructors for each of the socket classes do nothing, and simply set the underlying handle to INVALID_SOCKET. They do not create a socket object. The call to actively connect a connector object or open an acceptor object will create an underlying OS socket and then perform the requested operation.

An application can generally perform most low-level operations with the library. Unconnected and unbound sockets can be created with the static create() function in most of the classes, and then manually bind and listen on those sockets.

The socket::handle() method exposes the underlying OS handle which can then be sent to any platform API call that is not exposed by the library.

Thread Safety

A socket object is not thread-safe. Applications that want to have multiple threads reading from a socket or writing to a socket should use some form of serialization, such as a std::mutex to protect access.

A socket can be moved from one thread to another safely. This is a common pattern for a server which uses one thread to accept incoming connections and then passes off the new socket to another thread or thread pool for handling. This can be done like:

sockpp::tcp6_socket sock = acc.accept(&peer);

// Create a thread and transfer the new socket to it.
std::thread thr(handle_connection, std::move(sock));

In this case, handle_connection would be a function that takes a socket by value, like:

void handle_connection(sockpp::tcp6_socket sock) { ... }

Since a socket can not be copied, the only choice would be to move the socket to a function like this.

It is a common patern, especially in client applications, to have one thread to read from a socket and another thread to write to the socket. In this case the underlying socket handle can be considered thread safe (one read thread and one write thread). But even in this scenario, a sockpp::socket object is still not thread-safe due especially to the cached error value. The write thread might see an error that happened on the read thread and visa versa.

The solution for this case is to use the socket::clone() method to make a copy of the socket. This will use the system's dup() function or similar create another socket with a duplicated copy of the socket handle. This has the added benefit that each copy of the socket can maintain an independent lifetime. The underlying socket will not be closed until both objects go out of scope.

sockpp::tcp_connector conn({host, port});

auto rdSock = conn.clone();
std::thread rdThr(read_thread_func, std::move(rdSock));

The socket::shutdown() method can be used to communicate the intent to close the socket from one of these objects to the other without needing another thread signaling mechanism.

See the tcpechomt.cpp example.

Comments
  • Reasons for implementing `sock_address_ref`

    Reasons for implementing `sock_address_ref`

    First off, thanks for writing sockcpp! It's almost exactly what I was looking for in a modernized C++ sockets library.

    I've been digging through the code, and I'm confused about why you've preferred to implement and use sock_address_refover using C++ references to sock_address.

    opened by anrddh 17
  • Non-blocking I/O

    Non-blocking I/O

    It would be useful to support non-blocking I/O on sockets, and non-blocking connect and accept. This allows a lot more flexibility with threading, instead of having to devote one or two threads to every socket. It also seems like the only way to control the timeout of connect.

    I've implemented this and will try to put a PR together today.

    opened by snej 12
  • last_error property is not thread-safe

    last_error property is not thread-safe

    The implementation of the socket class's last_error property is not thread-safe. The error code is copied from errno into a member variable after a system call. However, the error really needs to be tracked per thread, as errno itself is.

    This is significant because it's not uncommon to have one thread writing to a socket and another thread reading from it — this is a typical way to implement WebSockets, for example. What can happen in this case is:

    1. Thread A calls write.
    2. The underlying send system call fails, and the error is copied from errno into the socket's lastErr_.
    3. Thread B calls read.
    4. The underlying recv system call succeeds, so lastErr_ is set to 0.
    5. Thread A sees that the write call returned -1, and calls get_last_error.
    6. get_last_error returns 0, not the actual error from the write.
    opened by snej 12
  • Get unit tests working on all platforms.

    Get unit tests working on all platforms.

    I was able to make it compile and run. The hardest part, actually, was fighting with CMake since Catch2 is not something I normally "install" since it's just one (or two) headers. Some CMake patching took care of that though, and the only thing left is the following issues (on Windows) in the unit tests causing 7 test and 8 assertion failures:

    • Incorrect assumption: Address information is available before socket connection (family type will remain unspecified, as opposed to the various checks for AF_INET)
    • Incorrect assumption: Windows uses POSIX error codes (e.g. sock.last_error() == EAFNOSUPPORT needs to be sock.last_error() == WSAEAFNOSUPPORT). Also, often these codes are WSAEINVAL or WSAENOTSOCK instead.
    • socket::pair not implemented for Windows, so its corresponding test fails
    • to_timeval is not implemented on Windows, causing compilation failures

    All of the above are pretty easily fixable though.

    EDIT OH I forgot, initialize() is never called during the tests so a lot of tests initially failed with the "not initialized" error. I fixed that by not auto generating the catch main function (GOTCHA: Include socket platform.h before catch.hpp to avoid odd errors from including headers in the wrong order)

    Originally posted by @borrrden in https://github.com/fpagliughi/sockpp/issues/25#issuecomment-530154552

    opened by fpagliughi 10
  • Doc-comment issues (Clang warnings with -Wdocumentation)

    Doc-comment issues (Clang warnings with -Wdocumentation)

    There are a number of glitches in the doc-comments, especially @param directives, like name mismatches and empty descriptions. They're flagged as warnings by Doxygen, and by Clang if -Wdocumentation is on.

    Not a big deal, except that the project I work on builds with -Wdocumentation -Werror (because it's a library with its own API and doc-comments), so when I include sockpp headers they break the build.

    I can work around this by wrapping all the includes with #pragma clang diagnostic push / ignored / pop, but it's a pain and it'd be nice if these were cleaned up along with the other header-file work that's acknowledged in the README :)

    opened by snej 5
  • Can this library be compiled for IOS?

    Can this library be compiled for IOS?

    I want to use CMake to compile this library for IOS, but I tried and got errors. Can I implement that? ` Creating symlinks /Applications/CMake.app/Contents/bin/cmake -E cmake_symlink_library /Users/wujiahang/Project/EdgeTileIOS/deps/build/sockpp/Release-iphoneos/libsockpp.0.7.0.dylib /Users/wujiahang/Project/EdgeTileIOS/deps/build/sockpp/Release-iphoneos/libsockpp.0.dylib /Users/wujiahang/Project/EdgeTileIOS/deps/build/sockpp/Release-iphoneos/libsockpp.dylib CMake Error: failed to create symbolic link '/Users/wujiahang/Project/EdgeTileIOS/deps/build/sockpp/Release-iphoneos/libsockpp.0.dylib': no such file or directory CMake Error: cmake_symlink_library: System Error: No such file or directory CMake Error: failed to create symbolic link '/Users/wujiahang/Project/EdgeTileIOS/deps/build/sockpp/Release-iphoneos/libsockpp.dylib': no such file or directory CMake Error: cmake_symlink_library: System Error: No such file or directory make: *** [sockpp_buildpart_0] Error 1

    ** BUILD FAILED ** `

    help wanted 
    opened by JiahangOK 4
  • Definition of ssize_t is wrong

    Definition of ssize_t is wrong

    sockpp has its own declaration of ssize_t in platform.h, but on non-Windows systems it defines it as int. ~~This is wrong on 64-bit OSs that use 32-bit ints, which includes all Apple platforms. (Dunno about Linux or BSD.) This leads to compile errors if a source file ends up including both platform.h and the OS's declaration. That aside, there are potentially actual integer overflow bugs if dealing with sizes > 4GB.~~

    https://github.com/fpagliughi/sockpp/blob/180f18d55b46fb6e8b6723a8dacc8f3733f1a47d/include/sockpp/platform.h#L78-L86

    You shouldn't need to declare this at all. Instead:

    • ~~On a POSIX-compliant OS, #include <sys/types.h>.~~
    • On Windows, #include <BaseTsd.h> and then using ssize_t = SSIZE_T;.

    (Also, it's kind of icky that the types declared in platform.h are all in the global namespace. Could they be put in the sockpp namespace like the rest of the API?)

    opened by snej 4
  • I cannot get examples to compile on linux

    I cannot get examples to compile on linux

    Using: g++ (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 Examples: tcp echo client /server and unix echo client/server. I consistently get errors with non- static reference made to run_echo(). when I comment out the call to run_echo(); I get undefined references `sockpp::inet_address::inet_address(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, unsigned short)':|

    opened by theisen1337 4
  • Does Windows support socket timeouts?

    Does Windows support socket timeouts?

    In the stream_socket class, the calls to read_timeout() and write_timeout() are empty for Windows. I can't remember if Windows doesn't support this, or if I was just too lazy to look up how.

    @borrrden Do you know?

    bool stream_socket::read_timeout(const microseconds& to)
    {
    	#if !defined(_WIN32)
    		timeval tv = to_timeval(to);
    		return set_option(SOL_SOCKET, SO_RCVTIMEO, tv);
    	#else
    		return false;
    	#endif
    }
    
    opened by fpagliughi 4
  • Made to_timeval work with any timescale

    Made to_timeval work with any timescale

    I have some code that needs to convert steady_clock durations to timeval, and that timescale is different from microseconds. So I trivially changed to_timeval() into a template.

    opened by snej 4
  • Fixed family for sockaddr for mac

    Fixed family for sockaddr for mac

    Signature of mac's kernel sockaddr is different:

    struct sockaddr {
    	__uint8_t	sa_len;		/* total length */
    	sa_family_t	sa_family;	/* [XSI] address family */
    	char		sa_data[14];	/* [XSI] addr value (actually larger) */
    };
    

    instead of

    struct sockaddr{
        sa_family_t   sa_family       address family
        char          sa_data[]       socket address (variable-length data)
    };
    

    like the code assumes.

    opened by desertkun 4
  • Linking on Windows with minGW-x64

    Linking on Windows with minGW-x64

    I was able to create a static library in both Windows and Linux (using ArchLinux) following the README. Two files were generated:

    • libsockpp.a for Linux
    • sockpp-static.lib for Windows

    Then I need to use the static library in another program, which is built using a Makefile. In Linux no issue occurs, while in Windows with minGW-x64 I received multiple errors like

    C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccvvpJbH.o:tcp6echo.cpp:(.text+0x176): undefined reference to `sockpp::operator<<(std::ostream&, sockpp::inet6_address const&)'
    

    To reproduce the issue with the example tcp6echo (assuming headers in ./include and static library in ./lib):

    • In Linux all works ok using g++ -I./include -o tcp6echo tcp6echo.cpp -L./lib -lsockpp
    • In Windows with minGW-x64 issue occurs using g++ -I./include -o tcp6echo tcp6echo.cpp -L./lib -l:sockpp-static.lib
    opened by stefphd 0
  • building with mingw32 g++ on Windows 10

    building with mingw32 g++ on Windows 10

    C:\For_CMake\source\sockpp-0.7.1\src\inet_address.cpp: In member function 'std::__cxx11::string sockpp::inet_address::to_string() const':
    C:\For_CMake\source\sockpp-0.7.1\src\inet_address.cpp:107:13: error: 'inet_ntop' was not declared in this scope
      auto str = inet_ntop(AF_INET, (void*) &(addr_.sin_addr), buf, INET_ADDRSTRLEN);
                 ^~~~~~~~~
    C:\For_CMake\source\sockpp-0.7.1\src\inet_address.cpp:107:13: note: suggested alternative: 'inet_ntoa'
      auto str = inet_ntop(AF_INET, (void*) &(addr_.sin_addr), buf, INET_ADDRSTRLEN);
                 ^~~~~~~~~
                 inet_ntoa
    C:\For_CMake\source\sockpp-0.7.1\src\inet_address.cpp: In function 'std::ostream& sockpp::operator<<(std::ostream&, const sockpp::inet_address&)':
    C:\For_CMake\source\sockpp-0.7.1\src\inet_address.cpp:117:13: error: 'inet_ntop' was not declared in this scope
      auto str = inet_ntop(AF_INET, (void*) &(addr.sockaddr_in_ptr()->sin_addr),
                 ^~~~~~~~~
    C:\For_CMake\source\sockpp-0.7.1\src\inet_address.cpp:117:13: note: suggested alternative: 'inet_ntoa'
      auto str = inet_ntop(AF_INET, (void*) &(addr.sockaddr_in_ptr()->sin_addr),
                 ^~~~~~~~~
                 inet_ntoa
    mingw32-make[2]: *** [src\CMakeFiles\sockpp-objs.dir\build.make:138: src/CMakeFiles/sockpp-objs.dir/inet_address.cpp.obj] Error 1
    mingw32-make[1]: *** [CMakeFiles\Makefile2:141: src/CMakeFiles/sockpp-objs.dir/all] Error 2
    mingw32-make: *** [Makefile:148: all] Error 2
    
    opened by quan787 1
  • Compile with MinGW-64 (G++)

    Compile with MinGW-64 (G++)

    Hi fpagliughi,

    Would you happen to know how to compile a sockpp included CPP file properly with G++? I've tried many including: g++ main.cpp -o main -I "sockpp/include/" -L "sockpp/build/Debug/sockpp-static.lib"

    Including both the path and the linker file location. The program compiles properly when I have the actual include statement (example: #include <sockpp/tcp_connector.h>) only - but when trying to add a TCP connector (example: sockpp::tcp_connector conn({"localhost", 12345});) - it fails to compile.

    opened by ryanwe1ss 3
  • socket.is_connected not working

    socket.is_connected not working

    Hi, I've been trying to check if my socket that I have connected to a server is active in which it obviously is because I am able to send data back and forth, but is there any way I can check because I've been trying to use "socket.is_connected()" but it seems to be returning the same value no matter if it is connected or not. Currently using TCP sockets.

    opened by ryanwe1ss 1
  • Receiving Data

    Receiving Data

    Hi, I'm just wondering but is there any mechanism in this repository that can simply be able to receive data from another endpoint without knowing the length of it and be able to receive it all properly? For example, if I send an image on the server side to the client, is there any way I can receive the full image which one simple line to store it all in an array without sending the length of the data first then the actual data?

    opened by ryanwe1ss 2
Releases(v0.7.1)
  • v0.7.1(Jan 24, 2022)

    This is a minor update to merge in a number of long-standing Pull Requests and other fixes. It also contains some new, experimental, support for SocketCAN on Linux.

    • [Experimental] SocketCAN, CAN bus support on Linux
    • #37 socket::get_option() not returning length on Windows
    • #39 Using SSIZE_T for ssize_t in Windows
    • #53 Add Conan support
    • #55 Fix Android strerror
    • #60 Add missing move constructor for connector template.
    • Now acceptor::open() uses the SO_REUSEPORT option instead of SO_REUSEADDR on non-Windows systems. Also made reuse optional.
    Source code(tar.gz)
    Source code(zip)
  • v0.7(Oct 6, 2019)

    Version 0.7

    • Base socket class
      • shutdown() added
      • create() added
      • bind() moved into base socket (from acceptor)
    • Unix-domain socket pairs (stream and datagram)
    • Non-blocking I/O
    • Scatter/Gather I/O
    • stream_socket cloning.
    • Set and get socket options using template types.
    • stream_socket::read_n() and write_n() now properly handle EINTR return.
    • to_timeval() can convert from any std::chrono::duration type.
    • socket::close() and shutdown() check for errors, set last error, and return a bool.
    • tcpechomt.cpp: Example of a client sharing a socket between read and write threads - using clone().
    • Windows enhancements:
      • Implemented socket timeouts on Windows
      • Fixed bug in Windows socket cloning.
      • Fixed bug in Windows socket::last_error_string.
      • Unit tests working on Windows
    • More unit tests
    Source code(tar.gz)
    Source code(zip)
  • v0.6(Aug 11, 2019)

    Added improved support for UDP, including implementation on Windows.

    • UDP support
      • The base datagram_socket added to the Windows build
      • The datagram_socket cleaned up for proper parameter and return types.
      • New datagram_socket_tmpl template class for defining UDP sockets for the different address families.
      • New datagram classes for IPv4 (udp_socket), IPv6 (udp6_socket), and Unix-domain (unix_dgram_socket)
    • Windows support
      • Windows support was broken in release v0.5. It is now fixed, and includes the UDP features.
    • Proper move semantics for stream sockets and connectors.
    • Separate tcp socket header files for each address family (tcp_socket.h, tcp6_socket.h, etc).
    • Proper implementation of Unix-domain streaming socket.
    • CMake auto-generates a version header file, version.h
    • CI dropped tests for gcc-4.9, and added support for clang-7 and 8.
    Source code(tar.gz)
    Source code(zip)
  • v0.5(Aug 6, 2019)

    Version 0.5 refactored the network address classes with an abstract base class and reduced redundant code with templates to create implementations for the different address families.

    • (Breaking change) Updated the hierarchy of network address classes, now derived from a common base class.
      • Removed sock_address_ref class. Now a C++ reference to sock_address will replace it (i.e. sock_address&).
      • sock_address is now an abstract base class.
      • All the network address classes now derive from sock_address
      • Consolidates a number of overloaded functions that took different forms of addresses to just take a const sock_address&
      • Adds a new sock_address_any class that can contain any address, and is used by base classes that need a generic address.
    • The acceptor and connector classes are still concrete, generic classes, but now a template derives from each of them to specialize.
    • The connector and acceptor classes for each address family (tcp_connector, tcp_acceptor, tcp6_connector, etc) are now typedef'ed to template specializations.
    • The acceptor::bind() and acceptor::listen() methods are now public.
    • CMake build now honors the CMAKE_BUILD_TYPE flag.
    Source code(tar.gz)
    Source code(zip)
  • v0.4(Jun 30, 2019)

    Version 0.4 added support for IPv6 and refactored the class hierarchies to better support the different address families without so much redundant code.

    • IPv6 support: inet6_address, tcp6_acceptor, tcp_connector, etc.
    • (Breaking change) The sock_address class is now contains storage for any type of address and follows copy semantics. Previously it was a non-owning reference class. That reference class now exists as sock_addresss_ref.
    • Generic base classses are being re-implemented to use sock_address and sock_address_ref as generic addresses.
    • (Breaking change) In the socket class(es) the bool address(address&) and bool peer_address(addr&) forms of getting the socket addresses have been removed in favor of the ones that simply return the address. Added get_option() and set_option() methods to the base socketclass.
    • The GNU Make build system (Makefile) was deprecated and removed.
    Source code(tar.gz)
    Source code(zip)
  • v0.3(Dec 3, 2018)

    Version 0.3 brings several new features:

    • Socket class hierarcy now splits out for streaming and datagram sockets.
    • Support for UNIX-domain sockets.
    • New modern CMake build system.
    • GNU Make system marked for deprecation.
    Source code(tar.gz)
    Source code(zip)
  • v0.2(Apr 9, 2017)

Owner
Frank Pagliughi
Embedded Rust / C++ Contractor for IoT, Industrial, and Medical. Author/Maintainer for Eclipse Paho MQTT.
Frank Pagliughi
Lightweight, header-only, Boost-based socket pool library

Stream-client This is a lightweight, header-only, Boost-based library providing client-side network primitives to easily organize and implement data t

Tinkoff.ru 12 Aug 5, 2022
A single-header socket library for both Linux and Windows

COMS What is COMS? COMS is a single-header library designed to be simple to use. It supports TCP and UDP, Server and Client. Available for Windows and

null 5 Dec 23, 2021
Socket and Networking Library using msgpack.org[C++11]

netLink C++ 11 KISS principle networking library. Features: C++ 11 IPv4, IPv6 Protocols: TCP, UDP Enable/Disable blocking mode Join/Leave UDP-Multicas

Alexander Meißner 208 Sep 9, 2022
Minimalistic socket library inspired by Asio/Boost Asio, implemented in 1 single header file

cz-spas czspas (Small Portable Asynchronous Sockets) is minimalistic socket library inspired by Asio/Boost Asio, implemented in 1 single header file.

Rui Figueira 25 Jun 12, 2022
Asynchronous, Header-only C++ HTTP-over-(TCP|UNIX Socket|STDIO) Library

CXXHTTP A C++ library implementing an asynchronous HTTP server and client. To clone this library, make sure you also clone the submodules. The --recur

null 25 Mar 19, 2021
C++11 implementation of Socket.IO client

By virtue of being written in C++, this client works in several different platforms. The examples folder contains an iPhone, QT and Console example chat client! It depends on websocket++ and is inspired by socket.io-clientpp.

Socket.IO 2k Sep 19, 2022
HP-Socket bindings for aardio

HP-Socket-bindings-for-aardio HP-Socket is a high performance network framework. aardio is an extremely easy-to-use dynamic language, but it is also a

null 9 Jan 3, 2022
Simple server and client using python socket and declarative programming

Socket-programming Simple server and client using python socket and declarative programming How to use? open cmd and navigate to the location of the s

MAINAK CHAUDHURI 21 Sep 30, 2021
Small utility that leverages eBPF to dump the traffic of a unix domain socket

UnixDump UnixDump is a small eBPF powered utility that can be used to dump unix socket traffic. System requirements This project was developed on a Ub

Guillaume Fournier 5 Dec 1, 2021
Socket server for DAZ Studio meant for use with Streamdeck plug-in

StreamDeckSocket This listens on port 8080 of localhost. If the port is inconvenient, change it in "qhttpserver.h" as LISTEN_PORT do not change the LI

Stephen 2 Oct 9, 2021
As a Teaching Assistant, this is a sample project about socket programming for my teaching in a capstone course in NTUST(National Taiwan University of Science and Technology)

socket-programming As a Teaching Assistant, this is a sample project about socket programming for my teaching in a capstone course in NTUST(National T

Chang Wei 2 Oct 26, 2021
Multithreaded client socket server

-------------------------------------------------------------------------------------- File structure ------------------------------------------------

Ashish Kaushik 1 Mar 1, 2022
A beginner friendly Client-Server program in C. Socket Programming in C

basic-client-server Program on basic client-server connection. This is intended to whomever it may be useful. If you use this somewhere else, proper r

Abdul Samad 1 Oct 21, 2021
簡單的 socket programming 入門筆記。

socket programming socket 本質上是一種 IPC (Inter-Process Communication) 的技術,用於兩個或多個 process 進行資料交換或者通訊。 在網路領域,socket 著重的不是同一台主機間 process 的通訊,而是不同主機執行的 proc

davidleitw 22 Jul 16, 2022
Provide translation, currency conversion, and voting services. First using telnet you create a connection to a TCP socket, then the server connects to 3 UDP sockets hosted on other servers to do tasks.

to run micro servers g++ translator.cpp -o translator ./translator <port 1> g++ voting.cpp -o voting ./voting <port 2> g++ currency_converter.cpp -o c

Jacob Artuso 1 Oct 29, 2021
A toy implementation of socket programming for Lean 4.

Lean4-Socket A toy implementation of socket programming for Lean 4. Installation Lake import Lake open System Lake DSL package foo where dependenci

王虛白 18 Jul 21, 2022
Faster termux-am implementation that connects to a receiver in termux-app using a unix socket

termux-am-socket This is a small program for sending commands to the Termux:API app, thereby allowing terminal programs to use the Android API. The pr

Termux 20 Sep 12, 2022
Wrapper for linux TCP/UDP/unix/USB socket connections

Socket Connection wrapper shared library Shared library that realize sockets connections and could transfer data-packages. Navigation Navigation Insta

Dmitry Golgovsky 7 Dec 21, 2021
A socket daemon to multiplex connections from and to iOS devices

usbmuxd A socket daemon to multiplex connections from and to iOS devices. Features usbmuxd stands for "USB multiplexing daemon". This daemon is in cha

libimobiledevice 1.1k Sep 21, 2022