包括：
    “>> 右移”；“<< 左移”；“>>> 无符号右移”

例子：
-5>>3=-1
1111 1111 1111 1111 1111 1111 1111 1011
1111 1111 1111 1111 1111 1111 1111 1111
其结果与 Math.floor((double)-5/(2*2*2)) 完全相同。

-5<<3=-40
1111 1111 1111 1111 1111 1111 1111 1011
1111 1111 1111 1111 1111 1111 1101 1000
其结果与 -5*2*2*2 完全相同。

5>>3=0
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0000
其结果与 5/(2*2*2) 完全相同。

5<<3=40
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0010 1000
其结果与 5*2*2*2 完全相同。

-5>>>3=536870911     
1111 1111 1111 1111 1111 1111 1111 1011
0001 1111 1111 1111 1111 1111 1111 1111

无论正数、负数，它们的右移、左移、无符号右移 32 位都是其本身，比如 -5<<32=-5、-5>>32=-5、-5>>>32=-5。
一个有趣的现象是，把 1 左移 31 位再右移 31 位，其结果为 -1。
0000 0000 0000 0000 0000 0000 0000 0001
1000 0000 0000 0000 0000 0000 0000 0000
1111 1111 1111 1111 1111 1111 1111 1111

位逻辑运算符

    包括：
    & 与；| 或；~ 非（也叫做求反）；^ 异或

    “& 与”、“| 或”、“~ 非”是基本逻辑运算，由此可以演变出“与非”、“或非”、“与或非”复合逻辑运算。“^ 异或”是一种特殊的逻辑运算，对它求反可以得到“同或”，所以“同或”逻辑也叫“异或非”逻辑。

例子：
5&3=1
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0001

-5&3=1
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0011

5|3=7
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0111

-5|3=-5
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0011
1111 1111 1111 1111 1111 1111 1111 1011

~5=-6
0000 0000 0000 0000 0000 0000 0000 0101
1111 1111 1111 1111 1111 1111 1111 1010

~-5=4
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0100

5^3=6
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0110

Eclipse快速上手指南之使用ANT

以前对于ant的使用总是避而不触，总以为有点难度，最近一直看我们项目中的build.xml忽而觉得非常简单，也模仿着在我的www.javaedu.com开发上使用了一下，非常不错，以下是我的打包文件build.xml：

<?xml version="1.0"?>
 
<project name="payManager" default="all" basedir=".">
 
 <property name="src.dir"       value="JavaSource" />
 <property name="classes.dir"   value="WebContent/WEB-INF/classes" />
 <property name="lib.dir"       value="WebContent/WEB-INF/lib" />
 <property name="WebContent.dir"     value="WebContent" />
 
 <!--用于输出的临时文件夹与打包的文件夹-->
 <property name="temp.dir"     value="D:\temp" />
 <property name="war.dir"      value="D:\war" />

 <!--对于不同环境的war包，使用不同的配置文件-->
 <property name="生产.dir"     value="bak\生产" />
 <property name="开发.dir"     value="bak\开发" />
 
 <!-- 定义classpath -->
 <path id="master-classpath">
  <fileset file="${lib.dir}/*.jar" />
  <pathelement path="${classes.dir}" />
 </path>

 <target name="clean"> 
  <delete dir="${temp.dir}" />
  <delete dir="${classes.dir}" />
  <delete file="${war.dir}/开发/ROOT.war"/>
  <delete file="${war.dir}/生产/ROOT.war"/>
 </target>

 <!-- 初始化任务 -->
 <target name="init" depends="clean">
 </target>

 <!-- 编译 -->
 <target name="compile" depends="init" description="compile the source files">
  <mkdir dir="${temp.dir}/生产" />
  <mkdir dir="${temp.dir}/开发" />  
  <mkdir dir="${classes.dir}" />

  <javac srcdir="${src.dir}" destdir="${classes.dir}"  debug="true" encoding="GB2312">
   <classpath refid="master-classpath" />
  </javac>

  <copy todir="${temp.dir}/生产" overwrite="true">
   <fileset dir="${WebContent.dir}">
    <include name="**/**" />
   </fileset>
  </copy>
  
  <copy todir="${temp.dir}/生产/WEB-INF/classes" overwrite="true">
   <fileset dir="${生产.dir}">
    <include name="jlo_logging.xml" />
    <include name="log4j.properties" />
    <include name="mvncore.xml" />
    <include name="mvnForum_i18n_zh_CN.properties" />
    <include name="mvnforum.xml" />    
    <include name="whirlycache.xml" />
   </fileset>
  </copy>
  
  <copy todir="${temp.dir}/开发" overwrite="true">
   <fileset dir="${WebContent.dir}">
    <include name="**/**" />
   </fileset>
  </copy>
    
  <copy todir="${temp.dir}/开发/WEB-INF/classes" overwrite="true">
   <fileset dir="${开发.dir}">
    <include name="jlo_logging.xml" />
    <include name="log4j.properties" />
    <include name="mvncore.xml" />
    <include name="mvnForum_i18n_zh_CN.properties" />
    <include name="mvnforum.xml" />
    <include name="whirlycache.xml" />
   </fileset>
  </copy>
  
 </target>

 <!--打包-->
 <target name="war" depends="compile">
  <mkdir dir="${war.dir}/生产" />
  <mkdir dir="${war.dir}/开发" />
  
  <jar jarfile="${war.dir}/生产/ROOT.war">
   <fileset dir="${temp.dir}/生产">
    <include name="**/*" />
   </fileset>
  </jar>
  
  <jar jarfile="${war.dir}/开发/ROOT.war">
   <fileset dir="${temp.dir}/开发">
    <include name="**/*" />
   </fileset>
  </jar>
  
  <delete dir="${temp.dir}"/>
 </target>
 
 <target name="all" depends="war">
  <delete dir="${classes.dir}" />
  <delete dir="${temp.dir}" />
 </target>

