如何用WinSocket在两台不在同一局域网内的机子之间建立连接？(100分)

[blue]看过一些教程后，终于会用WinSocket了，能在局域网或广域网之间建立连接，但又有一个问题想问问各位大虾。
两台机子，用WinSocketClient,WinSocketServer,设置host和port,就可以建立连接，但如果一台在局域网内，和其他机子共用一个ip,host应该填什么？如果两个机子都在不同局域网内，又该怎么做？象QQ,网络游戏，都可以在不同网络间建立连接。我很是羡慕啊。[/blue]

做NAT吧

应该要有internet的网络标识吧,如果CS结构肯定要一个server的

帮顶一下。。。。。。。。。。。

我可以在同网间建立连接，但~只是~怎么穿过局域网啊？
顺便问个傻瓜问题，NAT是嘛呀？

NAT--网络服务端口映射

那一段别人翻译的东东出来给你看看。不过还没有实现代码。

3.2 逆向连接 (Connection reversal)
第二种技术是在只有一个客户位于middlebox后的条件下运用的。举例来说, 推想客户A在 NAT 后面但是客户 B 有一个全球有效的 IP 地址, 参照下面图表：

Server S
18.181.0.31:1235
|
|
+----------------------+----------------------+
| |
NAT A |
155.99.25.11:62000 |
| |
| |
Client A Client B
10.0.0.1:1234 138.76.29.7:1234

客户A有一个私有IP地址10.0.0.1，并且一个应用程序使用TCP端口1234。这个客户端和服务器S的公网IP地址18.181.0.31和端口1235建立了一个连接。NAT A为了客户端A和服务器S的会话，临时分配了一个终端地址，其TCP端口62000，它自己的IP地址是155.99.25.11：因此，服务器S认为客户端A用的是IP地址155.99.25.11，端口是62000。然而，客户端B有着自己的固定IP地址，138.76.29.7，并且在它上面的P2P应用程序可以在端口1234接收TCP连接。

现在推想客户端B想要与客户端A建立一个P2P连接会话。B可能用客户端A本身的地址，即10.0.0.1:1234，也可能用在服务器S上得到到的地址，155,99.25.11:62000，去尝试连接。然而无论在哪一种情况下，连接都会失败。第一种情况下，指向IP地址10.0.0.1的通讯包会被丢弃，因为10.0.0.1不是一个公网固定IP地址。第二种情况下，来自客户端B的TCP SYN请求包将会到达NAT A的62000端口，但NAT A将会拒绝这个请求，因为NAT A只允许向外发送数据。

在尝试和客户端A建立直接连接失败后，客户端B会利用服务器S传递一个请求，让客户端A去主动连接客户。客户端A在通过服务器S接收到传递的请求后，会使用客户端B的公共IP地址和端口建立一个TCP连接。 因为这个连接是在防火墙内部发起的，所以NAT A允许这个连接建立，而客户端B也能接收这个连接，因为它并不处于middlebox后面。当前实现P2P系统的一种技术，它有一个主要的局限性，就是它只能允许P2P中一方在NAT后面：而两方都在NAT后面的情况是很常见的，这种方法就会失败。因为这种逆向连接并不是解决问题的普遍方法，通常不推荐这个方法。应用程序可以选择试一试逆向连接，但当"向前"或"逆向"都不能建立连接时，应用程序应该能够自动的可以选择另外的连接机制，比如relaying(即3.1说的)。

3.3 UDP hole punching
第三种技术，也是这篇文章的一个重要点之一，就是被称为"UDP Hole Punching"的技术。当两个需要通讯的主机可能都在middlebox后面的时候，UDP hole punching依赖于cone NAT和普通防火墙的一些特性，允许合适的P2P应用程序以"punch holes"方式通过middlebox并且建立彼此之间直接的连接。这种技术在RFC 3027[NAT- PORT]的5.1节中简要的提及，并且在英特网[KEGEL]非证实的提到，也在最近的一些协议[TEREDO, ICE]中用到。正如名字中的所提到的，这种技术只能用于UDP连接。

我们将会考虑两个特别情况，并且考虑应用程序如何完善的处理两者之间的握手连接。第一种情况下，也是较为普通的情况，两个在不通的NAT后面的客户端要求直接的进行P2P连接。第二种情况，两台客户端位于同一个NAT后面，但不能肯定(两台客户端位于同一个NAT后面)。

3.3.1 位于不同NAT后面(Peers behind different NATs)
假设客户端A和B都有自己的私有IP地址，也都位于不同的NAT后面。P2P应用程序在A、B和服务器S上运行，用的都是UDP端口1234。A和B各自和服务器S建立UDP通讯连接，使NAT A为A的连接分配一个自己的公共端口62000，而NAT B为B的连接分配的是31000端口。

Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
155.99.25.11:62000 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234

现在推想一下，客户端A想要直接和B建立一个UDP通讯会话。假设A简单的发一个UDP信息包到B的公共地址138.76.29.7:31000，然而NAT B将会丢弃这些进入的数据信息(除非它是一个FULL cone NAT)，原因是NAT B和S已经建立的外部会话，而A发送的信息中的源地址和端口号是和S不匹配的(可以参照一下上面的内容，匹配才能接受)。同样，假如B发送一个条UDP数据包给A的公网地址，NAT A也会丢弃。

但是，假设A发出一个UDP数据信息给B的公网IP地址，同时也通过服务器S传递一个请求给B，要求B也发一个UDP信息给A的公网IP地址。A直接向B的公共IP地址(138.76.29.7:31000)发送的数据包会让NAT A在A的私有地址和B的公网地址之间建立了一个新的连接会话。同时，B到A的公网地址(155.99.25.11:62000)的信息会导致NAT B在B的私有地址和A的公共地址之间建立一个新的连接会话。一旦这种新的UDP连接在两者之间建立起来，客户端A和B就不需要服务器S的"介绍"就能彼此直接通讯了。

UDP hole punching技术有几个很有用的特点。一旦在两个位于middlebox后面的客户端建立了一个直接的P2P连接，在连接中的任何一方都可以扮演一个"介绍人"的角色，依次继续和另一个客户端建立连接，减少了最初的服务器S的负担。如果说有[STUN]的话，假如两个中的任意一个或两个都碰巧不在middlebox后面，上述应用程序将同样可以建立P2P通讯通道，应用程序不需要尝试明确middlebox的类型。Hole punching技术甚至可以自动的运用在多级NAT下面，多重NAT就是那些客户端需要经历多级地址转换才能进入公网。

听起来不错~不过我有点晕~哈哈~我慢慢理解，谢了

啊？我给错分了[]