倾城服务器源码解读（一）

第一次把代码解读写出来，可能不够理想还请大家包含。
对于游戏源码的欣赏，我一般只看一个地方通信层。所以我的解读也就只针对通信曾。当全部代码解读完后，我将对倾城通信层的设计与实现提出意见，以及希望各位高手也可以参加到讨论中来。文中有不正确，或我没有理解的地方请大家一起指出讨论，谢谢。
倾城的网络层server源码在deff.net和app.net下。
我是以消息对象为入口点开始分析的，在消息对象的设计中有如下几个接口。
MessageCodecFactory，MessageDecoder，MessageEncoder
以及如下实现类。
AppMessageCodecFactory，AppMessageDecoder，AppMessageEncoder
还有一个消息的model，Message类
因为我已经简单的看过了，这里边主要用到了一个倾城自己完成bytebuffer类，作为缓存。对消息进行读写。这篇文章我就主要说下bytebuffer类的作用。
bytebuffer类在daff.util下，在看到它这个包的时候我就在考虑一个问题。为什么它要重写那么多的类呢？bytebuffer在java的nio下已经完成了，我想它应该比我们自己重写要好的多把？下面我们一起来看看bytebuffer都完成了什么就明白了。
bytebuffer中有3个内部的全局变量
    private int readPos;
    private int writePos;
    private byte data[];
readPos代表读取指针位置，writePos代表写入指针位置，data数组是存储数据作用。
bytebuffer的构造函数总共有三个
    public ByteBuffer() {
        this(1024);
    }
    public ByteBuffer(int i) {
        data = new byte[i];
    }
    public ByteBuffer(byte abyte0[]) {
        this(abyte0, 0, abyte0.length);
    }
    public ByteBuffer(byte abyte0[], int i, int j) {
        data = abyte0;
        readPos = i;
        writePos = i + j;
    }
前两个构造函数完成的是对数组大小的初始化工作，分配1024个字节大小的空间给byte数组。后两个初始化的方法用在一个已经有数据的data数组情况下。
其他对此类中方法的解释，在附件中的java文件中，我已经对此类的方法做了一个大概的注释，大家可以自己下下来研究。