evpp
evpp copied to clipboard
Qihoo360
A modern C++ network library for developing high performance network services in TCP/UDP/HTTP protocols.
将session中的消息函数修改下，模拟接收到异常数据包，关闭连接（异常处理），这样客户端会崩溃 ```C++ void OnMessage(const evpp::TCPConnPtr& conn, evpp::Buffer* buf) { LOG_TRACE Close(); } ```
在重构代码的过程中，发现关于SetMessageCallback的疑问，还麻烦大佬帮忙解答下。 在重构代码前，代码的结构大体是这样的： ```C++ //这些回调函数都在一个.cpp文件里面 写的全局函数 void A_connect_callback(){} void A_message_callbacl(){} void B_connect_callback(){} void B_message_callbacl(){} void C_connect_callback(){} void C_message_callbacl(){} //大概的伪代码。 void init_server() { if(A) { evpp::EventLoop * next = _tpool->GetNextLoop(); std::shared_ptr server(new...
我看了你的关于evpp和asio性能比对博客, 下载了陈硕的recipes中asio的demo进行测试, 我测出的吞吐量数据平均只有你博客中的1/5;想确认下是否测试方法有问题; 测试环境:windows x64 cpu:i5 3.2GHz 用vs2013编译测试的(debug和release差不多) client的参数是:单线程 ,块大小8192,1个session, server参数一样; 用批处理脚本启动了共10个client;一般只有100M/s, 博客中数据有600M/s; 如果启动一个client,session设置为10也是一样的;
CMakeList要求的版本最低是3.1，请修改cmake_minimum_required (VERSION 2.8)
1.客户端调用disconnect，直接关闭了fd，并没有判断当前客户端有没有在写，如果客户端的发送缓冲区满了，那么数据会堆积在output_buffer中等待发送，discconect强制关闭客户端的写端，会导致output_buffer中的数据丢失。 2.客户端调用disconnect，完全关闭了fd的读写端，那么此时服务器端发送缓冲区的数据会丢失，正常应该先关闭写端，等read函数返回0时，再关闭读端把。
Hello, I hope that your day is going well. My project is using the "simple_proxy" example to build upon and I think that EVPP is just amazing and has the...
1、环境： 物理机：macos、mem 8g、cpu i5 2core 客户机：win7旗舰、mem 2g、cpu i5 2core 2、evpp代码： ``` #include "evpp/inner_pre.h" #include #include "evpp/libevent.h" #include "evpp/event_watcher.h" #include "evpp/event_loop.h" //#ifdef WIN32 //#define LOCAL_SOCKETPAIR_AF AF_INET //#else //#define LOCAL_SOCKETPAIR_AF AF_UNIX //#endif...
listenerer中Listen接口默认backlog为SOMAXCONN，而这个一般为128，相当于编译在程序中了。 tcp_server中Init直接调用的Listen，会导致用户通过调整内核参数改变了backlog值后，程序不能作出响应。 希望将backlog等参数暴露到涉及到服务监听的地方，能够更方便的更改。
folly::ProducerConsumerQueue比cameron314作者的spsc queue更快，希望能把folly::MPMCQueue也加入性能对比测试。源代码在 https://github.com/facebook/folly/blob/master/folly/MPMCQueue.h，其中提到在各种场景下比intel tbb::concurrent_queue快，肯定会是优秀的竞争者。 另外 https://github.com/cameron314/concurrentqueue 并非线性（并非先生产的一定先被处理），而市面上大多数concurrent queue是基于线性实现，性能上起点略不同。
