免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: mik
打印 上一主题 下一主题

大家讨论一下 IM 的实现结构和方案 [复制链接]

论坛徽章:
1
天秤座
日期:2014-04-27 07:42:20
91 [报告]
发表于 2009-07-08 14:16 |只看该作者
单服务器的IM很简单,无非就是通过协议传数据.但要支持同时在线几十万用户的,就不简单了.分布式计算中的事件同步和协调能要了你老命

论坛徽章:
1
天秤座
日期:2014-04-27 07:42:20
92 [报告]
发表于 2009-07-08 14:26 |只看该作者
原帖由 flw 于 2009-7-8 00:45 发表

你说的不错,TCP 穿越的关键点正是在这个地方。

你知道“同时打开”这个概念吗?
服务器 X 为 A 和 B 两个 client 做好时间同步,
A 和 B 同时向对方发起连接请求,只要时间偏移控制在 MSL 之内,
理论 ...



你这种办法在高延时的网络上会被自己搞死的,基本上没有应用的可能,而且只要上了V6,这种穿NAT的技术立马成为废物.........目前比较简单可靠的办法就是没有端口映射的客户端只能主动往具有端口映射的客户端发送和接收数据.无端口映射的客户端之间不能建立连接.具体请参考电驴/BT,这些都是有开源代码的.

论坛徽章:
5
2015年辞旧岁徽章
日期:2015-03-03 16:54:152015年迎新春徽章
日期:2015-03-04 09:53:172015亚冠之水原三星
日期:2015-06-02 16:34:202015年亚冠纪念徽章
日期:2015-10-19 18:13:37程序设计版块每日发帖之星
日期:2015-11-08 06:20:00
93 [报告]
发表于 2009-07-08 14:42 |只看该作者
原帖由 xhl 于 2009-7-8 13:31 发表
87楼的兄弟。  我没怎么看明白你的测试。

p2p的tcp也不是同时彼此都打开一条连接。 而是一个listen 一个connect.

至于说如何知道nat外面的地址, 有公用的协议, stun, turn 等, 都是判断自己的网络出口用 ...


你用我说的第一种方法看看能不能连上就知道了.  我只是说明这种情况下即便两边同时connect也能够建立连接.不需要一个listen一个connect.

下面最后一个图

img001.gif (2.2 KB, 下载次数: 42)

img001.gif

img002.gif (1.54 KB, 下载次数: 40)

img002.gif

img003.gif (1.84 KB, 下载次数: 47)

img003.gif

img004.gif (1.43 KB, 下载次数: 47)

img004.gif

论坛徽章:
0
94 [报告]
发表于 2009-07-08 14:51 |只看该作者
原帖由 xinglp 于 2009-7-8 14:42 发表


你用我说的第一种方法看看能不能连上就知道了.  我只是说明这种情况下即便两边同时connect也能够建立连接.不需要一个listen一个connect.

下面最后一个图



如果中间有nat, 我的印象是, 大部分nat都会拒绝外面直接进来的syn消息, 而只响应曾经出去过syn的目的地址发会来的ack. 除非是及特殊的21, 20 之类的port, 但也很多都不支持。

我没做过tcp穿透, 可能是我从理论上判断, 这个性价比太低, 没必要这样搞。 当然,这个如果能做好, 对穿firewall (block udp)的网络环境, 是很有好处的。

如果你实验出来了, 可以把经验分享给我。

论坛徽章:
1
2015年辞旧岁徽章
日期:2015-03-03 16:54:15
95 [报告]
发表于 2009-07-08 15:00 |只看该作者
【大部分nat都会拒绝外面直接进来的syn消息, 而只响应曾经出去过syn的目的地址发会来的ack】
这是必须的呀,
但是仅仅是这样的话,很容易穿越啊。

论坛徽章:
0
96 [报告]
发表于 2009-07-08 15:11 |只看该作者
原帖由 flw 于 2009-7-8 15:00 发表
【大部分nat都会拒绝外面直接进来的syn消息, 而只响应曾经出去过syn的目的地址发会来的ack】
这是必须的呀,
但是仅仅是这样的话,很容易穿越啊。



呵呵, 理论跟现实还是有差距的。 我明白你的意思。 但udp没seq, 无状态, 都很难做到很高的穿透率, tcp的就更不容易了,

a, b 中间有两个未知的设备在那里, 甚至更复杂, 用户在多层nat 后面, 实际用户的网络环境千齐百怪。

论坛徽章:
5
2015年辞旧岁徽章
日期:2015-03-03 16:54:152015年迎新春徽章
日期:2015-03-04 09:53:172015亚冠之水原三星
日期:2015-06-02 16:34:202015年亚冠纪念徽章
日期:2015-10-19 18:13:37程序设计版块每日发帖之星
日期:2015-11-08 06:20:00
97 [报告]
发表于 2009-07-08 15:17 |只看该作者

回复 #98 xhl 的帖子

我只是试验成功了单个socket的"回连"
不同socket的话修改tcp seq后应该也能连接成功.  
过nat没有试验过.   上面那四个图中后两个图两边的客户端是对称的

论坛徽章:
0
98 [报告]
发表于 2009-07-08 15:24 |只看该作者
我把帖子顶上来,大家继续,O(∩_∩)O~

最好讨论下分布式的服务器之间的通信机制和数据同步机制,我还没什么概念呢,非常感谢!

论坛徽章:
0
99 [报告]
发表于 2009-07-08 16:00 |只看该作者

回复 #92 xhl 的帖子

关键不在于时延是否“高”,而是是否稳定。如果足够稳定的话,事实上是时延越高越容易通过中间服务器的协调来保证syn和syn+ack的顺序。注意在两边真正发起尝试之前,应该和中间服务器做多次同步进行测试,原理和NTP类似。

当然,如果NAT加黑名单的规则非常苛刻,会减小成功率。但同样,这不能说绝对不能成功。事实上我试验过的大多数NAT,即使已经加过黑名单的IP,如果内部再次发出SYN的话,一般都会把目标IP从黑名单移除。给定这个前提,和中间服务器的协调过程可以大大简化。

论坛徽章:
0
100 [报告]
发表于 2009-07-08 16:58 |只看该作者
原帖由 4tar 于 2009-7-8 16:00 发表
关键不在于时延是否“高”,而是是否稳定。如果足够稳定的话,事实上是时延越高越容易通过中间服务器的协调来保证syn和syn+ack的顺序。注意在两边真正发起尝试之前,应该和中间服务器做多次同步进行测试,原理和 ...


你有作过这方面的应用? 有实际数据可以透漏吗?

我觉得不好做。 我举个例子。

                            s
                           /  \
                          a---b

client 到自己的nat的速度可能会受到自己机器的性能跟当时的带宽影响,  随时都可能变化

a经过nat 到达s 的速度比b经过nat到达s的速度快, 这个不代表a经过nat到达b的速度一定就比b经过nat到达a的速度快。

这一切都在非常快速的时间内完成, 要控制这个顺序, 首先s发信号, 通知a, b准备象对方发包, 这个信号到达a, b上的时间, 就无可控制。

接下来, a, b分别选择什么时间, 彼此发包, 是否彼此都经过自己的nat, 还没到达对方。

我觉得这做法, 只能是偶然能通, 撞大运。或者说, 上一次通了, 下一次可能都不通。


还有你刷黑名单, 也是要有顺序的, 必须两边同时刷, 否则形成恶性循环, 还是通不了。

[ 本帖最后由 xhl 于 2009-7-8 17:05 编辑 ]
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

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

清除 Cookies - ChinaUnix - Archiver - WAP - TOP