特别说明，上篇（http://blog.csdn.net/guestcode/article/details/11911933）所举例子，在堵塞客户端和异步（iocp）服务端互相通信下出现过问题，但其他模型的通讯方式也不能保证没有问题。
连接握手：我们可以在Connect之后，发送握手协议包。主发方可以是服务器，也可是客户端。如果是服务器主发，一般是需要客户端把接收到的数据进行加密运算以后再发回服务器，服务器再验证客户端连接的合法性，比如手机卡（手机）和基站的入网验证。如果是客户端主发，一般是登录ID和密码之类的信息，比如游戏的用户登录。服务器验证之后，如何非法则可以直接断开连接不必给对方发送非法登录失败，客户端未得到返回应答数据包就被断开，应视为登录信息错误。当然，委婉一些可以返回失败数据包，有客户端自行断开，但这种方法可能会被恶意行为所利用：不断开但又不断发包，除非服务器有更严密的验证安全逻辑。
应答机制：这是数据通信安全保障的重要措施。发送方把发送数据放入队列，发送之后暂时不释放数据缓存，等待对方发送接收应答之后再释放，同时要有超时机制重复机制，超过规定范围应该记录失败数据并释放缓存。举例，发送方:Len+SndCmd+DataID+Datas+CRC，应答方：Len+AckCmd+DataID1+DataID2+......+CRC。
心跳机制：心跳有两种方式，一种是服务器主发，一种是客户端主发，服务端主发的客户端接收后会再转发给服务器，也就是无论如何，都必须有客户端发送给服务器的心跳数据包以便服务器做超时检验清除和释放相应的资源。如果要求高的实时体统，客户端主发给服务器，服务器再转发给客户端端，客户端自己也要检测超时，但心跳机制最大最重要的是保护服务器资源。在实现当中，也有可能设置了心跳还是经常被服务器断开的可能，比如双方都是以60秒为检测时长和发送周期，因为没有考虑网络延时。合理的设置方法是：假定网络最大延时是dt，客户端发送心跳周期是ct，那么服务器心跳检测周期应该是st=ct+dt，比如允许最大网络延时是5，客户端发送周期是30秒，那么服务器检测超时时长应该是35秒。
优雅断开：这是确保数据安全到达对方（应用逻辑层）手里或已经被对方处理的唯一方式。假如确保对方收到之后定能100%处理，那么就在接收的时候就可以发送应答包，否则一定等处理完了再发送应答包，这样处理过程如果出现异常还可以再次收到该数据包再次处理。那么应该如何优雅断开呢？就是在发送队列尾部加入一个节点标识为要断开这个链接了，当这个断开标识之前的数据都被应答或超市清除完毕之后，即可断开。或者把这个发送标识定义一个断开数据包发给对方，对方再返回同样的数据包之后即可断开。
在过去双方都使用堵塞方式（边读边处理同步方式）的时候，可能这些方式都是被笑为多此一举，即使是如此，安全的通讯方式也应该考虑上述方式，因为你无法确保网络和OS的正常运行。当然那些无关紧要数据通讯就另当别论了。
做和服务器的网络通讯应该充分考虑客户的网络环境和配置情况，比如棋牌等游戏类。这个时候我们还需要测速数据包，如果通讯严重超时的人应该T掉，以确保其他的正常通讯。
上篇和上述，也仅仅说明了网络通讯的基本协议要求而已。事实上，要做好网络通讯还需要更多的经验才能处理程序所带来的意想不到的问题。