</project>

值得注意的是，在书写build.xml的时候一定要小心，别写错了，我就是因为粗心，在写下面代码的时候：

   <fileset dir="${生产.dir}">
    .<include name="jlo_logging.xml" />
    <include name="log4j.properties" />
    <include name="mvncore.xml" />
    <include name="mvnForum_i18n_zh_CN.properties" />
    <include name="mvnforum.xml" />    
    <include name="whirlycache.xml" />
   </fileset>

不小心在红色代码前加了一个“.”，结果报了一个type   doesn't   support   nested   text   data.   的错，我找了半天没找出原因，到网上搜了一下竟然没有找到答案，后来才发现自己写错了，大汗，改正后，搞定，爽啊。是为记。

ANT的基本概念：Java的Makefile

当一个代码项目大了以后，每次重新编译，打包，测试等都会变得非常复杂而且重复，因此c语言中有make脚本来帮助这些工作的批量完成。在Java 中应用是平台无关性的，当然不会用平台相关的make脚本来完成这些批处理任务了，ANT本身就是这样一个流程脚本引擎，用于自动化调用程序完成项目的编 译，打包，测试等。除了基于JAVA是平台无关的外，脚本的格式是基于XML的，比make脚本来说还要好维护一些。

每个ant脚本（缺省叫build.xml）中设置了一系列任务(target)：比如对于一个一般的项目可能需要有以下任务。

• 任务1：usage 打印本脚本的帮助信息（缺省）
• 任务2：clean <-- init 清空初始化环境
• 任务3：javadoc <-- build <-- init 生成JAVADOC
• 任务4：jar <-- build <-- init 生成JAR
• 任务5：all <-- jar + javadoc <-- build <-- init 完成以上所有任务：jar javadoc

ANT的安装

ANT的使用

• 测试任务：JUnit测试
• 代码风格检查任务：CheckStyle，Jalopy等
• 邮件警报任务：可以把以上这些任务的输出警告发送到制定的用户列表中，这个任务可以设置每天自动运行。

出处：JDON.COM

Java的事件模式是动态响应系统重要的基础，在图形界面领域的事件模式已经有很多文章介绍，但是在服务器端我们会碰到更多的事件模式，这里本人试图总结一下：

　　事件直接驱动模式

　　事件模式的第一个要求就是性能的要求，需要直接而且快，Command模式是必须经常使用的，主要适合于迅速处理 前台的命令，Command模式往往是系统架构的重要部分，也是流程控制的主要模式。

