P2P 即时通讯

linux 环境下高性能服务器的实现

背景介绍• 传统的即时通讯软件大多采用 C/S 模式

• 客户数量增加时服务器压力急剧增大

服务器转发

客户A 客户B

1 2

背景介绍• P2P 方式：服务器帮助客户之间建立连接后，

客户直接进行通讯

• 大大的减轻了集中式服务器的压力

服务器

客户A 客户B

1

2

3

背景介绍• 从传文件的速度可以看出 QQ 是 P2P 的

• MSN 和一些其他传统的即时通讯没有采取P2P 的方式，内网间传文件就没优势

关键技术• P2P 的实现依赖于客户端之间的互连，但由于

NAT与防火墙的存在，客户端之间无法直接建立连接

• 可见，如何实现内网穿越是实现 P2P 的一个关键

服务器

客户A 客户B

1

2

3

NAT

NAT 简介

穿越方案• 一、通讯双方只要有

一个在外网的情况：– 外连外和内连外都可以

之间连接– 外连内需要服务器改变

连接方向，让内去连外NAT

NAT

公网服务器

超级客户A

客户C 客户D客户E

1

3

4

2

穿越方案• 二、通讯双方处于不

同内网中：– 需要处于外网的客户中

继转发

NAT

NAT

NAT

公网服务器

超级客户A 超级客户B

客户C 客户D 客户E

客户F

1 23

4 5

穿越方案• 三、通讯双方在同一

内网中：– 考虑到多层的 NAT ，

同一内网中会出现上面两种情况

– 可以先用子网掩码进行基本的判断

– 尝试连接失败后再找外网客户转发

NAT

NAT

公网服务器

超级客户A

客户C 客户D客户E

1

3

42

系统需求• 一、基本的即时通讯功能：

– 注册、登录、下线、好友管理• 二、文件传输

– 体现 P2P 的优势

服务器框架设计注册模块

登录模块

好友管理

P2P请求模块

数据库

内存

数据库存储客户个人信息，好友关系内存中维护在线客户的临时信息

服务器框架设计• 客户数量与日俱增，服务器并发处理客户

的各种请求• 多进程 / 多线程？ 系统开销太大• select/poll IO 复用？效率提高了不少• epoll linux 内核实现的一种 IO 复用机制，

相比 select 不用轮询所有 fd ，相比 poll 速度更快

服务器框架设计• 出现的问题：

– 高速的 epoll 不能被某个客户阻塞，所有套接字都必须设置成非阻塞

– 数据库操作是阻塞的• 怎么办？

epoll 非阻塞 + 线程池架构

Epoll

2011-5-23

Thread1

2011-5-23

Thread2

Pip

e1

Pip

e2数据库操作交给线程池处理

非数据库操作直接在epoll事件中高速处理

epoll 非阻塞 + 线程池架构• 登录流程：

– 线程池里面只进行最基本的数据库查询

– 对共享资源 onlineList的操作放到单线程的 epoll 里面做

– 简化系统的逻辑

客户发起登录请求(UID, password)

Epoll将结果写回客户，如果登录成功，epoll中把该客户添加到onlineList中

Epoll将请求从pipe1写入线程池

线程池里面进行客户匹配，将结果从pipe2写回

epoll

客户端框架设计

后台侦听服务器发送的命令和客户的P2P连

接

接受处理用户命令

侦听P2P消息

侦听P2P消息

侦听P2P消息

客户端的压力比较小，使用多线程阻塞 IO 就可以了，而且便于实现

客户端框架设计• 客户端就是个遵纪守法的好公民，按照协议处理用户输入的命令，服务器发送的命令。。。

• 好公民还有着成为“冤大头”的潜在危险：– 对于处于外网或者相对外网的客户可能会需要

帮助内网客户进行中继

客户端框架设计• 客户端要维护一张 UI

D 和 fd 对应的表• P2P消息格式为 :

– <myUID, UID, msg>

• 中继客户通过查表完成转发 NAT

NAT

NAT

公网服务器

超级客户A 超级客户B

客户C 客户D 客户E

客户F

1 23

4 5

谢 谢