ASIO,无锁,高并发,高可靠, 统一,网络架构,抗DOS,低端4核心服务器CPU 每秒87万QPS ECHO

wangspace

回来看看大神们

wlmqgzm

回复 39# BetonArmEE

以前都是用别人的网络库, 这次是第一次自己做, 曾经给某大型通信设备公司做底层库的牛人, 当年也犯过错误, 造成了设备升级重启过程中出现了少量丢包.
经过相关人员定位后, 底层网络库开发承担相关责任, 牛人给全部相关人员发过邮件道歉, 并详细说明过客户端服务器设计流程,
时间长了,大约是十年前的邮件, 有些东西现在也要到处找资料, 再确认一下, 所以, 代码写得很慢. 流程要仔细琢磨.

在此也是一起探讨, 希望自己能够不犯错误, 一次弄好.  请大家多多指正.

自己也是首次做网络方面的编程， 能够先做好一个用户态的网络服务器程序， 就已经深感不易， 希望能够稳定运行， 其次，才考虑性能。

   

wlmqgzm

回复 40# hellioncu

请多提宝贵意见.

wlmqgzm

漫谈针对"socket_handle复用"的 高可靠性解决方案.

在做网络服务器时, 不可避免的遇到操作系统底层复用socket_handle带来的问题, 就是高层软件还在处理某个socket_handle=10的连接各类故障或者各类超时等待中, TCP/IP底层其实已经拆线了, 并且有新连接进来, 该socket_handle=10又被赋值给了新的连接, 并且由于并发处理, 新的socket_handle=10可能已经开始收发处理数据了, 老的socket_handle=10还在走拆线流程, 造成冲突.
危害就是某个连接可能出现其他数据冲突, 甚至莫名其妙的异常中断, 丢失数据包.

目前代码的解决方案是:
在前面所有管理数据单线程运行的前提下,
给每个socket_handle操作全部携带上时间指纹 accept_time(微秒级别),
新连接进来时将存储管理数据,
在存储数据时检查socket_handle,  accept_time, 使用最新数据覆盖老数据
在执行一切操作时检查对比存储数据的socket_handle,  accept_time, 当指令中携带的时间指纹与存储数据中不一致时, 避免操作, 直接丢弃过时的操作指令.
总之, 一切socket操作都有检查和校验, 可以解决此问题.
我的优势就在于单线程管理后台所有数据, 可以很简单的高性能高可靠的解决此问题.

目前, 民用级别的网络服务器软件, 多数都是忽略此问题, 可能认为发生的小概率, 或者故意漠视, 认为偶然断开一个新连进来的连接, 或者丢一个新连接的新数据包, 认为不是问题.
那么, 高可靠性网络服务器软件在设计上, 必须要避免此类问题的发生.


说一个笑话:
三个程序员被要求穿过一片田地，到达另一侧的房子。
菜鸟程序员目测了一下之间很短的距离，说：“不远！我只要十分钟。”
资深程序员看了一眼田地，想了一会，说：“我应该能在一天内过去。”菜鸟程序员很惊讶。
大神程序员看了一眼田地，说：“看起来要十分钟，但我觉得十五分钟应该够了。” 资深程序员冷笑了一声。
菜鸟程序员出发了，但只过了一会，地雷爆炸了，炸出了巨大的洞。这下他必须偏移预定的路线，原路返回，反复尝试穿过田地。最后他花了两天到达目的地，到的时候颤颤发抖，还受了伤。
资深程序员一出发就匍匐前进，仔细地拍打地面，寻找地雷，只有在安全的时候才前进。他在一天的时间内小心谨慎地缓慢爬过了这片地，只触发了几个地雷。
大神程序员出发之后径直穿过了田地，十分果断。他只用了十分钟就到了另一边。
“你是怎么做到的？”另外两个人问道，“那些地雷怎么没有伤到你？”
“很简单，”他回答道，“我最初就没有埋地雷。”

hellioncu

用时间来判断，本身就是在埋地雷

wlmqgzm

谈高性能高并发  队列的选择:  优先选择"lock-free"无锁队列

在做抗DOS处理的代码时, 存在2个线程之间, 必须要交换数据的问题,  其中一个线程是管理线程, 一个是acceptor线程.
对于此类问题, 传统的方式就是: 生产者和消费者模式, 二者之间, 通过队列QUEUE, 双方都加锁(mutex)处理队列.

我的解决方案是采用  Boost 超高性能 无锁队列来实现,  只用了三条代码就解决了此问题.  
这个无锁队列模块已经开发出来多年,  但是国内C++程序员应用不多.  
无锁队列的优势:
它将保证线程无限次调用这个方法都能够在有限步内完成，而不会因为其他线程被阻塞而导致本线程无法在有限步内完成，即“无锁”。
Boost保证在任何情况下所有并发中有一个操作能够得到执行, 不必考虑"多线进程的优先级反转等策略".

三行代码 就可以非常简洁高效率的解决一切锁(mutex)带来的问题, .

#include <boost/lockfree/spsc_queue.hpp>
boost::lockfree::spsc_queue<unsigned int, boost::lockfree::capacity<65536> >  closed_ip_queue;  
closed_ip_queue.push( int_ip );
closed_ip_queue.pop( int_closed_ip )
还要加上检查返回值的代码

下面是Boost对于spsc_queue的解释:
boost::lockfree::spsc_queue
await-free single-producer/single-consumer queue (commonly known as ringbuffer)
一个无等待的单生产者/单消费者队列（通常被称为环形缓冲区）

wlmqgzm

回复 45# hellioncu

一个已经建立的socket的持续时间不可能低于一微秒, accept_handle单线程处理,

那么对于socket_handle + socket_accept_time 这样的内容, 2个连接一定不一致.

当年用过的高可靠网络底层库, 里面对此问题的处理是: socket_handle + socket_accept_time + client_ip等客户端的特征,
不过, 当年开发测试的时候, socket_accept_time最初是秒级或者毫秒的, 我也未太关注, 我只是用别人库的路人甲, 由于需要更多区别, 牛人就考虑+ client_ip等客户端的特征.
对此问题, 为了可靠, 牛人采用的参数很多, 好像一共6个参数, 时间太久, 记不住了, 程序风格不好看, 判断语句很长, 牛人还专门发过邮件, 希望大家提更合理的解决办法, 无人回应.
然后, BOSS回邮件, 坚决反对这种把自己的内部代码问题, 群发邮件的风气, 后无下文.

我这里考虑 accept_handle单线程处理, 最大新建连接没有超过100万QPS(10的六次方)的情况下(目前4.6万新建连接QPS), 做出了简化.
适当简化的目的是为了高性能.

目前情况下, 由于我代码中accept_handle单线程处理, 任何一个连接, accept_time(微秒)都不相同.

cokeboL

一个包都不丢，是否包含了断电的情况？如果战时状态，电源别切断备用电源也用光或者挂了，在有包要发但尚未发完的时候断电了，这个包是不是就丢了

cokeboL

应该也存在网络不好有尚未处理完的包时另一方断掉的情况

对方挂了，这个包怎么处理，持久化的方式，下次对方再连上来再发？

不知道这种和断电的情况算不算丢包的范围

如果不算，那就是网络畅通为前提，那样的话，估计tcp不胜任的情况不多见吧

cokeboL

楼主啥时候写好了可否开源出来，学习研究一下