　　Command模式经常Java的Reflect一起使用，因为系统的事件处理系统是处于动态变化的，随着功能要求扩展，就可能有动态变化事件 处理响应系统，以Struts中action为例，我们知道，Structs的一个主要配置文件是struts-config.xml 如下：

　　它实际是个command和event的映射关系，通过这个配置文件，运行时动态装载相应的Action，完成Command模式， 我们检查LoginAction代码，就可以看出Command模式的基本特征：

　　很明显，典型的Command模式需要有一个接口.接口中有一个统一的方法，这里统一的方法就是execute;

　　比如我们有个实时系统，客户段向服务器发出不同编码代号，意味着不同的请求，不同的请求有不同的Handler进行 处理，Handler接口是:

　　不同性质的处理过程继承这个Handler接口，如负责进入系统的处理过程

　　调用Handler时是:

　　以上是常用的一个事件驱动模式。它的特点是靠一个事件直接启动对应的事件处理器。

　　Chain of Responsibility职责链模式也应该属于这类，当事件到达后，让这个事件在我们提供的一批处理器中逐个挑选适合的处理器进行处理，这个模式缺点 是显然的，性能丧失在逐个挑选 上，一般不推荐使用，这个模式适合在我们无法预知发生的事件内容时使用，因为不知道发生事件的具体情况， 我们就无法在程序运行前事先为其指派相应的处理器，只能靠运行时，事件自己去摸索“撞运气”。

监控式事件模式

　　监控式事件模式就不同于事件直接驱动模式，它是借助第三者来监控和触发事件，这类事件的特点是： 有一个观察者置身事外在定期独立运行着，我们将我们要监听的事件向这个观察者注册，这样观察者就 代替我们来监听这个事件，应用客户端通过观察者来获得事件状况。

　　应用客户端有三种与观察者交互的方式：1.直接融合 2.推方式 3.拉方式。

　　直接融合就是说应用客户端自己就是观察者，两者融合，这样无疑应用客户端获得的触发时间是最快的。

　　推方式就是观察者一旦侦测到事件发生，立即将事件Push推到应用客户端；拉方式类似收取邮件，应用客户端在需要时才从观察者拉取事件。

　　JDK 1.4的None Blocking I/O是监控式事件模式的典型实现，Selector显然是一个监控I/O的第三者，当有外部事件进来，通过 调用Slector.select方法可以获得外部事件，从而进行处理，可参考我的本栏文章。

　　监控式事件模式适合使用在触发性质的场合，比如数据库后端触发器 界面触发 I/O触发 状态改变触发等。

　　我们以一个信件触发为例，这其实是个Observer应用例子:

　　比如用户提请服务器计算一个数据，如果用户同时要求将计算结果向自己信箱发一封，那么我们看如何设计？按照通常思维，这是一个次序问题，先在内 存中计算数据，然后将结果发送到他的信箱，最后返回结果到用户端，我们知道信件的发送是耗时的，因此，有可能网络的原因造成信件发送很慢，这是用户就一直 等不到他的计算结果，很显然，我们使用监控式事件模式来解决，让发信的事件由监控者去完成，只要需要时触发就可以了：

　　我们再来看监控观察者代码是如何写的？

　　这样服务器在执行compute方法时，就没有发送邮件的等待，一直接继续执行。

　　监控式事件模式和事件直接驱动模式可以在一个系统一起使用，外界信号通过事件直接驱动模式启动系统处理模块， 系统处理模块处理过程中，可以通过监控式事件模式来触发其它后台任务。这样一个架构非常适合实时处理系统。

　　既然事件处理模式是众多应用系统的基本模式，那么应该可以形成一个框架标准，JMX的notification Model就是这样一个架构设计。

　　JMX Notification Model

　　我们知道，JMX是提供了一种对MBean资源执行控制和配 置的管理机制，但这只是复杂的，分布式的系统中的一部分， 还有需要资源能够感应状态改变或者特定事件变化的机制，这就是JMX Notification Model。 在JMX Notification Model中均可以实现"事件直接驱动模式"和"监控式事件模式"，这取决于你的应用需求。

