在网络应用服务器端, 为了性能和防止阻塞, 经常会把逻辑处理和I/O处理分离:
I/O网络线程处理I/O事件: 数据包的接收和发送, 连接的建立和维护等.
逻辑线程要对收到的数据包进行逻辑处理.

通常网络线程和逻辑线程之间是通过数据包队列来交换信息, 简单来说就是一个生产者-消费者模式.
这个队列是多个线程在共享访问必须加锁, 意味着每次访问都要加锁。如何更好的如何减少锁竞争次数呢 ?

方案一 双缓冲消息队列:

两个队列，一个给逻辑线程读，一个给IO线程用来写，当逻辑线程读完队列后会将自己的队列与IO线程的队列相调换。
IO线程每次写队列时都要加锁，逻辑线程在调换队列时也需要加锁，但逻辑线程在读队列时是不需要加锁的.

队列缓冲区的大小要根据数据量的大小进行调整的，如果缓冲区很小，就能更及时的处理数据，但吞吐量以及出现资源竞争的几率大多了。

可以给缓冲队列设置最大上限，超过上限的数量之后，将包丢弃不插入队列。
另外，双缓冲的实现也有不同策略的，

一是读操作优先，就是生产者只要发现空闲缓冲，马上swap，
二是写线程只有在当前的缓冲区写满了，才进行swap操作。
三是上层逻辑按照帧率来处理，每一帧的时候将双层缓冲队列调换一下，取一个队列来处理即可

方案二 提供一个队列容器:

提供一个队列容器，里面有多个队列，每个队列都可固定存放一定数量的消息。网络IO线程要给逻辑线程投递消息时，会从队列容器中取一个空队列来使用，直到将该队列填满后再放回容器中换另一个空队列。而逻辑线程取消息时是从队列容器中取一个有消息的队列来读取，处理完后清空队列再放回到容器中。

这样便使得只有在对队列容器进行操作时才需要加锁，而IO线程和逻辑线程在操作自己当前使用的队列时都不需要加锁，所以锁竞争的机会大大减少了。

这里为每个队列设了个最大消息数，看来好像是打算只有当IO线程写满队列时才会将其放回到容器中换另一个队列。那这样有时也会出现IO线程未写满一个队列，而逻辑线程又没有数据可处理的情况，特别是当数据量很少时可能会很容易出现[这个可以通过设置超时来处理, 如果当前时间-向队列放入第一个包的时间 > 50 ms, 就将其放回到容器中换另一个队列]。

