首先要明白：客户端的文件如果是最新的，那么创建时间肯定晚于服务器上文件的创建时间，反之客户端的文件就是旧的需要更新了，但是为了提高更新效率，并不是一个个和服务器上的文件做对比

而是建立一个文件列表索引文件，里面记录服务器上的“最新版”所有文件的创建时间，首先更新本地的索引文件，如果更新了，说明服务器上的文件列表有更新，然后和本地做对比，整理一份需要更新或新建的文件列表清单，然后主动连接服务器进行下载，全部完成以后，在索引文件进行记录，更新完一个就记录一个ok，这样方便“断点续传”，所有都更新完成，全部是ok了，就证明本地都是最新的了，不过这里面有个小问题是值得注意的，本地文件的创建时间不能是本地计算机的时间，应该下载完以后，修改成服务器的当前时间，（比如如果本地时间设置到了一年以前）那本地的列表可能永远都是旧的，每次都要更新，这是可怕的。

通过这个文件列表索引，能大大提高更新效率，而且也能做好版本的控制。

另外，更新服务器一般和游戏服务器分离，大致思路就是这样

打包和网络传输方面，自己封装一套序列化和反序列化的IO流协议就可以了，游戏里面这些都必须是最基本的功能了

当然，这套思路还有一些不完善的地方，比如更新正在运行的exe或一些内存保护的DLL，是比较麻烦的事情,需要尽量避免

ObjectStream
StreamBuffer
SerializeMap
PacketStruct
...

等等，有了前人的经验，似乎也算比较顺利，一个个从基本的数字，
到数组，到char[] (很多资料也称之为：raw 二进制序列)
再到STL 的一系列容器的序列化工作都实现了

其中大量使用了模版类的泛型设计，不必要求一个可序列化的类必须继承某某基类，只需要具备以下：

 SerializeTag ComputeTag();
 bool Read(ObjectStream& stream);
 bool Write(ObjectStream& stream);
 DWORD GetLength(ObjectStream& stream);
 bool operator==(const PacketHeader &other) const;

五个方法就可以了，如果随意给你一个事先定义好的类，可以实现序列化吗？当然可以，只需要写出该类的
Wrapped Proxy，再添加这5个方法，就能通过 ObjectStream 和 StreamBuffer 实现该类的序列化了

这些是写完成了，回头看看自己已经写好的网络逻辑模块，犯愁了。
唉……，加入序列化，相当于高层次的通讯协议全都变了，包结构要改，所有的业务逻辑通讯代码随之要改。

之前的工作…… 又要写大量的重构代码了。

重构真是件痛苦的事情。
最坏的打算把之前的一些逻辑东西按现有思路重写一遍嘛，二次加工也许能应祸得福，把破旧看不过眼的地方重整理的更漂亮，好比重新装修升级一样

现在，只能告诉自己一件事，沉下心，沉注气。

2.别以为有了序列化就不需要结构体
  表面上序列化代码量小，按顺序读和写char int short LPCSTR ... 就好，逻辑对象写不写都无所谓，那就是大错而特错了
  待序列化的对象发送前的结构还是不可省略的序列化的过程就是 object->(按一定顺序拆分)write->bytes->(按拆分顺序组装)read->object的过程
 其实object还是不能省略,很多人写网络程序不注重逻辑对象结构,收到的一堆bytes按一定顺序读和写就完事了,这样虽然灵活,但缺乏结构,容易造成混乱，调试起来是灾难
   所以结构体（或类）还是省略不了的，所以：别以为有了序列化，就不需要结构体了。

3.结构体存在内存对齐和CPU不兼容的问题，可以避免
  的确结构体是有内存对齐的问题,存在兼容性问题,我可以选择pack(1)把内存对齐给关闭掉,避免兼容性问题,既然选择了iocp就不打算跨平台了,可以避免结构体平台兼容的问题

4.结构体调试起来方便很多，减少内存拷贝，效率高
  不用序列化可write和read的过程就不需要过多考虑（少写太多代码了），read write 就好像现代社会每个人每天都要穿衣服和脱衣服一样，原始社会需要吗？其实人类进化到原始裸奔状态才是最爽快的:)
  但还是要说句公道话：有人说序列化编码解码read write 需要耗费资源, 诚然这个过程基本等于赋值和内存拷贝，那点效率损失主要还在内存拷贝上，这点效率损失很小，不能作为序列化的缺点，当然如果涉及到数据加密那将是另外一个话题

5.结构体貌似呆板，发送数据限制多，发送变长数据就不方便，数据组织起来也不灵活
  我想这是很多人抛弃结构体，选择用序列化方式发送和接受数据的一个很重要的原因
  但：其实对于变长结构(子结构也是变长)的问题,用结构体来实现的确很麻烦,但并不代表不能实现
  我已经实现了,而且读和写变长子结构体嵌套任意多层都不成问题,可以存储复杂变长的数据结构，
  数据就如同能自动序列化一样方便，这个应该是技术难点，但细心去做是可以实现的

6.关于结构体指针
  游戏里面要发送的数据内存事先分配好的，不存在指针,深度复制更不用考虑，所以内存拷贝不会出错
  如果用到指针即使用序列化来实现也会面临同样的问题也占不了多少便宜，由于C++这们语言的特点，
  不象java那样有个标准实现,对于序列化本身没有一个统一的标准，所以可想而知，有人说:boost有它的序列化的实现
  其实那个实现不见得就合适你自己，如果真要做序列化，编码和解码的仿照那个过程自己写才最为牢靠，
  哪些指针对应的内存需要序列化那些不需要序列化，是个逻辑结构，需要自己说了算才好（好像扯远了点）
  说回游戏数据，既然不用需要他用到指针，结构体用来发送数据也没问题的

7 平台扩充问题
  退一万步的说：换了语言就基本上换了客户端，客户端的数据组织形式都要重写
  实在不行还可以考虑用xml json 编码等等一些跨平台的解决方案，现在所写的结构体是可以用来做数据接收的，只是发送的不再是结构体而已

8.综上所述
  如果需要跨语言平台，不用序列化（二进制流或xml, json文本等等）根本无法实现
  序列化的优点还是非常多的.如果主要是跨平台和语言自定义读写规则,根据需要读写对象的某一部分数据,
  空间浪费少,不存在内存对齐问题等诸多优点，缺点就是拐弯抹角，代码量大，调试不方便

权衡了良久
  数据如果能组织的合理，而且没有跨语言平台的要求，用结构体也未尝不可,毕竟数据发送直来直去还是方便些，减少内存拷贝，效率也高了很多
  特别是调试起来容易太多了，衡量利弊我还是放弃了序列化，选择了原始的结构体，只是难在数据的组织（好在基本已经克服了）

我知道：序列化很好很强大，很多网络程序高手根本不屑于直接发一个逻辑结构体，用这种方式就好象是旁门左道，狗肉上不了大雅之堂一样，狗肉还是很多人喜欢吃的嘛，：）。

我还是返璞归真选择了结构体

一句话：物尽其用，用的恰当，够用就好。

如果有什么不对，敬请拍砖，莫要客气