　　JMX Notification Model允许MBean通过调用notifications广播事件，接受者只要注册为一个listerner， JMX的 MBean notification model 将会激活这个listerner注册一次，然后将一直接受到 来自广播者发出的各种事件。

　　事件模式有三个角色，第一个是事件发出者producer 然后是事件接受者Consumer,第三个 是要传输的事件。JMX notification model也是这样分别依靠下列组件来实现这三个角色：

　　A. NotificationBroadcaster接口, 事件广播发出者， 这个接口允许监听者在需要发出的notification中注册他们感兴趣的事件。

　　B. 通用事件(Notification)，这是我们要传输的事件。 Notification事件能被直接使用，也能成为子类，这些都依赖于随同事件传输的信息。 通过使用通用事件类型，监听者将能接受来自广播者所有类型的事件。
　　
　　C. NotificationListener接口, 事件监听者或者接受者， 用于接受来自广播者的任何notification信号。

　　D. NotificationFilter接口, 这个接口为notification的监听者提供一个对发出事件的过滤器。

　　E. NotificationEmitter 接口, 扩展了NotificationBroadcaster接口，当删除监听者时允许更多的控制功能。

　　只要是MBean，就既可以成为notification的发布广播者，也可以成为notification的监听者接受者，或者同时两者都可以。

　　Attribute Change Notifications

　　Attribute Change Notifications是一种特殊的notification, 任何时候MBean属性attribute 被修改，外界能够被通知到。

　　在JMX架构中，MBean能够在属性attribute变化发生时，发出通知，关于诊断属性变化的机制以及触发 通知事件并不属于JMX规定部分，每个MBean可以有自己独立的实现方式。

　　Timer Service

　　Timer Service触发器是在规定的日期和事件发出通知，它能够一一个恒定的间隙不断重复发出通知， 通知可以发往所有注册为接受timer通知的对象，Timer Service也是一个可管理的MBean，允许应用系统设置 一个可配置的调度程度。

　　Monitoring

　　通过使用monitoring service，一个或多个MBean属性将按规定间隔时间被监视， 对于被观察的Mbean,监视器monitor将从它上面获得一个值，叫derived gauge，这个derived gauge可以是 被观察属性的原值，也可以是一个数字性属性连续被观察值之差。

　　当derived gauge值满足一系列条件时，每个monitor server将会发出一个特定类型的通知。 这些条件都是在monitor被初始化时设定的，也可以通过monitor MBean的管理接口动态设定。

　　根据MBean内部属性值类型有三种monitor:

　　A.CounterMonitor - 使用Java的整数类型来观察属性，有一个行为特征：

　　　a. 总是大于或等于零.

　　　b. 能自增.

　　　c. 能回滚.

　　B.GaugeMonitor - 使用java的整数或浮点类型观察属性。象gauge(测量仪器) 要么上升　要么下降减少。

　　C StringMonitor - 使用String类型观察属性.

　　事件处理架构

　　JMS是基于Socket的一种消息处理框架，原理类似于监控式事件模式，但是JMS已经把这种模式上升到架构的高度。不同JVM间也依靠JMS消息可以实现事件系统（注意是系统，不简单是一个小事件了）的触发和激活。

　　

　　从上面JMS的架构图可以看出事件三个角色Producer和Consumer以及事件信息本身Message．JMS就是在Producer和Consumer之间建立一个连接Connection．

　　JMS可实现同步或异步的事件触发机制，分别是通过Poin to Point(拉方式)和Pubilsh/Subscibe(推方式)具体完成，在分布式计算环境中，异步机制是非常重要，可以起到解耦作用，因为分布环境 中单点错误或通讯问题是经常发生的，整个分布式系统不能总是依靠同步机制来可靠地传递事件或notification．

　　由此可见，事件处理模式从Java诸多架构到我们具体应用程序，随处可见，根据不同的应用需求选择不同的事件处理模式，才能真正挖掘Java的潜在性能。

　　服务器的异常处理包括的内容非常广泛，本文仅就在网络封包方面出现的异常作一讨论，希望能对正从事相关工作的朋友有所帮助。

