C++ TCP Library - NO LONGER MAINTAINED

Overview

Important

Please be advised that this library is no longer maintained.

I have maintained this library for over 2 years, but I do not have enough time to provide a reliable support and continuous development for any longer.

Any existing or new issues will not be treated and I do not guarantee to merge any new pull request.

If anyone is willing to take over this project, feel free to fork this project and message me to add a link to your fork in this README.

Taco Pie Build Status Build status

tacopie is a multi-platform TCP Client & Server C++11 library.

Requirement

tacopie has no dependency. Its only requirement is C++11.

Example

tacopie::tcp_server:

tacopie::tcp_server s;
s.start("127.0.0.1", 3001, [] (const std::shared_ptr<tacopie::tcp_client>& client) -> bool {
  std::cout << "New client" << std::endl;
  return true;
});

tacopie::tcp_server full documentation and detailed example.

tacopie::tcp_client:

tacopie::tcp_client client;
client.connect("127.0.0.1", 3001);
client.async_read({ 1024, [&] (tacopie::tcp_client::read_result& res) {
  client.async_write({ res.buffer, nullptr });
} });

tacopie::tcp_client full documentation and detailed example.

Wiki

A Wiki is available and provides full documentation for the library as well as installation explanations.

Doxygen

A Doxygen documentation is available and provides full API documentation for the library.

License

tacopie is under MIT License.

Contributing

Please refer to CONTRIBUTING.md.

Author

Simon Ninon

