cpp-netlib/netlib

C++ Network Library

Modern C++ network programming libraries.

Join us on Slack: http://slack.cpp-netlib.org/

Subscribe to the mailing list: https://groups.google.com/forum/#!forum/cpp-netlib

Downloading cpp-netlib

You can find official release packages of the library at:

http://github.com/cpp-netlib/cpp-netlib/downloads

If you want the latest code from the master branch of the project, you can follow these instructions for cloning the project repository:

$ git clone https://github.com/cpp-netlib/cpp-netlib
$ cd cpp-netlib
$ git submodule init
$ git submodule update

Introduction

cpp-netlib is a collection of network-related routines/implementations geared towards providing a robust cross-platform networking library. cpp-netlib offers the following implementations:

• Common Message Type -- A generic message type which can be used to encapsulate and store message-related information, used by all network implementations as the primary means of data exchange.
• Network protocol message parsers -- A collection of parsers which generate message objects from strings.
• Adapters and Wrappers -- A collection of Adapters and wrappers aimed towards making the message type STL friendly.
• Network protocol client and server implementations -- A collection of network protocol implementations that include embeddable client and server types.

This library is released under the Boost Software License (please see http://boost.org/LICENSE_1_0.txt or the accompanying LICENSE_1_0.txt file for the full text.

Building and Installing

To build the libraries you will need to have CMake version 2.8 or higher installed appropriately in your system.

$ cmake --version
cmake version 2.8.1

It is recommended that you build cpp-netlib outside of the source directory, to avoid having issues with CMake generated files polluting the source directory:

$ mkdir ~/cpp-netlib-build
$ cd ~/cpp-netlib-build
$ cmake -DCMAKE_BUILD_TYPE=Debug     \
>       -DCMAKE_C_COMPILER=clang     \
>       -DCMAKE_CXX_COMPILER=clang++ \
>       $HOME/cpp-netlib    # we're assuming this is where cpp-netlib is.

Once CMake is done with generating the Makefiles and configuring the project, you can now build the tests and run them:

$ cd ~/cpp-netlib-build
$ make
$ make test

You can also download and install cpp-netlib using the ` vcpkg`_ dependency manager:

$ git clone https://github.com/Microsoft/vcpkg.git $ cd vcpkg $ ./bootstrap-vcpkg.sh $ ./vcpkg integrate install $ vcpkg install cpp-netlib

The cpp-netlib port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the ` vcpkg`_ repository.

If for some reason some of the tests fail, you can send the files in Testing/Temporary/ as attachments to the cpp-netlib developers mailing list.

Running Tests

If you want to run the tests that come with cpp-netlib, there are a few things you will need. These are:

• A compiler (GCC 4.x, Clang 3.6, MSVC 2008)
• A build tool (CMake is required)
• OpenSSL headers (optional)

Note

This assumes that you have cpp-netlib at the top-level of your home directory.

Hacking on cpp-netlib

cpp-netlib uses git for tracking work and is hosted on GitHub. cpp-netlib is hosted on GitHub following the GitHub recommended practice of forking the repository and submitting pull requests to the source repository. You can read more about the forking process and submitting pull requests if you're not familiar with either process yet. cpp-netib follows the GitHub pull request model for accepting patches. You can read more about the process at http://cpp-netlib.org/process.html#pull-requests.

Because cpp-netlib is released under the Boost Software License it is recommended that any file you make changes to bear your copyright notice alongside the original authors' copyright notices on the file. Typically the copyright notices are at the top of each file in the project.

You can read about the cpp-netlib style guide at http://cpp-netlib.org/style-guide.html.

The main "upstream" repository is at http://github.com/cpp-netlib/cpp-netlib.

Contact and Support

In case you have any questions or would like to make feature requests, you can contact the development team through the developers mailing list or by filing issues at http://github.com/cpp-netlib/cpp-netlib/issues.

Join us on Slack: http://slack.cpp-netlib.org/

You can reach the maintainers of the project through:

Dean Michael Berris ([email protected])

Glyn Matthews ([email protected])

netlib's Issues

Just want to contribute to this project

Dear,

I just want to contribute my coding to this project. Is there any required skills?

I have skill in c/c++ and experience on creating web apps.

Thanks,
Thuc

RFC: A collection of abstractions for network programming

Background

The goal of the project is to provide some abstractions to use for network programming at large. These include defining vocabulary concepts which will allow us to build higher level abstractions on top of. Some of these will sound familiar, but will require some elaboration.

Some guidelines for the discussion:

• We will attempt to operate only on the abstractions. If these are "concepts" we will provide type erasure facilities which can be used in ABI boundaries.

• We will not constrain the APIs to just async, blocking, or streaming. Consider when an operation on an abstraction is defined that it may be any one of the aforementioned styles.

• We may consider implementing the abstractions directly, or wrapping a dependency. For example, we might decide that we don't want to depend on Asio or implementations of the networking TS and instead implement these lower-level libraries ourselves.

As a conversation starter, here's a list of the abstractions I've been thinking about and opening up the list for comments on what might be the minimum required set of abstractions for us to build, say an HTTP server and client? Or if someone wanted to build/implement an RPC system with a custom protocol?

Proposed Abstractions

Here's a non-complete list of abstractions:

• Connection -- an abstraction which allows for performing write(Connection, ...) and read(Connection, ...) operations.
• Buffer -- a backing store of data which may be segmented in nature (i.e. a list of blocks) or associated with an external resource (can be associated with a Connection) which provides iterators (in the STL sense) for the data associated with a Buffer.
• Address -- a data type which represents a location of a resource. There may be many kinds of addresses, which depend on the underlying network implementation -- this should be able to represent things like domain sockets, named pipes, IPv4 and IPv6 addresses, etc.

The abstractions themselves don't mean much on their own, but the operations on these abstractions define much of the requirements. We elucidate some of these below.

Connection

First, establishing a connection will be dependent on the type of the Connection which can be as diverse as it needs to be. Consider the many ways to establish an HTTPS connection with TLS behind an HTTP proxy -- we may need to first establish a connection to the proxy, then set up a tunnel to a remote resource, and then "upgrade" the connection to be a TLS-encrypted connection. Some protocols enable multiple "streams" in a conceptual connection (for HTTP/2 for instance there can be multiple streams associated with a single connection, similar to IRC with different channels through the same session) which all compose.

We want to ensure that all Connection types support at least the following operations:

• write(Connection, ...)
• read(Connection, ...)
• query(Connection, ...)
• configure(Connection, ...)

The results of these operations will be specific to the Connection, but typically these free functions will be implemented as a forwarding template to public member functions of the Connection type.

All of these operations can fail, and failures are not exceptional conditions -- therefore we will refrain from using exceptions to report course-of-normal-operation failure states. We will reserve the use of exceptions to reporting failures in constructing types which have no way to represent a valid Connection object with invalid internal state (one example is if the construction fails to acquire a critical resource).

Buffer

We can represent a lot of data for higher level protocols with the concept of a Buffer -- these objects provide a means of staging data that is not immediately written to a Connection. The main operations for a buffer are:

• write(Buffer, ...)
• read(Buffer, ...)

We may have more refined buffer types which allow for seeking, and connection-backed buffers which also supports flushing contents of the buffer to the underlying connection.

Address

This abstraction covers the gamut of addressing systems which are supported/defined by the Internet Protocol addressing system, POSIX domain socket addressing, and even non-IP/POSIX addressing. The only requirement for an Address is that it support a query(Address, ...) operation which is dependent on the domain for which a particular address is defined.

Implementation Details

Sometimes we will need to expose underlying implementation details. We'll only require that the implementation details be domain-specific, non-ABI stable, and in its own namespace. While we want to provide the abstractions for ease of use, we recognise that some users (including us!) will need to reach into the implementation details at a higher level for platform/domain-specific configuration.

We may, given experience over time, consolidate more implementation details into abstraction-level functionality/support. This will require a consultation with the community on the extent/acceptability of the change.

Decide on a continuous integration (CI) system.

Pick one of:

• Travis
• CircleCI
• Google Cloud Build
• Something Else

for the CI system.

Implement the Connection Abstraction

This is part of #4 which describes a minimal connection abstraction to allow for establishing a conceptual connection to a destination "address". For now we're going to use some minimal placeholder types for the dependencies of a connection until we refine the implementation to an acceptable level of detail.

Packages/libraries manager are needed

Packages managements are supported in many framework, i think we should have it in Netlib too. Netlib can start with a small once and the core component and then...

code generation is needed

Currently many framework support code generation such as rails, .netcore,...
I suggest to have a code generation tool for netlib

• basic & built in templates in netlib: mvc, data schemas, frontend resources
• allow developer to add their own templates

Decide on a dependency management system.

Decide on using one of:

• conan.io
• vcpkg
• git submodules

for dependency management.

Built-in or added-on components for building Service Applications

Netlib can be used to create Services Applications, i think components which used to build background services are needed. Such ash RPC, RFC components for remote service in Microservices' layers

Decide on a build system.

Pick at least one of:

• bazel
• CMake
• gn

for the build system.

Bikeshed (sorry)

The name "netlib" is already used for a very old piece of software that is still used for numerical computations:

http://www.netlib.org/

I'd like to consider a naming scheme (brand?) that we can use for the library and to identify sub-components.

Built-in common web server components are needed

Modern web framework has several built-in components:

• Session, Cookie, Cache, Application Data, and other Context Data Objects
• Routes mapping: like to have React coding style with lambda :-p
• Request objects: HttpRequest, HttpResponse, Url, ..
• REST API, JSON, BJSON