通常我们逻辑服务器会以场景来划分线程,不同线程执行不同场景.一个线程可以执行多个场景.因为玩家属于场景,我们会把玩家数据,包括其缓冲池丢给场景 去处理.

            最先提出的是基本的NAT，它的产生基于如下事实：一个私有网络（域）中的节点中只有很少的节点需要与外网连接（呵呵，这是在上世纪90年代中期提出的）。那么这个子网中其实只有少数的节点需要全球唯一的IP地址，其他的节点的IP地址应该是可以重用的。
            因此，基本的NAT实现的功能很简单，在子网内使用一个保留的IP子网段，这些IP对外是不可见的。子网内只有少数一些IP地址可以对应到真正全球唯一的IP地址。如果这些节点需要访问外部网络，那么基本NAT就负责将这个节点的子网内IP转化为一个全球唯一的IP然后发送出去。(基本的NAT会改变IP包中的原IP地址，但是不会改变IP包中的端口)
            关于基本的NAT可以参看RFC 1631

            另外一种NAT叫做NAPT，从名称上我们也可以看得出，NAPT不但会改变经过这个NAT设备的IP数据报的IP地址，还会改变IP数据报的TCP/UDP端口。基本NAT的设备可能我们见的不多（呵呵，我没有见到过），NAPT才是我们真正讨论的主角。看下图：
            Server S1
            18.181.0.31:1235
            |
            ^ Session 1 (A-S1) ^ |
            | 18.181.0.31:1235 | |
            v 155.99.25.11:62000 v |
            |
            NAT
            155.99.25.11
            |
            ^ Session 1 (A-S1) ^ |
            | 18.181.0.31:1235 | |
            v 10.0.0.1:1234 v |
            |
            Client A
            10.0.0.1:1234
            有一个私有网络10.*.*.*，Client
            A是其中的一台计算机，这个网络的网关（一个NAT设备）的外网IP是155.99.25.11(应该还有一个内网的IP地址，比如10.0.0.10)。如果Client
            A中的某个进程（这个进程创建了一个UDP
            Socket,这个Socket绑定1234端口）想访问外网主机18.181.0.31的1235端口，那么当数据包通过NAT时会发生什么事情呢？
            首先NAT会改变这个数据包的原IP地址，改为155.99.25.11。接着NAT会为这个传输创建一个Session（Session是一个抽象的概念，如果是TCP，也许Session是由一个SYN包开始，以一个FIN包结束。而UDP呢，以这个IP的这个端口的第一个UDP开始，结束呢，呵呵，也许是几分钟，也许是几小时，这要看具体的实现了）并且给这个Session分配一个端口，比如62000，然后改变这个数据包的源端口为62000。所以本来是（10.0.0.1:1234->18.181.0.31:1235）的数据包到了互联网上变为了（155.99.25.11:62000->18.181.0.31:1235）。
            一旦NAT创建了一个Session后，NAT会记住62000端口对应的是10.0.0.1的1234端口，以后从18.181.0.31发送到62000端口的数据会被NAT自动的转发到10.0.0.1上。（注意：这里是说18.181.0.31发送到62000端口的数据会被转发，其他的IP发送到这个端口的数据将被NAT抛弃）这样Client
            A就与Server S1建立以了一个连接。

            呵呵，上面的基础知识可能很多人都知道了，那么下面是关键的部分了。
            看看下面的情况：
            Server S1 Server S2
            18.181.0.31:1235 138.76.29.7:1235
            | |
            | |
            +----------------------+----------------------+
            |
            ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
            | 18.181.0.31:1235 | | | 138.76.29.7:1235 |
            v 155.99.25.11:62000 v | v 155.99.25.11:62000 v
            |
            Cone NAT
            155.99.25.11
            |
            ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
            | 18.181.0.31:1235 | | | 138.76.29.7:1235 |
            v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
            |
            Client A
            10.0.0.1:1234
            接上面的例子，如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server
            S2发送了一个UDP包，那么这个UDP包在通过NAT时会怎么样呢？
            这时可能会有两种情况发生，一种是NAT再次创建一个Session，并且再次为这个Session分配一个端口号（比如：62001）。另外一种是NAT再次创建一个Session，但是不会新分配一个端口号，而是用原来分配的端口号62000。前一种NAT叫做Symmetric
            NAT，后一种叫做Cone
            NAT。我们期望我们的NAT是第二种，呵呵，如果你的NAT刚好是第一种，那么很可能会有很多P2P软件失灵。（可以庆幸的是，现在绝大多数的NAT属于后者，即Cone
            NAT）

            好了，我们看到，通过NAT,子网内的计算机向外连结是很容易的（NAT相当于透明的，子网内的和外网的计算机不用知道NAT的情况）。
            但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是P2P所需要的）。
            那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢？首先，我们必须在内网的NAT上打上一个“洞”（也就是前面我们说的在NAT上建立一个Session），这个洞不能由外部来打，只能由内网内的主机来打。而且这个洞是有方向的，比如从内部某台主机（比如：192.168.0.10）向外部的某个IP(比如：219.237.60.1)发送一个UDP包，那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”，（这就是称为UDP
            Hole
            Punching的技术）以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。（但是其他的IP不能利用这个洞）。

            呵呵，现在该轮到我们的正题P2P了。有了上面的理论，实现两个内网的主机通讯就差最后一步了：那就是鸡生蛋还是蛋生鸡的问题了，两边都无法主动发出连接请求，谁也不知道谁的公网地址，那我们如何来打这个洞呢？我们需要一个中间人来联系这两个内网主机。
            现在我们来看看一个P2P软件的流程，以下图为例：

            Server S （219.237.60.1）
            |
            |
            +----------------------+----------------------+
            | |
            NAT A (外网IP:202.187.45.3) NAT B (外网IP:187.34.1.56)
            | (内网IP:192.168.0.1) | (内网IP:192.168.0.1)
            | |
            Client A (192.168.0.20:4000) Client B (192.168.0.10:40000)

            首先，Client A登录服务器，NAT A为这次的Session分配了一个端口60000，那么Server S收到的Client
            A的地址是202.187.45.3:60000，这就是Client A的外网地址了。同样，Client B登录Server S，NAT
            B给此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。
            此时，Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client
            B，那么他可以从Server S那儿获得B的公网地址187.34.1.56:40000，是不是Client
            A向这个地址发送信息Client B就能收到了呢？答案是不行，因为如果这样发送信息，NAT
            B会将这个信息丢弃（因为这样的信息是不请自来的，为了安全，大多数NAT都会执行丢弃动作）。现在我们需要的是在NAT
            B上打一个方向为202.187.45.3（即Client A的外网地址）的洞，那么Client
            A发送到187.34.1.56:40000的信息,Client B就能收到了。这个打洞命令由谁来发呢，呵呵，当然是Server S。
            总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server
            S命令Client B向Client
            A方向打洞。呵呵，是不是很绕口，不过没关系，想一想就很清楚了，何况还有源代码呢（侯老师说过：在源代码面前没有秘密
            8）），然后Client A就可以通过Client B的外网地址与Client B通信了。

            注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client
            A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric
            NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。

             另一篇文章接上：

            下面解释一下上面的文章中没有提及或者说我觉得比较欠缺的地方.
             私有地址/端口和公有地址/端口:我们知道,现在大部分网络采用的都是NAPT(Network Address/Port Translator)了,这个东东的作用是一个对外的对话在经过NAT之后IP地址和端口号都会被改写,在这里把一次会话中客户自己认为在使用的IP地址和端口号成为私有地址/端口,而把经过NAPT之后被改写的IP地址和端口号称为公有地址/端口.或者可以这么理解,私有地址/端口是你家里人对你的昵称而公有地址/端口则是你真正对外公开的名字.如何获得用户的私用地址/端口号,这个很简单了,而要得到公有地址/端口号就要在连接上另一台机器之后由那台机器看到的IP地址和端口号来表示.

             如果明白了上面的东西,下面进入我们的代码,在这里解释一下关键部分的实现:

             客户端首先得到自己的私有地址/终端,然后向server端发送登陆请求,server端在得到这个请求之后就可以知道这个client端的公有地址/终端,server会为每一个登陆的client保存它们的私有地址/端口和公有地址/端口.

              OK,下面开始关键的打洞流程.假设client A要向client B对话,但是A不知道B的地址,即使知道根据NAT的原理这个对话在第一次会被拒绝,因为client B的NAT认为这是一个从没有过的外部发来的请求.这个时候,A如果发现自己没有保存B的地址,或者说发送给B的会话请求失败了,它会要求server端让B向A打一个洞,这个B->A的会话意义在于它使NAT B认为A的地址/端口是可以通过的地址/端口,这样A再向B发送对话的时候就不会再被NAT B拒绝了.打一个比方来说明打洞的过程,A想来B家做客,但是遭到了B的管家NAT B的拒绝,理由是:我从来没有听我家B提过你的名字,这时A找到了A,B都认识的朋友server,要求server给B报一个信,让B去跟管家说A是我的朋友,于是,B跟管家NAT B说,A是我认识的朋友,这样A的访问请求就不会再被管家NAT B所拒绝了.简而言之,UDP打洞就是一个通过server保存下来的地址使得彼此之间能够直接通信的过程,server只管帮助建立连接,在建立间接之后就不再介入了.

            下面是一个模拟P2P聊天的过程的源代码，过程很简单，P2PServer运行在一个拥有公网IP的计算机上，P2PClient运行在两个不同的NAT后（注意，如果两个客户端运行在一个NAT后，本程序很可能不能运行正常，这取决于你的NAT是否支持loopback
            translation，详见http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt，当然，此问题可以通过双方先尝试连接对方的内网IP来解决，但是这个代码只是为了验证原理，并没有处理这些问题），后登录的计算机可以获得先登录计算机的用户名，后登录的计算机通过send
            username message的格式来发送消息。如果发送成功，说明你已取得了直接与对方连接的成功。
            程序现在支持三个命令：send , getu , exit

            send格式：send username message
            功能：发送信息给username

            getu格式：getu
            功能：获得当前服务器用户列表

            exit格式：exit
            功能：注销与服务器的连接（服务器不会自动监测客户是否吊线）

            代码很短，相信很容易懂，如果有什么问题，可以给我发邮件zhouhuis22@sina.com
            或者在CSDN上发送短消息。同时，欢迎转发此文，但希望保留作者版权8-）。
            _05/04052509317298.rar"
            http://www.ppcn.net/upload/2004_05/04052509317298.rar 　