Issues
  • Build dynamic library failed on Windows

    Build dynamic library failed on Windows

    Hi, I'am trying to build a dll library on Windows, but got linking error:

    Severity	Code	Description	Project	File	Line	Suppression State
    Error	LNK2001	unresolved external symbol __imp_listen	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\tcp_socket.obj	1	
    Error	LNK1120	20 unresolved externals	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\msvc15\x64\Release\tacopie.dll	1	
    Error	LNK2001	unresolved external symbol __imp_accept	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\tcp_socket.obj	1	
    Error	LNK2001	unresolved external symbol __imp_bind	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_self_pipe.obj	1	
    Error	LNK2001	unresolved external symbol __imp_closesocket	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_self_pipe.obj	1	
    Error	LNK2001	unresolved external symbol __imp_connect	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_self_pipe.obj	1	
    Error	LNK2001	unresolved external symbol __imp_freeaddrinfo	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_tcp_socket.obj	1	
    Error	LNK2001	unresolved external symbol __imp_getaddrinfo	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_tcp_socket.obj	1	
    Error	LNK2001	unresolved external symbol __imp_getsockname	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_self_pipe.obj	1	
    Error	LNK2001	unresolved external symbol __imp_htonl	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_self_pipe.obj	1	
    Error	LNK2001	unresolved external symbol __imp_htons	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_tcp_socket.obj	1	
    Error	LNK2001	unresolved external symbol __imp_inet_ntoa	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\tcp_socket.obj	1	
    Error	LNK2001	unresolved external symbol __imp_ioctlsocket	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_self_pipe.obj	1	
    Error	LNK2001	unresolved external symbol __imp_recv	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\tcp_socket.obj	1	
    Error	LNK2001	unresolved external symbol __imp_recvfrom	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_self_pipe.obj	1	
    Error	LNK2001	unresolved external symbol __imp_select	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\io_service.obj	1	
    Error	LNK2001	unresolved external symbol __imp_send	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\tcp_socket.obj	1	
    Error	LNK2001	unresolved external symbol __imp_sendto	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_self_pipe.obj	1	
    Error	LNK2001	unresolved external symbol __imp_socket	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_self_pipe.obj	1	
    Error	LNK2001	unresolved external symbol __imp_WSAGetLastError	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\windows_tcp_socket.obj	1	
    Error	LNK2001	unresolved external symbol __WSAFDIsSet	tacopie	Z:\cpp_redis4.2.0\cpp_redis-4.2.0\tacopie\msvc15\io_service.obj	1	
    

    How to reproduce:

    • Use latest tacopie tag(3.1.0)
    • Change visual studio solution configure: Configuration Type: static to dynamic
    wait for reporter response 
    opened by theidexisted 10
  • Resolve Compiler Warnings for Windows Build

    Resolve Compiler Warnings for Windows Build

    Hi @Cylix

    I just open a new PR for this topic.

    Hi @Cylix

    thanks for all the integration work so far! If you take a look at the tacopie build on Windows, you still see 4 compiler warnings. I am trying to get rid of them.

    • 3 warnings are about type conversion. For some reason Win wants the buffer length for sockets as int instead of size_t. Negative buffer length surely are a breat benefit ^^ I added a type conversion macro right at the Winsock2.h API call as I did not see any benefit of carrying this issue wider through the application.
    • 1 warning is about a deprecated inet_ntoa function, which only supports IPv4. As long we stick to IPv4, we should be save to supress this warning (which I did for now). As we still have some work to do for IPv6, I suppressed this warning.

    Ah, and I made the PlatformToolset consistent between all build configs.

    When all builds pass, this PR would be ready to merge. Any comments are welcome ;)

    opened by zodiac403 7
  • Inconsistent async_read behaviour after 2.4.3

    Inconsistent async_read behaviour after 2.4.3

    On versions 2.4.2 and before async_read would always call the callback with read_result.sucess == false after the read is finished.

    After 2.4.2, this no longer appears to always be the case, in fact, after the client has finished sending all its info and disconnected, some of the time the callback won't be triggered at all.

    Tested on Visual Studio 2017.

    bug 
    opened by willxinc 6
  • Support IPv6

    Support IPv6

    1、Support IPv6 2、add Os Macro definition 3、Merge unix and windows of socket and pipe code 4、remove unix and windows files 5、add socket utils files insert of same duplicated code. 6、repair complie erro with xcode

    Ah,Because of my poor english. less code annotation。sorry for it。happy fun^_^

    opened by yuangu 4
  • gethostbyname is thread unsafe

    gethostbyname is thread unsafe

    Hi, I'm using cpp_redis in a multithreaded environment. Running DRD on several usecases, it seems that this function is not thread safe as confirmed by linux man page. Cheers,

    opened by ProRealTime 4
  • tacopie thread_pool class variable m_nb_running_threads should lock to avoid race condition?

    tacopie thread_pool class variable m_nb_running_threads should lock to avoid race condition?

    hi, I have used your cpp_redis, in your source code, i see you have implemented a lightweight thread pool, I wonder why you has not lock the m_nb_runing_threads variable to protect it from race condition? each thread of the worker pool would execute the following code:
    // if (should_stop()) { //may occur the race condition --m_nb_running_threads; return {true, nullptr}; } bool thread_pool::should_stop(void) const { return m_should_stop || m_nb_running_threads > m_max_nb_threads; } // would you like to give me an explanation?I am a little confused of it, thank you very much.

    opened by kkshaq 3
  • WIP: Resolve Compiler Warnings for Windows Build

    WIP: Resolve Compiler Warnings for Windows Build

    Still work in progress. Please do not merge yet ;)

    Hi @Cylix

    thanks for all the integration work so far! If you take a look at the tacopie build on Windows, you still see 4 compiler warnings. I am trying to get rid of them.

    • 3 warnings are about type conversion. For some reason Win wants the buffer length for sockets as int instead of size_t. Negative buffer length surely are a breat benefit ^^ I added a type conversion macro right at the Winsock2.h API call as I did not see any benefit of carrying this issue wider through the application.
    • 1 warning is about a deprecated inet_ntoa function, which only supports IPv4. As long we stick to IPv4, we should be save to supress this warning (which I did for now). For IPv6 we had some work to do here.

    In addition, I changed the projects settings to fail the build, if compiler warnings occur.

    I still need some time on this. But if you have any thoughts in the meantime, feel free to share ;)

    opened by zodiac403 3
  • TCP Server example throws exception

    TCP Server example throws exception

    Hello, nice library. I'd like to use it but straight away I have encountered this problem. Built OK under MSYS2 on Windows 7 with Mingw64 compiler.

    terminate called after throwing an instance of 'tacopie::tacopie_error' what(): fail socket()

    That's the TCP server example copied and pasted. The issue is in the tcp_server constructor.

    opened by supercamel 3
  • build with bazel

    build with bazel

    bazel build --config=opt //... bazel test --config=opt //...

    Now you can run bazel run --config=opt //:example_tcp_server (which is the same as ./bazel-bin/example_tcp_server) and bazel run --config=opt //:example_tcp_client (or ./bazel-bin/example_tcp_client)

    (Note: You cannot bazel run both, because bazel run is limited to one application at a time.)

    opened by steple 2
  • How to make a broadcast on tcp server?

    How to make a broadcast on tcp server?

    Hey guy, thx for your great job. Here is what i met

    1 Send msg form server

    I'd like to send msg from server to client, not just received from client then reply. Is there any way to do these? I cant find any write function in tcp_server.cpp.

    2 Bug

    I delete some code from demo, then my client can't receive any msg anymore. like this:

    Work well

    void on_new_message(const std::shared_ptrtacopie::tcp_client& client, const tacopie::tcp_client::read_result& res) { if (res.success) { std::cout << "Client recv data" << std::endl; client->async_write({ res.buffer, nullptr }); client->async_read({ 1024, std::bind(&on_new_message, client, std::placeholders::_1) }); } else { std::cout << "Client disconnected" << std::endl; client->disconnect(); } }

    ** "Client recv data" shown, client got no reply **

    void on_new_message(const std::shared_ptrtacopie::tcp_client& client, const tacopie::tcp_client::read_result& res) { if (res.success) { std::cout << "Client recv data" << std::endl; client->async_write({ res.buffer, nullptr }); // client->async_read({ 1024, std::bind(&on_new_message, client, std::placeholders::_1) }); } else { std::cout << "Client disconnected" << std::endl; client->disconnect(); } }

    I am not sure its a bug or i made some mistake.

    opened by VShawn 2
  • when connect timeout is 0,  connnect fail on same operating systems.

    when connect timeout is 0, connnect fail on same operating systems.

    Some operating systems (such as IOS), socket defaults to non blocking. When the connect set to timeout is 0, the connection will fail.

    sorry for my poor english.^_^

    opened by yuangu 2
  • Branch on a garbage value

    Branch on a garbage value

    Clang analyzer shows this error:

    Logic error: Branch condition evaluates to a garbage value 1: Calling 'tcp_client::process_write' in tacopie/sources/network/tcp_client.cpp:174 2: Assuming the condition is true in tacopie/sources/network/tcp_client.cpp:218 3: Returning from 'tcp_client::process_write' in tacopie/sources/network/tcp_client.cpp:174 4: Branch condition evaluates to a garbage value in tacopie/sources/network/tcp_client.cpp:176

    The value result.success seems never to be initialized anywhere here:

      read_result result;
      auto callback = process_read(result);
    
      if (!result.success) {
        __TACOPIE_LOG(warn, "read operation failure");
        disconnect();
      }
    

    While I see that process_read() does the initialization, I'm wondering whether there's something else missing.

    opened by TheQuantumPhysicist 0
  • Running on vis. std. 2017

    Running on vis. std. 2017

    Hello, First of all , thanks for this nice lib. I was trying to compile on win 10 , vis. std. 2017, and getting unresolved external errors. After some digging I realize that #pragma comment(lib, "ws2_32.lib") line should be added (i added it in #ifdef _win32 definition )

    This needed for both client and server examples.

    Best regards,

    opened by firatsarlar 0
  • Tacopie TCP server library (read access violation after close under TCP zero window condition)

    Tacopie TCP server library (read access violation after close under TCP zero window condition)

    Issue imported from emails:

    Bonjour Simon,
    
    ça va?
    
    I'm very happy to have discovered your excellent Tacopie library on GitHub. You know, I was looking for a modern TCP server library that would take a lot of work out of my hands. I'm currently using it in order to run a few custom VNC-server experiments.
    
    However, I now think I have run into a bug (either in my own program, tacopie or perhaps both).
    
    Background:
    
    I have made a small tacopie based "VNC server" program that talks to the well known "Ultra VNC Viewer" / "Tight VNC viewer" etc.
    
    Now the current implementation of "my" VNC server is minimalistic. 
    For instance it does not send 'incremental' screen updates at all (yet).
    
    Build-up
    
    When I connect with the UVNC client, the connection is established fine and things generally work as expected. UVNC displays the screen I'm sending and receiving keyboard/mouse input works too. Life is good!
    
    Remember I don't send incremental updates to UVNC. Well, at some point in time, UVNC starts to worry about that and decides that it now has waited long enough for those. It then simply stops receiving data from its socket and displays a (misleading!) "server closed the connection" popup.
    
    And I know it is misleading because all the while its TCP socket is actually still open! I verified this with Wireshark: no FIN messages etc.
    
    To further convince myself the connection is still open I press the "refresh screen" button on the UVNC toolbar a few times. The server 'sees' these update requests and duly replies, writing a lot of data to the socket.
    
    Since UVNC is not receiving data from the socket, this causes a so called "TCP zero window" situation where basically the TCP-buffer on the client side is exhausted.
    
    Here comes the real problem
    
    If I dismiss the UVNC popup under these specific conditions, the TCP connection will actually be terminated (which is good). But the server application may now crash with an access violation.
    
    The crash happens when trying to obtain the mutex m_write_requests_mtx inside method tcp_client::process_write. I suspect the tcp_client object is destroyed before process_write is called.
    
    The more bytes I attempt to write in that zero window situation, the higher the chance the server application will crash this way. If I press that refresh button numerous times, the crash is virtually guaranteed.
    
    I figure this has something to do with those bytes that could not be written to the socket, delivered etc. 
    It looks to me like a race condition where part of the library wants to notify the connection object after having it already destroyed somewhere else (from another thread?).
    
    Disclaimer: I'm not sure if this can be attributed to a bug in my program or the library, but I thought I would communicate it anyway... It may or may not be of help to you.
    
    
    opened by Cylix 4
Releases(3.2.0)
  • 3.2.0(Nov 14, 2017)

    Tag

    3.2.0

    Date

    November 13th, 2017

    Changes

    • fork support: allow set_default_io_service to take nullptr. In order to safely fork, call set_default_io_service(nullptr) to make sure the io_service destructor is called and all underlying threads joined.
    • fix: timeout for connection not working due to invalid param to select, now working
    • improvement: make sure socket is in blocking mode before connection (#32) as it differs from one OS to another
    • improvement: check for non-blocking connect errors with getsockopt to avoid connect reporting a successful connection followed by a call to disconnection handler (now connect report a failed connection as expected).

    Additions

    • ipv6 support (connect, bind and accept operations, on tcp_server and tcp_client)

    Removals

    None

    Source code(tar.gz)
    Source code(zip)
  • 3.1.0(Nov 3, 2017)

    Tag

    3.1.0

    Date

    November 2nd, 2017

    Changes

    • Improvement: For windows, if port is 0, use the default AF_INET windows API behavior (bind to first port available). Behavior on unix is unchanged (is unix socket).
    • CMake fix: Remove explicit STATIC in add_library call so dynamic libraries can be built with -DBUILD_SHARED_LIBS=ON

    Additions

    • Visual Studio C++ solution

    Removals

    None

    Source code(tar.gz)
    Source code(zip)
  • 3.0.1(Sep 26, 2017)

    Tag

    3.0.1

    Date

    September 26th, 2017

    Changes

    • Fix some compilation issues on windows

    Additions

    None.

    Removals

    • Private, Protected and Static functions from doxygen documentation
    Source code(tar.gz)
    Source code(zip)
  • 3.0.0(Sep 21, 2017)

    Tag

    3.0.0

    Date

    September 20th, 2017

    Changes

    • clear pending read and write requests on disconnection
    • io_service access
    • ability to modify number of io service worker at runtime

    Additions

    • doxygen documentation
    • connection timeout if requested (for tcp_socket and tcp_client)
    • ability to change the number of io_service workers (or thread_pool threads) at runtime

    Removals

    None.

    Source code(tar.gz)
    Source code(zip)
  • 2.4.4(Jul 2, 2017)

    Tag

    2.4.4

    Date

    July 2nd, 2017

    Changes

    • add calls to WSAStartup and WSACleanup in examples (#16).
    • fix #17 and cpp_redis#85 (select keep sleeping and does not process incoming read/write events).

    Additions

    None.

    Removals

    None.

    Source code(tar.gz)
    Source code(zip)
  • 2.4.3(Jun 21, 2017)

    Tag

    2.4.3

    Date

    June 19th, 2017

    Changes

    • Remove unnecessary use of self-pipe to try to fix high-CPU usage issued reported on this repository and on cpp_redis repository.

    Additions

    • CMake compilation flag SELECT_TIMEOUT that can be used to define the select timeout in nano seconds. By default, timeout is set to NULL (unlimited).

    Removals

    None.

    Source code(tar.gz)
    Source code(zip)
  • 2.4.2(Jun 11, 2017)

    Tag

    2.4.2

    Date

    June 11th, 2017

    Changes

    • Compilation Fix
    • change behavior of on_new_connection_handler. Returning true means connection is handled by tcp_client wrapper and nothing will be done by tcp_server. Returning false means connection is handled by tcp_server, will be stored in an internal list and tcp_client disconection_handler overriden.

    Additions

    • get_host & get_port methods for tcp_client

    Removals

    None.

    Source code(tar.gz)
    Source code(zip)
  • 2.4.1(Apr 30, 2017)

    Tag

    2.4.1

    Date

    April 30th, 2017

    Changes

    • Compile project with /bigobj option on windows
    • Fix behavior when trying to reconnect from disconnection_handler callback

    Additions

    None.

    Removals

    None.

    Source code(tar.gz)
    Source code(zip)
  • 2.4.0(Apr 10, 2017)

    Tag

    2.4.0

    Date

    April 9th, 2017

    Changes

    None.

    Additions

    • Provide support for Unix socket. Simply pass in 0 as the port when building a tcp_socket, tcp_client or tcp_server. Then, the host will automatically be treated as the path to a Unix socket instead of a real host.

    Removals

    None.

    Source code(tar.gz)
    Source code(zip)
  • 2.3.0(Apr 10, 2017)

  • 2.2.0(Apr 5, 2017)

    v2.2.0

    Tag: 2.2.0.

    Date: April 4th, 2017

    Description:

    • Change: IO Service is now based on select and not on poll anymore to solve some issues encountered on windows due to the buggy implementation of poll on windows Systems.
    Source code(tar.gz)
    Source code(zip)
  • 2.1.0(Mar 20, 2017)

    v2.1.0

    Tag: 2.1.0.

    Date: March 19th, 2017

    Description:

    • Remove: install_deps.sh has been removed in favor of CMakelists.txt enhancement.
    • Change: read and write TCP client callbacks now takes a reference to the result as parameter instead of a const-reference.
    Source code(tar.gz)
    Source code(zip)
  • 2.0.1(Feb 16, 2017)

    Fix: replace gethostbyname() (not thread-safe) usage by getaddrinfo() (thread-safe) on unix platforms. No change where required on windows as getaddrinfo() was already in use before.

    Source code(tar.gz)
    Source code(zip)
  • 2.0.0(Jan 29, 2017)

    • Feature: Port the library onto windows
    • Feature: Make the library usable by cpp_redis
    • Fix: some sockets were not removed from io_service tracking. Now fixed
    • Improvement: handle POLLHUP events
    Source code(tar.gz)
    Source code(zip)
  • 1.1.0(Dec 16, 2016)

    Improvement of the public API:

    • Make server on_new_connection callback take shared_ptr as parameter instead of reference (provide more flexibility to the client app)
    • Provide access to tcp_socket in the public API of tcp_client and tcp_server

    Wiki has been updated appropriately.

    Source code(tar.gz)
    Source code(zip)
  • 1.0.0(Dec 11, 2016)

    TCP Client & Server for Unix & Mac platform. Documented in the wiki.

    Windows port will come as well as some additional features in later releases. In particular, some features available on the cpp_redis network module will be imported here.

    Source code(tar.gz)
    Source code(zip)
Owner
Simon Ninon
Senior Site Reliability Engineer at PagerDuty
Simon Ninon
an easy implementation of a multi-process tcp server and a multi-thread tcp client

一个TCP多进程服务器-多线程客户端的简单实现。 客户端类似Apache ab的测试功能,能够通过向某一个ip端口发送指定并发量和总数量的tcp短连接;服务端处理tcp短连接,每来一条消息就打印一条log。 使用cmake编译,建议在vscode里编译,或者命令行 # 终端进入目录 mkdir bu

adin 1 Nov 28, 2021
Mongoose Embedded Web Server Library - a multi-protocol embedded networking library with TCP/UDP, HTTP, WebSocket, MQTT built-in protocols, async DNS resolver, and non-blocking API.

Mongoose - Embedded Web Server / Embedded Networking Library Mongoose is a networking library for C/C++. It implements event-driven non-blocking APIs

Cesanta Software 8.5k Jun 29, 2022
Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and 10K connections problem solution

CppServer Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and

Ivan Shynkarenka 848 Jun 26, 2022
A modern C++ network library for developing high performance network services in TCP/UDP/HTTP protocols.

evpp Introduction 中文说明 evpp is a modern C++ network library for developing high performance network services using TCP/UDP/HTTP protocols. evpp provid

Qihoo 360 3k Jun 27, 2022
Warp speed Data Transfer (WDT) is an embeddedable library (and command line tool) aiming to transfer data between 2 systems as fast as possible over multiple TCP paths.

WDT Warp speed Data Transfer Design philosophy/Overview Goal: Lowest possible total transfer time - to be only hardware limited (disc or network bandw

Facebook 2.7k Jun 27, 2022
Brynet - Header Only Cross platform high performance TCP network library using C++ 11.

Brynet Header Only Cross platform high performance TCP network library using C++ 11. Build status Windows : Linux/MacOS : Features Header only Cross p

IronsDu 848 Jun 27, 2022
Asynchronous TCP Library for STM32H7-based Portenta_H7 using mbed_portenta core.

Asynchronous TCP Library for STM32H7-based Portenta_H7 using mbed_portenta core. This library is the base for future and more advanced Async libraries, such as AsyncWebServer, AsyncHTTPRequest, AsyncHTTPSRequest

Khoi Hoang 2 May 23, 2022
Asynchronous SSL TCP Library for ESP32.

Asynchronous SSL TCP Library for ESP32. This library is the base for future and more advanced Async SSL libraries, such as AsyncSSLWebServer, AsyncHTTPSRequest

Khoi Hoang 5 Apr 27, 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
TCP based publish-subscribe library

tcp_pubsub - TCP Publish/Subscribe library tcp_pubsub is a minimal publish-subscribe library that transports data via TCP. The project is CMake based.

Continental 9 Jun 7, 2022
mTCP: A Highly Scalable User-level TCP Stack for Multicore Systems

README mTCP is a highly scalable user-level TCP stack for multicore systems. mTCP source code is distributed under the Modified BSD License. For more

null 1.8k Jun 22, 2022
FreeModbus is a Modbus ASCII/RTU and Modbus TCP implementation for embedded systems

FreeModbus is a Modbus ASCII/RTU and Modbus TCP implementation for embedded systems. It provides an implementation of the Modbus Application Protocol

Mahmood Hosseini 17 Apr 7, 2022
High performant TCP server for rtl-sdr

About Key features Share available RF bandwidth between several independent clients: Total bandwidth can be 2016000 samples/sec at 436,600,000 hz One

dernasherbrezon 110 Jun 17, 2022
A simple tcp tunnel on c using sockets Right now it only supports linux systems

A simple tcp tunnel on c using sockets Right now it only supports linux systems build BY MAKE mkdir build make cd build ./tunnel.o <localport> <rem

notaweeb 8 Sep 20, 2021
TCP tunnel powered by epoll

Feature Dual Stack Async DNS Non-blocking IO Zero Copy Build git clone https://github.com/zephyrchien/ZTUN cd ZTUN mkdir build && cd build cmake .. ma

zephyr 15 Jun 3, 2022
A simple tcp/ip stack

pip A simple TCP/IP stack, just like lwIP, but pip focus only parse IP Packet and output IP Packet, basically realize no memory copy 一个简单的TCP/IP协议栈实现,

plumk 25 Apr 15, 2022
null 4 Feb 25, 2022
TCP Port Redirection Utility

Overview PortBender is a TCP port redirection utility that allows a red team operator to redirect inbound traffic destined for one TCP port (e.g., 445

Praetorian 386 Jun 27, 2022
TCP tunnel powered by epoll

Feature Dual Stack Async DNS Non-blocking IO Zero

zephyr 15 Jun 3, 2022