关于网络封包方面的异常，总体来说，可以分为两大类：一是封包格式出现异常；二是封包内容（即封包数据）出现异常。在封包格式的异常处理方面，我们在最 底端的网络数据包接收模块便可以加以处理。而对于封包数据内容出现的异常，只有依靠游戏本身的逻辑去加以判定和检验。游戏逻辑方面的异常处理，是随每个游 戏的不同而不同的，所以，本文随后的内容将重点阐述在网络数据包接收模块中的异常处理。

　　为方便以下的讨论，先明确两个概念（这两个概念是为了叙述方面，笔者自行取的，并无标准可言）：
　　1、逻辑包：指的是在应用层提交的数据包，一个完整的逻辑包可以表示一个确切的逻辑意义。比如登录包，它里面就可以含有用户名字段和密码字段。尽管它看上去也是一段缓冲区数据，但这个缓冲区里的各个区间是代表一定的逻辑意义的。
　　2、物理包：指的是使用recv(recvfrom)或wsarecv(wsarecvfrom)从网络底层接收到的数据包，这样收到的一个数据包，能不能表示一个完整的逻辑意义，要取决于它是通过UDP类的“数据报协议”发的包还是通过TCP类的“流协议”发的包。

我们知道，TCP是流协议，“流协议”与“数据报协议”的不同点在于：“数据报协议”中的一个网络包本身就是一个完整的逻辑包，也就是说，在应用层使用 sendto发送了一个逻辑包之后，在接收端通过recvfrom接收到的就是刚才使用sendto发送的那个逻辑包，这个包不会被分开发送，也不会与其 它的包放在一起发送。但对于TCP而言，TCP会根据网络状况和neagle算法，或者将一个逻辑包单独发送，或者将一个逻辑包分成若干次发送，或者会将 若干个逻辑包合在一起发送出去。正因为TCP在逻辑包处理方面的这种粘合性，要求我们在作基于TCP的应用时，一般都要编写相应的拼包、解包代码。

　　因此，基于TCP的上层应用，一般都要定义自己的包格式。TCP的封包定义中，除了具体的数据内容所代表的逻辑意义之外，第一步就是要确定以何种方式表示当前包的开始和结束。通常情况下，表示一个TCP逻辑包的开始和结束有两种方式：
　　1、以特殊的开始和结束标志表示，比如FF00表示开始，00FF表示结束。
　　2、直接以包长度来表示。比如可以用第一个字节表示包总长度，如果觉得这样的话包比较小，也可以用两个字节表示包长度。

　　下面将要给出的代码是以第2种方式定义的数据包，包长度以每个封包的前两个字节表示。我将结合着代码给出相关的解释和说明。

　　函数中用到的变量说明：

　　CLIENT_BUFFER_SIZE：缓冲区的长度，定义为：Const int CLIENT_BUFFER_SIZE=4096。
　　m_ClientDataBuf：数据整理缓冲区，每次收到的数据，都会先被复制到这个缓冲区的末尾，然后由下面的整理函数对这个缓冲区进行整理。它的定义是：char m_ClientDataBuf[2* CLIENT_BUFFER_SIZE]。
　　m_DataBufByteCount：数据整理缓冲区中当前剩余的未整理字节数。
　　GetPacketLen(const char*)：函数，可以根据传入的缓冲区首址按照应用层协议取出当前逻辑包的长度。
　　GetGamePacket(const char*, int)：函数，可以根据传入的缓冲区生成相应的游戏逻辑数据包。
　　AddToExeList(PBaseGamePacket)：函数，将指定的游戏逻辑数据包加入待处理的游戏逻辑数据包队列中，等待逻辑处理线程对其进行处理。
　　DATA_POS：指的是除了包长度、包类型等这些标志型字段之外，真正的数据包内容的起始位置。

