Cross-platform network library (with C + + 11)

I: The foundation of cross-platform design

Using the 0-byte wsarecv/wsasend (read-write) as read-write detection under Windows, IOCP is used as a notification model and "discards" its asynchronous model.

That is, use it as a epoll. Make (convenient) network library design (such as socket read-write processing) in Windows and Linux to achieve unity: the bottom of the read-write notification, the application layer (network library) processing their own read and write.

II: Single thread EventLoop

1:eventloop is a single-threaded network IO loop that uses an IOCP (Epoll) instance to manage multiple datasocket.

Add the Datasocket (and pass in a callback) to it via the Addconnection interface of EventLoop and trigger the incoming callback function after EventLoop takes over--processing the business logic after the link is established.

Datasocket is a client connection-session that allows the user to set an event callback function for it.

Setdatahandle: Sets the callback function after the message is received.

Setdisconnecthandle: Sets the callback function after the link is broken.

Of course, we can also actively disconnect the session through the Disconnect network connection.

2:eventloop implements thread-safe wakeup and asynchronous Message Queuing for external logical threads to post asynchronous operations (and wake-up to allow EventLoop to process requests as quickly as possible).

3:std::shared_ptr, as the packet type, is used to deliver the same packet to multiple clients datasocket (avoid assigning multiple messages), Datasocket a built-in queue, and saves the current pending on it packet List

Std::shared_ptr is used because it comes with reference counting processing, it is convenient to deal with the same message packets to more than one client, the allocation and release of the message packet (that is, the message is all sent to its destination client, then this message can be recycled),

No need to write a set of message package design.

Note: The current Linux client flush sends a network message, using WRITEV to improve efficiency, but there is no correlation function found on Windows (WSASend does not meet the requirements), but at some point the message can be memcpy to a buffer, Then send once (to reduce the number of send system calls)).

III: TCPServer of encapsulated EventLoop

1:tcpserver handles listen logic and assigns a eventloop to the newly-arrived link (via EventLoop's Addconnection interface).

2! : The Datasocket event callback function that can be seen from the source is datasocket*, but in the TCPServer callback function argument, the type of the session ID is: Int64 ID, not the bare pointer.

This is because TCPServer is used for multithreaded design, where the effectiveness of sessions (avoiding crosstalk) (as well as the validity of memory-wild pointer issues) needs to be ensured, while bare pointers are not secure.

3:2nd, when it comes to tcpserver multi-threaded design, the following:

In its callback function, we can post the message to a logical thread's message queue and wakeup the logical thread's eventloop, and when the logical thread is awakened, the message is read synchronously from the message queue and then processed.

And when a logical thread needs to send a message, it uses: TCPServer's send interface, which is a int64_t ID representing the session to send the message, followed by a packet that represents the message content.

Of course! : TCPServer's callback function can be processed immediately instead of being posted to other threads for collaboration, which is of course simpler to use.

For example, in some Web services where time-consuming processing is not required, but only IO-intensive (such as a gateway), it is recommended that the callback function be processed directly (such as forwarding).

Note: This network library references the Muduo:https://github.com/chenshuo/muduo

Another acknowledgement: SNIPERHW:HTTP://WWW.CNBLOGS.COM/SNIPERHW's guidance in recent years

Network Library code Address: https://github.com/IronsDu/accumulation-dev/tree/master/examples/DNet/

The current main.cpp implementation is a ping pong test (an in-process: Server with TCPServer, with multiple client threads running their own eventloop).

From main.cpp you can also see how single-threaded EventLoop and tcpserver multi-line loads Message Queuing are used.

(vs version at least VS2013) (Linux under the trouble g++/dnet under the few CPP files bar, there are several header files in the root directory of the/common and/cpp_common directories).

(g++-I.. /.. /.. /common-i. /.. /.. /cpp_common eventloop.cpp datasocket.cpp TCPServer.cpp main.cpp-std=c++0x-lrt)

TODO:: There's some todo in the code that means obscure or I'm not sure it's okay ~hoho

And I'm looking forward to the next broadcast test (like the MMO Aoi, where multiple players move simultaneously to broadcast to n players around).

Currently Ping pong test (client and server within the same process, compile without any optimizations) on my machine (AMD Athlon (tm) 7750 Dual-core processor,1.3g Hz, CentOS 6.3):

1:tcpserver uses a thread and posts the received message to the logical thread for ping pong processing.

100 links with a message packet size of 4K and throughput of 190m/s per second.

1000 links with a message packet size of 4K and throughput of 135m/s per second.

10,000 links with a message packet size of 4K and throughput of 125m/s per second.

2:tcpserver uses a thread to ping pong processing directly in its own message callback function.

100 links with a message packet size of 4K and throughput of 315m/s per second.

1000 links with a message packet size of 4K and throughput of 190m/s per second.

10,000 links with a message packet size of 4K and throughput of 160m/s per second.

Cross-platform network library (with C + + 11)