免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 3018 | 回复: 9

[C++] 请教一个udp服务器设计的问题 [复制链接]

论坛徽章:
0
发表于 2015-04-25 22:22 |显示全部楼层
最近在研究并发udp服务器的设计,考虑了以下三种模型

A.多线程处理同一个socket,阻塞模式,recvfrom完了sendto
B.多线程,每个线程创建一个socket,开启SO_REUSEPORT选项,所有线程共享一个地址,也是阻塞模式
C.多线程+epoll+非阻塞,每当客户端第一次请求时,就新建一个socket并connect到该客户端的地址,并将新的socket句柄加入epoll中,后续的读写操作都将有那个新的socket处理

第三种模型是比较奇怪,一般都是客户端connect服务端,我先解释下
之所以要用第三种模型,是因为我在unp 8.1 (UDP的connect函数)一节中看到,如果没有调用connect,每次recvfrom和sendto都会有额外的消耗,即内核每发一次包都会进行连接套接口和断开套接口

下面是我的问题
1. 我预期第模型C性能最高,但实测模型C性能最低,只有A的1/3左右
2. 我预期模型B应该比A高,毕竟使用了多个socket,至少内核中也会建立多个缓冲区,而且SO_REUSEPORT是linux内核3.x版本新出的为了改善性能一个选项,但实测性能跟第一种比较接近,但稳定性远远不如第一种,经常发生丢包现象
3.模型A是最稳定的,性能也几乎是最高的(这个还有待测试,我在家里的电脑上测的结果是比模型B略高,但在公司是比模型B略低)

下面是我的测试代码
https://github.com/sqfasd/ipractice/tree/master/net/socket

udp_server.cc 对应模型A
udp_server_ex.cc 对应模型C
udp_server_ex2.cc 对应模型B

望大家不吝赐教

论坛徽章:
289
射手座
日期:2013-08-23 12:04:38射手座
日期:2013-08-23 16:18:12未羊
日期:2013-08-30 14:33:15水瓶座
日期:2013-09-02 16:44:31摩羯座
日期:2013-09-25 09:33:52双子座
日期:2013-09-26 12:21:10金牛座
日期:2013-10-14 09:08:49申猴
日期:2013-10-16 13:09:43子鼠
日期:2013-10-17 23:23:19射手座
日期:2013-10-18 13:00:27金牛座
日期:2013-10-18 15:47:57午马
日期:2013-10-18 21:43:38
发表于 2015-04-25 22:54 |显示全部楼层
udp一般一个套接字就够了,更多的应该关注丢包怎么处理

论坛徽章:
36
子鼠
日期:2013-08-28 22:23:29黄金圣斗士
日期:2015-12-01 11:37:51程序设计版块每日发帖之星
日期:2015-12-14 06:20:00CU十四周年纪念徽章
日期:2015-12-22 16:50:40IT运维版块每日发帖之星
日期:2016-01-25 06:20:0015-16赛季CBA联赛之深圳
日期:2016-01-27 10:31:172016猴年福章徽章
日期:2016-02-18 15:30:3415-16赛季CBA联赛之福建
日期:2016-04-07 11:25:2215-16赛季CBA联赛之青岛
日期:2016-04-29 18:02:5915-16赛季CBA联赛之北控
日期:2016-06-20 17:38:50技术图书徽章
日期:2016-07-19 13:54:03程序设计版块每日发帖之星
日期:2016-08-21 06:20:00
发表于 2015-04-26 12:35 |显示全部楼层
以下拙见供参考:
    1.在一对一的场景中,阻塞效率高于非阻塞,非阻塞是为了保证一对多的场景中不让多等一。而且epoll要维护个内核事件表以及事件机制的额外开销
    2.B方案中传输层虽然各自一个sockfd,但源和目标都一样,协议栈打包到IP层的时候就已经归一了,最后出口都在网卡,reuse后的多个sockfd内
       核还要做些额外开销
      

论坛徽章:
0
发表于 2015-04-26 13:34 |显示全部楼层
cokeboL 发表于 2015-04-26 12:35
以下拙见供参考:
    1.在一对一的场景中,阻塞效率高于非阻塞,非阻塞是为了保证一对多的场景中不让多等 ...


多谢,很有帮助。
你怎么看unp8.1那节, 在udp服务器中,有没有必要让服务器反过来connect客户端,以减少每次recvfrom和sendto时的额外开销