Bool SplitFun(const char* pData,const int &len)
{
    PBaseGamePacket pGamePacket=NULL;
    __int64 startPos=0, prePos=0, i=0;
    int packetLen=0;

 　//先将本次收到的数据复制到整理缓冲区尾部
    startPos = m_DataBufByteCount;  
    memcpy( m_ClientDataBuf+startPos, pData, len );
    m_DataBufByteCount += len;   

    //当整理缓冲区内的字节数少于DATA_POS字节时，取不到长度信息则退出
　//注意：退出时并不置m_DataBufByteCount为0
    if (m_DataBufByteCount < DATA_POS+1)
        return false; 

    //根据正常逻辑，下面的情况不可能出现，为稳妥起见，还是加上
    if (m_DataBufByteCount >  2*CLIENT_BUFFER_SIZE)
    {
        //设置m_DataBufByteCount为0，意味着丢弃缓冲区中的现有数据
        m_DataBufByteCount = 0;

　　//可以考虑开放错误格式数据包的处理接口，处理逻辑交给上层
　　//OnPacketError()
        return false;
    }

     //还原起始指针
     startPos = 0;

     //只有当m_ClientDataBuf中的字节个数大于最小包长度时才能执行此语句
    packetLen = GetPacketLen( pIOCPClient->m_ClientDataBuf );

    //当逻辑层的包长度不合法时，则直接丢弃该包
    if ((packetLen < DATA_POS+1) || (packetLen > 2*CLIENT_BUFFER_SIZE))
    {
        m_DataBufByteCount = 0;

　　//OnPacketError()
        return false;
    }

    //保留整理缓冲区的末尾指针
    __int64 oldlen = m_DataBufByteCount; 

    while ((packetLen <= m_DataBufByteCount) && (m_DataBufByteCount>0))
    {
        //调用拼包逻辑，获取该缓冲区数据对应的数据包
        pGamePacket = GetGamePacket(m_ClientDataBuf+startPos, packetLen); 

        if (pGamePacket!=NULL)
        {
            //将数据包加入执行队列
            AddToExeList(pGamePacket);
        }

        pGamePacket = NULL;
 
　　//整理缓冲区的剩余字节数和新逻辑包的起始位置进行调整
        m_DataBufByteCount -= packetLen;
        startPos += packetLen; 

        //残留缓冲区的字节数少于一个正常包大小时，只向前复制该包随后退出
        if (m_DataBufByteCount < DATA_POS+1)
        {
            for(i=startPos; i<startPos+m_DataBufByteCount; ++i)
                m_ClientDataBuf[i-startPos] = m_ClientDataBuf[i];

            return true;
        }

        packetLen = GetPacketLen(m_ClientDataBuf + startPos );

         //当逻辑层的包长度不合法时，丢弃该包及缓冲区以后的包
        if ((packetLen<DATA_POS+1) || (packetLen>2*CLIENT_BUFFER_SIZE))
        {
            m_DataBufByteCount = 0;

    　　//OnPacketError()
            return false;
        }

         if (startPos+packetLen>=oldlen)
        {
            for(i=startPos; i<startPos+m_DataBufByteCount; ++i)
                m_ClientDataBuf[i-startPos] = m_ClientDataBuf[i];          

            return true;
        }
     }//取所有完整的包

     return true;
}

　　以上便是数据接收模块的处理函数，下面是几点简要说明：

　　1、用于拼包整理的缓冲区(m_ClientDataBuf)应该比recv中指定的接收缓冲区(pData)长度(CLIENT_BUFFER_SIZE)要大，通常前者是后者的2倍(2*CLIENT_BUFFER_SIZE)或更大。

　　2、为避免因为剩余数据前移而导致的额外开销，建议m_ClientDataBuf使用环形缓冲区实现。

3、为了避免出现无法拼装的包，我们约定每次发送的逻辑包，其单个逻辑包最大长度不可以超过CLIENT_BUFFER_SIZE的2倍。因为我们的整 理缓冲区只有2*CLIENT_BUFFER_SIZE这么长，更长的数据，我们将无法整理。这就要求在协议的设计上以及最终的发送函数的处理上要加上这 样的异常处理机制。

　　4、对于数据包过短或过长的包，我们通常的情况是置m_DataBufByteCount为0，即舍弃当前 包的处理。如果此处不设置m_DataBufByteCount为0也可，但该客户端只要发了一次格式错误的包，则其后继发过来的包则也将连带着产生格式 错误，如果设置m_DataBufByteCount为0，则可以比较好的避免后继的包受此包的格式错误影响。更好的作法是，在此处开放一个封包格式异常 的处理接口(OnPacketError)，由上层逻辑决定对这种异常如何处置。比如上层逻辑可以对封包格式方面出现的异常进行计数，如果错误的次数超过 一定的值，则可以断开该客户端的连接。