另一篇介绍打洞技术的（补充）

UDP打洞技术依赖于由公共防火墙和cone NAT，允许适当的有计划的端对端应用程序通过NAT"打洞"，即使当双方的主机都处于NAT之后。这种技术在 RFC3027的5.1节[NAT PROT] 中进行了重点介绍，并且在Internet[KEGEL]中进行了非正式的描叙，还应用到了最新的一些协议，例如[TEREDO,ICE]协议中。不过，我们要注意的是，"术"如其名，UDP打洞技术的可靠性全都要依赖于UDP。
这里将考虑两种典型场景，来介绍连接的双方应用程序如何按照计划的进行通信的，第一种场景，我们假设两个客户端都处于不同的NAT之后；第二种场景，我们假设两个客户端都处于同一个NAT之后，但是它们彼此都不知道(他们在同一个NAT中)。


 
处于不同NAT之后的客户端通信

    我们假设 Client A 和 Client B 都拥有自己的私有IP地址，并且都处在不同的NAT之后，端对端的程序运行于 CLIENT A,CLIENT B,S之间，并且它们都开放了UDP端口1234。 CLIENT A和CLIENT B首先分别与S建立通信会话，这时NAT A把它自己的UDP端口62000分配给CLIENT A与S的会话，NAT B也把自己的UDP端口31000分配给CLIENT B与S的会话。

假如这个时候 CLIENT A 想与 CLIENT B建立一条UDP通信直连，如果 CLIENT A只是简单的发送一个UDP信息到CLIENT B的公网地址138.76.29.7:31000的话，NAT B会不加考虑的将这个信息丢弃（除非NAT B是一个 full cone NAT），因为 这个UDP信息中所包含的地址信息，与CLIENT B和服务器S建立连接时存储在NAT B中的服务器S的地址信息不符。同样的，CLIENT B如果做同样的事情，发送的UDP信息也会被 NAT A 丢弃。

 假如 CLIENT A 开始发送一个 UDP 信息到 CLIENT B 的公网地址上，与此同时，他又通过S中转发送了一个邀请信息给CLIENT B，请求CLIENT B也给CLIENT A发送一个UDP信息到 CLIENT A的公网地址上。这时CLIENT A向CLIENT B的公网IP(138.76.29.7:31000)发送的信息导致 NAT A 打开一个处于 CLIENT A的私有地址和CLIENT B的公网地址之间的新的通信会话，与此同时，NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了，CLIENT A和CLIENT B之间就可以直接通信，而无需S来牵线搭桥了。(这就是所谓的打洞技术)！