开发者社区> 问答> 正文

linux/unix的ipc能实现进程间传递文件描述符吗 400 请求报错 

最近搞个转发项目,但是服务端的并发性能优点瓶颈,在想办法来优化服务端的代码。初步设想改进方法如下:
整体方案:后台常驻进程2个;进程pro1负责监听,进程pro2负责具体转发工作
进程分工及进程间通信:
进程间通信方式:消息队列req_que(服务请求队列)
pro1:采用select方式监听,有请求链接上来后,accept建立联机套接字conn_fd,然后将链接套接字的请求read出来,send到消息队列req_que,继续select阻塞监听。
pro2:维护线程池;main里面轮询recv消息队列req_que,将读取到的msg交给线程去处理。
 但是问题出来了,这样的话pro1里面要先读请求msg,然后在send到req_que,然后pro2再从req_que里面recv得到msg,这个过程造成了没必要的资源浪费。然后就想能不能再pro1里面accept得到conn_fd后不处理read,然后将conn_fd通过req_que发给pro2,pro2把从req_que里面获取的conn_fd交给线程,线程从conn_fd里面直接read请求的msg,完成后续的交易处理;这样做的好处就是pro1可以节省出大量时间来处理监听,减轻io阻塞。能提高服务端性能。
 
问题:pro1和pro2属于不同的进程空间,每个进程拥有自己的进程资源,如果pro1直接将自己的fd发送给pro2,pro2是不能直接用的;有没有办法解决此问题呢??
 

展开
收起
kun坤 2020-05-30 16:11:01 550 0
1 条回答
写回答
取消 提交回答
  • 记得APUE里面有个用msghdr实现的send_fd######??能具体介绍下么,谢谢!!!###### 哈,楼主,我给你另外个方案的建议。
    你pro1 就是收发啦。当然收发的内容是放在共享mem里的,随后给pro2信号,让pro2处理收的数据,和准备发的数据,处理完毕后让pro1发。
    你说想减轻pro1的负担,不过端口中间的数据,无论谁读,谁写,总要折腾这个io,这个是免不了的。对一个端口io的总控不放在一个进程里,会折腾很多逻辑问题的。。简单才是好。哈。实在不行,协议里规定握手完毕后,分配权限,让客户端对另外一个端口建立链接,进行数据量较大的传输动作。 ######好吧,共享mem是一种方式,大家还有没有啥方案?综合下大家的智慧

    2020-05-30 16:11:05
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
Alibaba Cloud Linux 3 发布 立即下载
ECS系统指南之Linux系统诊断 立即下载
ECS运维指南 之 Linux系统诊断 立即下载