大家讨论一下 IM 的实现结构和方案

4tar

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

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

xhl

原帖由 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 编辑 ]

xhl

原帖由 aaronvox 于 2009-7-8 15:24 发表
我把帖子顶上来，大家继续，O(∩_∩)O~

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

这个是根据具体应用来的， web应用也做集群， 但基本都是用db同步。

设计是根据需求来做的， 没有通用的什么设计模式。

sohier

那不如把QQ给改一下
在自己内部使用算了

edigar

好帖，mark下

li_zero

学习了，一直关注多用户的服务器端分布式构架

leiing

来学习学习

4tar

原帖由 xhl 于 2009-7-8 16:58 发表


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

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

                            s
                           /  \
                          a---b

client 到自 ...

我的工作不是做这方面应用的，不过是很早前看Stevens的《TCP/IP Illustrated》时自己写了一些小程序来验证一些想法。因为缺乏环境，特地跑回学校机房去做了不少实验，当时几个留校的同学在帮助老师管理系机房

关于你的疑问，任意两个端点之间，只要时延相对稳定的话，做足够准确的估计不是难事。应该说这是个已解决的问题，《TCP/IP Illustrated》也有相关解释，不过我好久没翻了，一下子不能给你指出具体章节。有电子版的话可以搜索一下。

关于NAT的TCP穿越，我觉得真正的问题还是看在NAT内部对握手包的解析到了什么程度。NAT足够强大的话，可以做充分的解析来屏蔽穿越企图，甚至将内网机器也加入黑名单，这样刷黑名单也不再可能。但对于普通用户和一般企业所处的网络环境，应该不至于存在这样的问题。

还有就是不同NAT之间存在千千万万意想不到的细微区别，也可能导致穿越失败。不过我个人认为如果把目标设定在达到60%或70%的穿越成功率的话，还是可以实现的。

也许应该把以前的小程序找出来好好整理一下，毕竟实际代码胜过一万句空谈。好像前面的flw也在做这个？不知道测试成功率怎样？

xhl

原帖由 4tar 于 2009-7-9 10:51 发表


我的工作不是做这方面应用的，不过是很早前看Stevens的《TCP/IP Illustrated》时自己写了一些小程序来验证一些想法。因为缺乏环境，特地跑回学校机房去做了不少实验，当时几个留校的同学在帮助老师管理系机 ...

你想的太简单了， 呵呵， 我做了大概4年这样的工作， 而且是团队开发， 大概6个人的网络团队，

最后还是结合了几种情况， 达到95%以上的p2p,  其实我们一直在讨论nat,  在实际环境中， 还有个很致命的问题， 就是firewall, 包括用户自己的firewall 软件(很多firewall软件， 缺省也做地址转换， 有更很的， 连接代理)， 或者是nat除的网关firewall.  弄清楚用户的网络环境， 就要弄几个月， 例如， 我给你个课题， 如何测量出用户在几层nat后面？

我的意思只是告诉大家， 象qq做到的那样， 不是几句理论上的东西， 是几年的工作量跟实际调试测试修改。

你让几个人的机器能p2p不算什么， 能让10w用户的各种机器， 各种软硬件网络环境50%以上p2p, 不是几个月能搞定的， 测试你都测试不过来， 呵呵。

所以理论研究tcp穿越没问题， 但我不建议做实际生产， 个人认为目前的环境， 性价比太低。

其实关于tcp穿越， 我的观点就是理论上可行， 实际不可行。 不想在讨论了， 即使你自己弄出来能通， 你也没用户环境帮你测试。 3年前这样的demo我们都实现过。

其实关于p2p的部分， 我最占同skype的做法， 能直接穿网p2p的， 就直接穿， 不能直接穿的， 找supernode, 中转。  这个做法还有个技术难点， 就是如何找到物理或者网络临近的节点。

[ 本帖最后由 xhl 于 2009-7-9 11:34 编辑 ]

4tar

你提到的问题都存在，实际上就是重复了我之前的意思。1. NAT足够强大的话可以屏蔽穿越。在这个场景里，Firewall可以看做带超强解析/屏蔽能力的NAT; 2. 实际中各种NAT存在千千万万的细微差别可能导致穿越失败，解决这个问题只有靠测试驱动开发。这种规模的测试只有已拥有大量用户群体的P2P软件供应商才有条件，但反过来说，有这个条件的P2P软件供应商，做这个测试并不难，不存在技术上的障碍。关键是决策者是否愿意做。

另外你不断提到QQ，确实，做到QQ的规模，需要相当的技术积累。但根据我个人的经验和了解到的情况来看，QQ这些年的主要积累应该是在服务端的分布式应用上，而不是做P2P里的NAT穿越。

最后也说一下我的意思，就像你也同意的，就是这个东西理论上是可行的，如果有相应测试条件的厂商愿意去做的话，谁能说做成后（比如，70%的TCP NAT穿越）带来的收益就不能抵消甚至超过投入的成本呢？关键还是决策者如何考量各方面因素如潜在需求，收益期望，成本估计，==。再说下去就不是技术问题了，打住。