to： shootingstars(有容乃大，无欲则刚) 我向你sina.com的邮箱写信问了好像也没答复 就是双方如果都是内网，是不是只能用udp？有qq么？ 我想问你点关于你的文章的东西~to all 大家请看看《BT通信协议》一文有如下表述 Downloaders are periodically checking in with the tracker to keep it informed of their progress, and are uploading to and downloading from each other via direct connections. These connections use the BitTorrent peer protocol, which operates over TCP. 问中说下载端之间是建立的TCP连接，我想问问，难道说这些downloader之间难道都必须要是公网地址？如果按照 shootingstars(有容乃大，无欲则刚) 说法，是不是如果这些dowloader之间如果只有一个是公网地址，那么速度就跟普通的c/s模式一样了？因为不同nat后面的downloader之间是不能建立TCP连接的~ 小弟真的不怎么明白，还请各位吃教~
To flyfish99(菜鱼) 不好意思，我并没有收到你的邮件,不知道你是什么时候发送的? 还有关于P2P，我认为不一定是两个内网之间的计算机能够通讯才叫做P2P的系统（虽然，在中国，穿透NAT直接通信是P2P最吸引人的地方）。我认为P2P架构只是一种观念上的改变，即：用户不再需要一定借助某个中央服务器来通信，而可以直接的互相通信（虽然开始可能会需要一个服务器来知晓其他的Peer的信息） 关于BT，这种思想我想也并非独创，在很早以前就有一些ftp的软件可以从多个ftp服务器上下载同一个文件，只不过BT把这种思想与P2P结合了起来。 也许在国外，处于内网的用户并没有中国这么普遍，所以解决NAT穿透问题并不是一个那么重要的问题。当然，如果我们有激情，完全可以自己改造出一个可以穿透NAT的BT协议来。
to 回复人： flyfish99(菜鱼) 你的内网做seed的传输仿真过程，是你自己模拟的还是参考了bt的设计原理式样？至于你说内网用户不能和内网用户相连，我不知道你是怎么得到的结论，因为在用bt下载东西的时候，seed的个数和可连接用户的个数是不一致的。我的猜测是，各个内网用户可以通过有seed的那台机子建立连接，当然建立连接后，各内网机子间数据通讯就不再通过seed的那台机子了。
to shootingstars(有容乃大，无欲则刚) 想通了为什么不能用tcp协议了，呵呵，从头理了一下TCP与UDP在这儿的异同，确实有麻烦，感觉是需要硬件的支持~当然还不知道什么驱动程序有什么用，因为我不了解~ 我说的那个零时决定那个做server，即使双方同意了，也建立不起TCP的，呵呵，因为一个socket不能在listen的同时去打洞~我们能做的只能是用udp去模拟TCP的可靠性及其流量控制~这儿倒可以做一下~ 谢谢~
象qq tcp，udp都用！
我向你sina.com的邮箱写信问了好像也没答复
就是双方如果都是内网，是不是只能用udp？有qq么？
我想问你点关于你的文章的东西~to all
大家请看看《BT通信协议》一文有如下表述
Downloaders are periodically checking in with the tracker to keep it informed of their progress, and are uploading to and downloading from each other via direct connections. These connections use the BitTorrent peer protocol, which operates over TCP. 问中说下载端之间是建立的TCP连接，我想问问，难道说这些downloader之间难道都必须要是公网地址？如果按照
shootingstars(有容乃大，无欲则刚)
说法，是不是如果这些dowloader之间如果只有一个是公网地址，那么速度就跟普通的c/s模式一样了？因为不同nat后面的downloader之间是不能建立TCP连接的~
小弟真的不怎么明白，还请各位吃教~
下面是我摘录的一段，不知道是我理解有误还是本来它就不算什么peer_to_peer~也就是没有什么新东西，就是一个分布式文件传输系统~
-----------------------以下为原文----------------------------------------------
内网用户可以做Send的原理 上面说到服务器只会返回公网的ip的，那内网用户怎么可以做Send呢，这是因为BT是一个主动连接的软件（即使你已经下载完了，也不也会主动连接他人）下面是一个仿真流程： 1 内网用户开始做 seed，
2 服务器收到请求，由于是第一个所以也没有peer返回
3 公网用户提交请求，由于seed是内网用户所以也没有peer返回，等待下载，但服务器会把它的IP放到列表中
4 内网经过 interval 时间间隔后，再向服务器放出请求，得到上面得公网IP
5 得到公网IP后，内网马上进行连接
6 公网用户建立连接，数据开始传输 （注意现在是公网用户做服务器，内网用户做客户端，是不是有点怪）
7 其它内网用户去上面公网用户下载数据 所以，内网用户做 seed 一定要有公网用户得参与，否则其它内网用户无法下载。如果全部是内网用户，那个所有连接都不会成立，当然这是比较极端的情况。 以上可见，内网用户不能和内网用户连接，其它用户无法从服务器查到你，所以无法主动连接你，你只能每隔30分钟从服务器找到公网用户一个个进行连接。 由于中国很多用户的是内网用户（我从服务器上查回来的peer还没试过超过10个的），所以内网用户用BT的确要比公网用户要慢很多。
不好意思，我并没有收到你的邮件,不知道你是什么时候发送的? 还有关于P2P，我认为不一定是两个内网之间的计算机能够通讯才叫做P2P的系统（虽然，在中国，穿透NAT直接通信是P2P最吸引人的地方）。我认为P2P架构只是一种观念上的改变，即：用户不再需要一定借助某个中央服务器来通信，而可以直接的互相通信（虽然开始可能会需要一个服务器来知晓其他的Peer的信息） 关于BT，这种思想我想也并非独创，在很早以前就有一些ftp的软件可以从多个ftp服务器上下载同一个文件，只不过BT把这种思想与P2P结合了起来。
也许在国外，处于内网的用户并没有中国这么普遍，所以解决NAT穿透问题并不是一个那么重要的问题。当然，如果我们有激情，完全可以自己改造出一个可以穿透NAT的BT协议来。
今天收到邮件发送失败的消息了~
我想问问的是A，B为两内网用户，S为server
假设：
此时A，B都已经拥有了对方的公网IP与NAT对外端口
那么：
当A想跟B直连的时候，做以下动作：
1、A尝试直接向B发送udp数据包
2、等待B回应，若回应建立连接成功，否则下一步
3、A向S发出要求与B进行连接的请求
4、S要求B向A的IP打一个洞
5、B向A发出一个UDP数据包，为A打开一个洞
6、A通过这个洞口向B发送数据
这样就完成了整个连接过程~
上面所有过程都是用的udp协议~
您说如果B发送一个udp数据包到A就会在B本地NAT上面创建一个session，既在NAT表里面添加一条纪录，内容为B所对应的内网IP、端口与A的NAT的IP、端口影射关系
那么，为什么不能是发送TCP数据包呢？如果用tcp连接，是不是session的建立既NAT表的纪录添加不是从TCP连接的SYN开始的（syn开始一般不能到达A机）？或者说如果B向A发送一个TCP连接请求，如果B的NAT没有收到A的ack数据包，那么这个session就自动销毁，从而说两个内网用户开始不能用TCP连接？
那么如果在建立UDP连接以后呢，两者之间按理说应该建立TCP连接了吧？
我有点摸不着头脑了~
各位清楚的还不胜赐教~
我的qq：33244516
msn：[email protected]，[email protected]
一：首先我们不能使用一个TCP的套结字既连接到服务器又在本地Listen接收数据，实际上TCP的套接字分为三种功能：Connect,Listen,Stream。解决TCP连接就必须先解决类似对称NAT的问题。
二：A给B发送一个SYN，NAT B在收到这个消息以后（可能）会返回一个消息不可达的ICMP错误报文，NAT A在收到此ICMP报文后（可能）会关闭此Session，或者将此ICMP返回A，A在收到此ICMP报文后也会关闭此次连接。
反正由于每个连接双方都要有一个独立的socket来处理，那么完全可以在建立udp之后，通过协商，将一端作为server一端作为client把TCP连接建立起来啊~
这样好像可行，不象对称NAT问题那么难解决 的啊~
---------------------------------------------------
这个好像不行吧我原来也想过这么做，不过如果在Windows系统上，不使用驱动肯定不行，可惜我对驱动编程不熟悉，只好作罢。
想通了为什么不能用tcp协议了，呵呵，从头理了一下TCP与UDP在这儿的异同，确实有麻烦，感觉是需要硬件的支持~当然还不知道什么驱动程序有什么用，因为我不了解~
我说的那个零时决定那个做server，即使双方同意了，也建立不起TCP的，呵呵，因为一个socket不能在listen的同时去打洞~我们能做的只能是用udp去模拟TCP的可靠性及其流量控制~这儿倒可以做一下~
谢谢~