C + + 11 high Performance network server EVPP based on libevent development

EVPP is a modern c++11 high performance Web server based on Libevent, with asynchronous non-blocking servers and client libraries with protocols such as Tcp/udp/http.

Characteristics:

• Modern version of the C++11 interface

• Non-blocking asynchronous interfaces are c++11 functional/bind form of callback functor (not a C-style function pointer in libevent)

• Non-blocking pure asynchronous Multithreaded TCP server/client

• Non-blocking pure asynchronous multithreaded HTTP Server/client

• Non-blocking pure asynchronous multithreaded UDP server

• Supports multi-process mode

• Excellent cross-platform features and high performance (inherited from libevent benefits)

In addition, based on this library, two additional application layer protocol libraries are available:

• EVMC: A pure asynchronous non-blocking memcached C + + client library that supports Membase cluster mode. For details, see: EVMC Readme

• EVNSQ: A pure asynchronous non-blocking NSQ C + + client library that supports consumer, producer, and service discovery features. For details, see: EVNSQ Readme
  A Redis client library will also be introduced in the future.

Origin:

Our development team responsible for the business needs to use the TCP protocol to build long-connected gateway services and some other TCP-based short-link services, in the process of investigating open source projects, did not find a suitable library to meet our requirements. In combination with our own business situation, the ideal C + + network library should have several features:

• Interface is easy to use, preferably a C + + interface

• Multi-threaded, can also support multiple processes

• It is best to implement based on the libevent (because existing legacy frameworks, base libraries, etc. are dependent on libevent), which makes it easy to embed libevent event loops, otherwise large or integrated programs may have many cross-threading calls

Based on these needs, there is not much to choose from, so we can only develop one ourselves. In the development process, most of the interface design is the reference Muduo project to design and implementation, of course, also made some trade-offs and changes, but also a lot of Golang design philosophy and ideas, give a few small examples to illustrate:

1. Duration: This is a time interval related class, with time unit information, referenced Golang implementation in Duration project. We see too much time in other projects without units, such as timeout, is it seconds, milliseconds or microseconds? Need to look at the document description or implementation, a good design will bring the unit in the variable name, such as Timeout_ms, but there is no duration such a separate class good. At present, there are similar implementations in c++11 Std::chrono::d uration, but slightly more complex, without our reference to the Golang implementation of the version to be simple and clear.

2. Buffer: This is a buffer class that incorporates the design and implementation of related classes in the Muduo and Golang two projects

3. Http::server: This is an HTTP server class, with a thread pool, Its event loops and worker-thread scheduling are completely thread-safe, and the business layer does not have to worry too much about cross-thread invocation issues. At the same time, the core functions of the HTTP server are extracted separately to form the

4. Http::service class, which is an embeddable server class that can be embedded in an existing Libevent event loop. The expression of the
   network address is simply a string representation of "Ip:port", which is the design of the reference Golang

The

5. Httpc::connpool is an HTTP client connection pool library that is designed to consider high performance and reuse as much as possible. Based on this, you can also add features such as load balancing and failover.

In addition, we attach great importance to thread safety in the implementation process, an event-related resource must be initialized and disposed of in the EventLoop to which it belongs, so that we can minimize the possibility of errors. To achieve this, we overload functions such as Event_add and Event_del, and each time we call Event_add, we record the object in the corresponding thread private data, and when we call Event_del, we check whether the object is owned by the thread's private data. Then, before the entire program exits, and then complete check the private data of the thread, to see if there are still objects do not have a destructor release, detailed code implementation can refer to Https://github.com/Qihoo360/evpp/blob/master/evpp/inner_ Pre.cc#l46~l87. We are so demanding thread safety, just to make a program quiet and smooth exit or reload, because we deeply understand that "writing a system that runs forever, and writing a system that is still closed after a certain period of time is not the same thing", the latter is much more difficult.

Http://www.oschina.net/p/evpp

C + + 11 high Performance network server EVPP based on libevent development