论坛徽章:
36
子鼠
日期:2013-08-28 22:23:29黄金圣斗士
日期:2015-12-01 11:37:51程序设计版块每日发帖之星
日期:2015-12-14 06:20:00CU十四周年纪念徽章
日期:2015-12-22 16:50:40IT运维版块每日发帖之星
日期:2016-01-25 06:20:0015-16赛季CBA联赛之深圳
日期:2016-01-27 10:31:172016猴年福章徽章
日期:2016-02-18 15:30:3415-16赛季CBA联赛之福建
日期:2016-04-07 11:25:2215-16赛季CBA联赛之青岛
日期:2016-04-29 18:02:5915-16赛季CBA联赛之北控
日期:2016-06-20 17:38:50技术图书徽章
日期:2016-07-19 13:54:03程序设计版块每日发帖之星
日期:2016-08-21 06:20:00
发表于 2015-04-26 17:46 |显示全部楼层
回复 4# sqfasd

    一对一的话,connect当然省些,但是性能瓶颈估计也不差这点吧,如果性能上需求这一点,那可能已经是满载的情况,满载的话,丢包就悲催了
    多对一的情况没尝试过,reuse之后不知道需不需要进行同步,如果需要同步,那多个sockfd不如只用一个算了

论坛徽章:
4
水瓶座
日期:2013-09-06 12:27:30摩羯座
日期:2013-09-28 14:07:46处女座
日期:2013-10-24 14:25:01酉鸡
日期:2014-04-07 11:54:15
发表于 2015-04-27 11:24 |显示全部楼层
其实我用asio,lf模型很舒服。

论坛徽章:
12
2015年辞旧岁徽章
日期:2015-03-03 16:54:1515-16赛季CBA联赛之同曦
日期:2017-03-17 19:13:162016科比退役纪念章
日期:2016-11-07 08:28:12luobin
日期:2016-06-17 17:46:36wusuopu
日期:2016-06-17 17:43:4515-16赛季CBA联赛之福建
日期:2016-01-14 12:49:22程序设计版块每日发帖之星
日期:2015-12-13 06:20:00程序设计版块每日发帖之星
日期:2015-06-08 22:20:00程序设计版块每日发帖之星
日期:2015-06-08 22:20:002015年亚洲杯之科威特
日期:2015-03-24 14:21:272015年迎新春徽章
日期:2015-03-04 09:57:092016科比退役纪念章
日期:2018-04-10 16:20:18
发表于 2015-04-27 11:27 |显示全部楼层
回复 6# linux_c_py_php


    你们asio用得多吗?

论坛徽章:
3
2015年辞旧岁徽章
日期:2015-03-03 16:54:152015年迎新春徽章
日期:2015-03-04 09:49:032015年亚洲杯之中国
日期:2015-04-22 15:52:45
发表于 2015-04-27 13:51 |显示全部楼层
A最好, 如果A适合你的场景你就不要想别的方案.
你不是嫌弃A的解决方式太简单吧, 简单的就是最好的.
这个我们内部一般称之为"惊群模型", 其实不惊群啦....

B模型的楼上也说了, 一般不用多个socket, 用了只会降低效率.
C这个很奇葩, 什么sendto/recvfrom都要进行绑定?这个和协议栈实现有关系吧.
udp的这个开销应该非常之小, 还担心不到这里来.

论坛徽章:
0
发表于 2015-04-28 05:19 |显示全部楼层
hanxin83 发表于 2015-04-27 13:51
A最好, 如果A适合你的场景你就不要想别的方案.
你不是嫌弃A的解决方式太简单吧, 简单的就是最好的.
这个我 ...

嗯,看来是我把问题复杂化了
不过多研究研究也没坏处

论坛徽章:
0
发表于 2015-11-24 17:12 |显示全部楼层
B模型我记得以前试过,会导致只有最后绑定socket的线程才能recvfrom
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

DTCC2020中国数据库技术大会

【架构革新 高效可控】2020年12月21日-23日第十一届中国数据库技术大会将在北京隆重召开。

大会设置2大主会场,20+技术专场,将邀请超百位行业专家,重点围绕数据架构、AI与大数据、传统企业数据库实践和国产开源数据库等内容展开分享和探讨,为广大数据领域从业人士提供一场年度盛会和交流平台。

http://dtcc.it168.com


大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP