<![CDATA[怨望森林]]> http://resentmenttree.blog.163.com zh-CN Thu, 28 Aug 2008 02:32:18 +0800 Thu, 28 Aug 2008 02:32:18 +0800 http://blogs.law.harvard.edu/tech/rss 120 <![CDATA[怨望森林]]> http://resentmenttree.blog.163.com/style/common/user_default.gif http://resentmenttree.blog.163.com <![CDATA[堆：欢乐和痛苦]]> http://resentmenttree.blog.163.com/blog/static/30080720200761910474333

Murali R. Krishnan
Microsoft Corporation

1999 年 2 月

摘要： 讨论常见的堆性能问题以及如何防范它们。

前言

您是否是动态分配的 C/C++ 对象忠实且幸运的用户？您是否在模块间的往返通信中频繁地使用了“自动化”？您的程序是否因堆分配而运行起来很慢？不仅仅您遇到这样的问题。几乎所有项目迟早都会遇到堆问题。大家都想说，“我的代码真正好，只是堆太慢”。那只是部分正确。更深入理解堆及其用法、以及会发生什么问题，是很有用的。

什么是堆？

（如果您已经知道什么是堆，可以跳到“什么是常见的堆性能问题？”部分）

在程序中，使用堆来动态分配和释放对象。在下列情况下，调用堆操作：

  1. 事先不知道程序所需对象的数量和大小。
  2. 对象太大而不适合堆栈分配程序。

堆使用了在运行时分配给代码和堆栈的内存之外的部分内存。下图给出了堆分配程序的不同层。

GlobalAlloc/GlobalFree：Microsoft Win32 堆调用，这些调用直接与每个进程的默认堆进行对话。

LocalAlloc/LocalFree：Win32 堆调用（为了与 Microsoft Windows NT 兼容），这些调用直接与每个进程的默认堆进行对话。

COM 的 IMalloc 分配程序（或 CoTaskMemAlloc / CoTaskMemFree）：函数使用每个进程的默认堆。自动化程序使用“组件对象模型 (COM)”的分配程序，而申请的程序使用每个进程堆。

C/C++ 运行时 (CRT) 分配程序：提供了 malloc() 和 free() 以及 new 和 delete 操作符。如 Microsoft Visual Basic 和 Java 等语言也提供了新的操作符并使用垃圾收集来代替堆。CRT 创建自己的私有堆，驻留在 Win32 堆的顶部。

Windows NT 中，Win32 堆是 Windows NT 运行时分配程序周围的薄层。所有 API 转发它们的请求给 NTDLL。

Windows NT 运行时分配程序提供 Windows NT 内的核心堆分配程序。它由具有 128 个大小从 8 到 1,024 字节的空闲列表的前端分配程序组成。后端分配程序使用虚拟内存来保留和提交页。

在图表的底部是“虚拟内存分配程序”，操作系统使用它来保留和提交页。所有分配程序使用虚拟内存进行数据的存取。

分配和释放块不就那么简单吗？为何花费这么长时间？

堆实现的注意事项

传统上，操作系统和运行时库是与堆的实现共存的。在一个进程的开始，操作系统创建一个默认堆，叫做“进程堆”。如果没有其他堆可使用，则块的分配使用“进程堆”。语言运行时也能在进程内创建单独的堆。（例如，C 运行时创建它自己的堆。）除这些专用的堆外，应用程序或许多已载入的动态链接库 (DLL) 之一可以创建和使用单独的堆。Win32 提供一整套 API 来创建和使用私有堆。有关堆函数（英文）的详尽指导，请参见 MSDN。

当应用程序或 DLL 创建私有堆时，这些堆存在于进程空间，并且在进程内是可访问的。从给定堆分配的数据将在同一个堆上释放。（不能从一个堆分配而在另一个堆释放。）

在所有虚拟内存系统中，堆驻留在操作系统的“虚拟内存管理器”的顶部。语言运行时堆也驻留在虚拟内存顶部。某些情况下，这些堆是操作系统堆中的层，而语言运行时堆则通过大块的分配来执行自己的内存管理。不使用操作系统堆，而使用虚拟内存函数更利于堆的分配和块的使用。

典型的堆实现由前、后端分配程序组成。前端分配程序维持固定大小块的空闲列表。对于一次分配调用，堆尝试从前端列表找到一个自由块。如果失败，堆被迫从后端（保留和提交虚拟内存）分配一个大块来满足请求。通用的实现有每块分配的开销，这将耗费执行周期，也减少了可使用的存储空间。

Knowledge Base 文章 Q10758，“用 calloc() 和 malloc() 管理内存” （搜索文章编号）, 包含了有关这些主题的更多背景知识。另外，有关堆实现和设计的详细讨论也可在下列著作中找到：“Dynamic Storage Allocation: A Survey and Critical Review”，作者 Paul R. Wilson、Mark S. Johnstone、Michael Neely 和 David Boles；“International Workshop on Memory Management”, 作者 Kinross, Scotland, UK, 1995 年 9 月(http://www.cs.utexas.edu/users/oops/papers.html)（英文）。

Windows NT 的实现（Windows NT 版本 4.0 和更新版本） 使用了 127 个大小从 8 到 1,024 字节的 8 字节对齐块空闲列表和一个“大块”列表。“大块”列表（空闲列表[0]） 保存大于 1,024 字节的块。空闲列表容纳了用双向链表链接在一起的对象。默认情况下，“进程堆”执行收集操作。（收集是将相邻空闲块合并成一个大块的操作。）收集耗费了额外的周期，但减少了堆块的内部碎片。

单一全局锁保护堆，防止多线程式的使用。（请参见“Server Performance and Scalability Killers”中的第一个注意事项, George Reilly 所著，在 “MSDN Online Web Workshop”上（站点：http://msdn.microsoft.com/workshop/server/iis/tencom.asp（英文）。）单一全局锁本质上是用来保护堆数据结构，防止跨多线程的随机存取。若堆操作太频繁，单一全局锁会对性能有不利的影响。

什么是常见的堆性能问题？

以下是您使用堆时会遇到的最常见问题：

  • 分配操作造成的速度减慢。光分配就耗费很长时间。最可能导致运行速度减慢原因是空闲列表没有块，所以运行时分配程序代码会耗费周期寻找较大的空闲块，或从后端分配程序分配新块。
  • 释放操作造成的速度减慢。释放操作耗费较多周期，主要是启用了收集操作。收集期间，每个释放操作“查找”它的相邻块，取出它们并构造成较大块，然后再把此较大块插入空闲列表。在查找期间，内存可能会随机碰到，从而导致高速缓存不能命中，性能降低。
  • 堆竞争造成的速度减慢。当两个或多个线程同时访问数据，而且一个线程继续进行之前必须等待另一个线程完成时就发生竞争。竞争总是导致麻烦；这也是目前多处理器系统遇到的最大问题。当大量使用内存块的应用程序或 DLL 以多线程方式运行（或运行于多处理器系统上）时将导致速度减慢。单一锁定的使用—常用的解决方案—意味着使用堆的所有操作是序列化的。当等待锁定时序列化会引起线程切换上下文。可以想象交叉路口闪烁的红灯处走走停停导致的速度减慢。

    竞争通常会导致线程和进程的上下文切换。上下文切换的开销是很大的，但开销更大的是数据从处理器高速缓存中丢失，以及后来线程复活时的数据重建。

  • 堆破坏造成的速度减慢。造成堆破坏的原因是应用程序对堆块的不正确使用。通常情形包括释放已释放的堆块或使用已释放的堆块，以及块的越界重写等明显问题。（破坏不在本文讨论范围之内。有关内存重写和泄漏等其他细节，请参见 Microsoft Visual C++(R) 调试文档 。）
  • 频繁的分配和重分配造成的速度减慢。这是使用脚本语言时非常普遍的现象。如字符串被反复分配，随重分配增长和释放。不要这样做，如果可能，尽量分配大字符串和使用缓冲区。另一种方法就是尽量少用连接操作。

竞争是在分配和释放操作中导致速度减慢的问题。理想情况下，希望使用没有竞争和快速分配/释放的堆。可惜，现在还没有这样的通用堆，也许将来会有。

在所有的服务器系统中（如 IIS、MSProxy、DatabaseStacks、网络服务器、 Exchange 和其他）, 堆锁定实在是个大瓶颈。处理器数越多，竞争就越会恶化。

尽量减少堆的使用

现在您明白使用堆时存在的问题了，难道您不想拥有能解决这些问题的超级魔棒吗？我可希望有。但没有魔法能使堆运行加快—因此不要期望在产品出货之前的最后一星期能够大为改观。如果提前规划堆策略，情况将会大大好转。调整使用堆的方法，减少对堆的操作是提高性能的良方。

如何减少使用堆操作？通过利用数据结构内的位置可减少堆操作的次数。请考虑下列实例：

struct ObjectA 
{ // objectA 的数据 } struct ObjectB 
{ // objectB 的数据 } 
// 同时使用 objectA 和 objectB 
// // 使用指针 // 
struct ObjectB 
{ struct ObjectA * pObjA; // objectB 的数据 }
 // // 使用嵌入 // 
struct ObjectB 
{ struct ObjectA pObjA; // objectB 的数据 } 
// // 集合 – 在另一对象内使用 objectA 和 objectB // 
struct ObjectX 
{ struct ObjectA objA; struct ObjectB objB; }
  1. 避免使用指针关联两个数据结构。如果使用指针关联两个数据结构，前面实例中的对象 A 和 B 将被分别分配和释放。这会增加额外开销—我们要避免这种做法。
  2. 把带指针的子对象嵌入父对象。当对象中有指针时，则意味着对象中有动态元素（百分之八十）和没有引用的新位置。嵌入增加了位置从而减少了进一步分配/释放的需求。这将提高应用程序的性能。
  3. 合并小对象形成大对象（聚合）。聚合减少分配和释放的块的数量。如果有几个开发者，各自开发设计的不同部分，则最终会有许多小对象需要合并。集成的挑战就是要找到正确的聚合边界。
  4. 内联缓冲区能够满足百分之八十的需要（aka 80-20 规则）。个别情况下，需要内存缓冲区来保存字符串/二进制数据，但事先不知道总字节数。估计并内联一个大小能满足百分之八十需要的缓冲区。对剩余的百分之二十，可以分配一个新的缓冲区和指向这个缓冲区的指针。这样，就减少分配和释放调用并增加数据的位置空间，从根本上提高代码的性能。
  5. 在块中分配对象（块化）。块化是以组的方式一次分配多个对象的方法。如果对列表的项连续跟踪，例如对一个 {名称，值} 对的列表，有两种选择：选择一是为每一个“名称-值”对分配一个节点；选择二是分配一个能容纳（如五个）“名称-值”对的结构。例如，一般情况下，如果存储四对，就可减少节点的数量，如果需要额外的空间数量，则使用附加的链表指针。

    块化是友好的处理器高速缓存，特别是对于 L1-高速缓存，因为它提供了增加的位置 —不用说对于块分配，很多数据块会在同一个虚拟页中。

  6. 正确使用 _amblksiz。C 运行时 (CRT) 有它的自定义前端分配程序，该分配程序从后端（Win32 堆）分配大小为 _amblksiz 的块。将 _amblksiz 设置为较高的值能潜在地减少对后端的调用次数。这只对广泛使用 CRT 的程序适用。

使用上述技术将获得的好处会因对象类型、大小及工作量而有所不同。但总能在性能和可升缩性方面有所收获。另一方面，代码会有点特殊，但如果经过深思熟虑，代码还是很容易管理的。

其他提高性能的技术

下面是一些提高速度的技术：

  1. 使用 Windows NT5 堆

    由于几个同事的努力和辛勤工作，1998 年初 Microsoft Windows(R) 2000 中有了几个重大改进：

    • 改进了堆代码内的锁定。堆代码对每堆一个锁。全局锁保护堆数据结构，防止多线程式的使用。但不幸的是，在高通信量的情况下，堆仍受困于全局锁，导致高竞争和低性能。Windows 2000 中，锁内代码的临界区将竞争的可能性减到最小,从而提高了可伸缩性。
    • 使用 “Lookaside”列表。堆数据结构对块的所有空闲项使用了大小在 8 到 1,024 字节（以 8-字节递增）的快速高速缓存。快速高速缓存最初保护在全局锁内。现在，使用 lookaside 列表来访问这些快速高速缓存空闲列表。这些列表不要求锁定，而是使用 64 位的互锁操作，因此提高了性能。
    • 内部数据结构算法也得到改进。

    这些改进避免了对分配高速缓存的需求，但不排除其他的优化。使用 Windows NT5 堆评估您的代码；它对小于 1,024 字节 (1 KB) 的块（来自前端分配程序的块）是最佳的。GlobalAlloc() 和 LocalAlloc() 建立在同一堆上，是存取每个进程堆的通用机制。如果希望获得高的局部性能，则使用 Heap(R) API 来存取每个进程堆，或为分配操作创建自己的堆。如果需要对大块操作，也可以直接使用 VirtualAlloc() / VirtualFree() 操作。

    上述改进已在 Windows 2000 beta 2 和 Windows NT 4.0 SP4 中使用。改进后，堆锁的竞争率显著降低。这使所有 Win32 堆的直接用户受益。CRT 堆建立于 Win32 堆的顶部，但它使用自己的小块堆，因而不能从 Windows NT 改进中受益。（Visual C++ 版本 6.0 也有改进的堆分配程序。）

  2. 使用分配高速缓存

    分配高速缓存允许高速缓存分配的块，以便将来重用。这能够减少对进程堆（或全局堆）的分配/释放调用的次数，也允许最大限度的重用曾经分配的块。另外，分配高速缓存允许收集统计信息,以便较好地理解对象在较高层次上的使用。

    典型地，自定义堆分配程序在进程堆的顶部实现。自定义堆分配程序与系统堆的行为很相似。主要的差别是它在进程堆的顶部为分配的对象提供高速缓存。高速缓存设计成一套固定大小（如 32 字节、64 字节、128 字节等）。这一个很好的策略，但这种自定义堆分配程序丢失与分配和释放的对象相关的“语义信息”。

    与自定义堆分配程序相反，“分配高速缓存”作为每类分配高速缓存来实现。除能够提供自定义堆分配程序的所有好处之外，它们还能够保留大量语义信息。每个分配高速缓存处理程序与一个目标二进制对象关联。它能够使用一套参数进行初始化，这些参数表示并发级别、对象大小和保持在空闲列表中的元素的数量等。分配高速缓存处理程序对象维持自己的私有空闲实体池（不超过指定的阀值）并使用私有保护锁。合在一起，分配高速缓存和私有锁减少了与主系统堆的通信量，因而提供了增加的并发、最大限度的重用和较高的可伸缩性。

    需要使用清理程序来定期检查所有分配高速缓存处理程序的活动情况并回收未用的资源。如果发现没有活动，将释放分配对象的池，从而提高性能。

    可以审核每个分配/释放活动。第一级信息包括对象、分配和释放调用的总数。通过查看它们的统计信息可以得出各个对象之间的语义关系。利用以上介绍的许多技术之一，这种关系可以用来减少内存分配。

    分配高速缓存也起到了调试助手的作用，帮助您跟踪没有完全清除的对象数量。通过查看动态堆栈返回踪迹和除没有清除的对象之外的签名，甚至能够找到确切的失败的调用者。

  3. MP 堆

    MP 堆是对多处理器友好的分布式分配的程序包，在 Win32 SDK（Windows NT 4.0 和更新版本）中可以得到。最初由 JVert 实现，此处堆抽象建立在 Win32 堆程序包的顶部。MP 堆创建多个 Win32 堆，并试图将分配调用分布到不同堆，以减少在所有单一锁上的竞争。

    本程序包是好的步骤 —一种改进的 MP-友好的自定义堆分配程序。但是，它不提供语义信息和缺乏统计功能。通常将 MP 堆作为 SDK 库来使用。如果使用这个 SDK 创建可重用组件，您将大大受益。但是，如果在每个 DLL 中建立这个 SDK 库，将增加工作设置。

  4. 重新思考算法和数据结构

    要在多处理器机器上伸缩，则算法、实现、数据结构和硬件必须动态伸缩。请看最经常分配和释放的数据结构。试问，“我能用不同的数据结构完成此工作吗？”例如，如果在应用程序初始化时加载了只读项的列表，这个列表不必是线性链接的列表。如果是动态分配的数组就非常好。动态分配的数组将减少内存中的堆块和碎片，从而增强性能。

    减少需要的小对象的数量减少堆分配程序的负载。例如，我们在服务器的关键处理路径上使用五个不同的对象，每个对象单独分配和释放。一起高速缓存这些对象，把堆调用从五个减少到一个，显著减少了堆的负载，特别当每秒钟处理 1,000 个以上的请求时。

    如果大量使用“Automation”结构，请考虑从主线代码中删除“Automation BSTR”，或至少避免重复的 BSTR 操作。（BSTR 连接导致过多的重分配和分配/释放操作。）

摘要

对所有平台往往都存在堆实现，因此有巨大的开销。每个单独代码都有特定的要求，但设计能采用本文讨论的基本理论来减少堆之间的相互作用。

  1. 评价您的代码中堆的使用。
  2. 改进您的代码，以使用较少的堆调用：分析关键路径和固定数据结构。
  3. 在实现自定义的包装程序之前使用量化堆调用成本的方法。
  4. 如果对性能不满意，请要求 OS 组改进堆。更多这类请求意味着对改进堆的更多关注。
  5. 要求 C 运行时组针对 OS 所提供的堆制作小巧的分配包装程序。随着 OS 堆的改进，C 运行时堆调用的成本将减小。
  6. 操作系统（Windows NT 家族）正在不断改进堆。请随时关注和利用这些改进。

Murali Krishnan 是 Internet Information Server (IIS) 组的首席软件设计工程师。从 1.0 版本开始他就设计 IIS，并成功发行了 1.0 版本到 4.0 版本。Murali 组织并领导 IIS 性能组三年 (1995-1998), 从一开始就影响 IIS 性能。他拥有威斯康星州 Madison 大学的 M.S.和印度 Anna 大学的 B.S.。工作之外，他喜欢阅读、打排球和家庭烹饪。

]]> http://resentmenttree.blog.163.com/blog/static/30080720200761910474333 0 http://resentmenttree.blog.163.com/blog/static/30080720200761910474333 Thu, 19 Jul 2007 10:47:04 +0800 2007-07-19T10:47:04+08:00 <![CDATA[德恩·多·波蒙(Le Chevalier d’Eon)的历史资料]]> http://resentmenttree.blog.163.com/blog/static/300807202007521102546859 真实的骑士—— 修巴利耶·德恩
“シュヴァリエ＝Chevalier”一词是法语“骑士”的意思。本作以十八世纪法国实际存在的天才美青年骑士德恩·多·波蒙波澜壮阔的一生为写照来进行动画创作。历史上，德恩接到了王下达的敕令，人们熟知他是一位来回奔走于各国之间的外交官。但是，他最为特异之处，就是“女装骑士”这一点了。把这样一位神秘叵测的人物和当时的史实放置穿插于故事的轴心之中，本作也并不能完全归纳于所谓的大河剧的范畴之内。

《Chelalier》主角历史原型--法国谍王戴戎
  在世界间谍战的历史中，法国谍王戴戎爵士（Chevolier，是一个十分传奇的人物。当间谍而被称为谍王，自有其过人之处。

在世界间谍战的历史中，法国谍王戴戎爵士（Chevolier，是一个十分传奇的人物。当间谍而被称为谍王，自有其过人之处。

戴戎的全名是查理士·日内维耶瓦·路易士·安德列·狄莫迪·戴戎·德博蒙。他出身于法国东尼雷城一个最低级的小贵族家庭。

戴戎在学校读书时，是一个成绩极优的学生，当其他同学还在开始学拉丁字母时，他已经在研究拉丁法律学了。他还只是一个孩子，就已获得法律博士学位。他的一篇关于法国金融财政的论文，震动了法国学术界。

戴戎个子不高，睫毛很长，面目俊秀，像个女孩子，但却是位出色的剑术家，在他的家乡，同学们选他当剑术学校的队长。

1750年，戴戎踌躇满志地来到巴黎。当时，法王路易十五正同他的群臣讨论戴戎的那篇著名论文。法王对大臣说：“这个戴戎，看来聪明绝顶，我们应该用这样一个聪明人当财政大臣才对。””“大臣点点头。当时的法国国库正连年债台高筑，越来越困难。于是，戴戎被召进宫。

法王用惊异的目光看着他，难道这个脸孔嫩如少女、天真无邪的小伙子，竟然就是一个著名的法律博士和财政专家吗？这简直使他无法置信
了。

但是，经过几分钟的交谈之后，证明戴戎并非等闲之辈。法王惊愕万分。

突然，路易十五觉得，让戴戎这样一个杰出人才关在国库之中运筹财经，未免大才小用，他要给他一个更重要的职位。法王把大臣们辞出，单独对戴戎说：“我想要你为法国完成一件极其重要的秘密使命。”

原来当时法王打探出一个惊人的消息：他的宿敌英王乔治二世正准备同俄国结成联盟，这样会使英国更强大，成为法国巨大的威胁。

法王屏退左右，对戴戎说道：“你得到俄国去，同女沙皇伊莉沙白单独交谈，不能让任何俄国人知道你是我的特使。当你有机会单独面见女沙皇时，就把我写的一封信给她。”

另外，法王还交给戴戎一份密码，要他设法亲手交给女沙皇，以便作为俄法之间秘密通讯之用。

男扮女装不久，一辆马车离开巴黎，不几天，已经到达德国城市安哈特城。

当马车进入安哈特城时，从车上走下来的却是一位令人神魂颠倒的少女：“米雅·德博蒙小姐”。没有人能想到“她”就是戴戎。

和他在一起的还有一个从瑞典来的老年法国人道格拉斯男爵，他自称为米雅小姐的伯父，实际上却是戴戎可靠的助手。道格拉斯到处说自己是经营皮革和矿业的商人。如果有人问起，他就向人解释说：“我希望访问某些波希米亚的矿场，也许甚至在回家之前，看看俄国巨大的皮革市场，不过我这次旅行完全是遵照医嘱，为了身体健康的原因。”说着就咳嗽一阵。

他们出尽风头，便挥手告别，取道北上了。

他们一路上有两件东西时刻不离身，一是由道格拉斯小心地放在口袋里的一个镶着珠宝的玳瑁鼻烟壶，另一样是米雅小姐随便到哪儿都带着的一本小书。这鼻烟壶有一个暗格，里面藏着通讯密码，而那本小书的羊皮封面里，藏着路易十五给女沙皇的亲笔信。

挨过千里草原的长途跋涉，他们终于到达了俄国首都圣彼得堡。

圣彼得堡塞满了外国间谍。有专业的，也有业余的，在舞会上寻欢作乐的贵族公子哥儿也在收集情报。俄国首相彼斯图切夫知道间谍很多，但他并不把间谍全部抓起来，而是建立起一支俄国自己的特务组织，严密监视所有的外国人，不让他们有机会接触女沙皇。他甚至在宫庭中也布置了特务，监视女沙皇的一举一动。他对她并不信任，因为女沙皇沉迷于荒淫无耻的生活，不关心国家大事，所以彼斯图切夫瞒着她同英国拉扯关系。

巴黎美人轰动了圣彼得堡，也引起了彼斯图切夫的注意，他下令特务们尽快探知来历，摸清底细。“小姐”被袭一天晚上，四个特务突然闯进道格拉斯和他“侄女”的寓所，其中三人在破门而入后，冲进道格拉斯的房间。被那三人按在床上的道格拉斯从床上挣扎着跳起来，挥拳还击，尽力自卫，但他赤手空拳，难敌三个持刀的特务。

与此同时，第四个特务已冲进“德博蒙小姐”的睡房。戴戎惊醒，一跃而起，把他时刻放在枕头底下的手枪拔出。随着枪声，特务倒地身亡。戴戎在特务手中夺过利剑，冲出房间，去救道格拉斯。

当时戴戎身穿睡袍，也没化装，他从房中跑出，使三个特务愕然：怎么“小姐”房中会跑出一个半裸的男人？说时迟，那时快，只见戴戎的利剑闪着寒光，猛然刺来。

第二天就是离境的最后期限，但仍没有被“召见”的信息。道格拉斯对戴戎说：“期限已到，看来我们不能违反彼斯图切夫的命令，否则他会以间谍罪名把我们关进死牢。”

戴戎说：“不，明天才走，今晚还有一个机会，不到最后一分钟不要绝望。”

天赐良机，就在当天傍晚，伏隆索夫副首相得意地陪伴美丽的“德博蒙小姐”进宫去见女沙皇。

女皇虽已上了年纪，但风韵犹存。她一见这位年轻的法国女宾，就把她拉到一边，很注意地同她交谈。

小姐说：“陛下的宫殿比凡尔赛宫还要华丽，这里的油画和塑像，比我见过的都要精美得多。”

女皇微笑了。因为当时欧洲人认为俄国是个落后国家，所以，多年来她请了世界各地的专家来装修宫殿，她特别喜欢客人称赞她的宫殿庭院能同外国媲美。“还有，陛下的袍服……请原谅我无礼，但我不能不说，实在是太漂亮了，外国皇后的服饰哪能同你相比啊！”

女皇又微笑了，她喜欢漂亮服装，并有15000件丝袍，5000双鞋，能受到一个巴黎女士的称赞，感到格外高兴。“我在巴黎时，听到不少奇谈，真是无奇不有，陛下愿听吗？”戴戎打出这张王牌，是因为他知道每天晚上女皇总要找几个女人到宫中去陪伴她，整夜不睡地同她们谈天说地。这是怎么回事呢？原来很多年前她是在半夜里夺取皇位的，从那时起，她一直害怕有人也在半夜来夺取她的皇位，因此，她已习惯整夜不睡，只准最信得过的人在夜里陪她。戴戎就希望能陪她过夜，完成使命。

后宫陪夜戴戎这一招果然生效。女皇最爱听是非，对世界各国的内幕新闻尤其感兴趣。

　她对戴戎说：“等宾客走后，你留下来，跟我进后宫去，把你在巴黎的见闻及所有最胡闹的故事都讲给我听！”

当晚，女皇便把戴戎留在后宫的密室中。

后宫的密室是安全的，即使是首相的密探也不能进入。当晚，第一晚戴戎不可能立即完成路易十五交给他的使命，他还需要时间。

时间在流逝，戴戎终于成了女皇的密友，进而竟发展为床上伴侣。当后来戴戎”“说出自己是个男子时，女皇不仅不生气，反而更加宠爱他，还要他改回男装，封他为御林军的统领，可以任意出入皇宫。

这时，首相彼斯图切夫已经没有办法了。

不久，英国的荷德纳斯公爵接到英国驻俄国大使的急信，信中说“我很遗憾地向您报告，首相彼斯图切夫发现有困难迫使女皇陛下签署那份我们急切需要得到的条约……”女皇洞悉彼斯图切夫的企图，拒绝签约，这说明戴戎的“使命”已告成功。

戴戎成了女皇的宠人，伏隆索夫得势了，彼斯图切夫的权力越来越小。

随着女皇同路易十五之间密件的来来往往，亲英派由此一蹶不振，英俄联盟成了空话。

虽然戴戎被女皇宠爱和重用，但他不愿长期当她的禁脔，于是离俄返国复命。

当他返回巴黎后，受到路易十五的欢迎和大加赏赐，每年给他3000金法郎年俸，而且经常派他作为法王私人代表到外国谈判，先后完成很多秘密的外交使命。有时他以戴戎爵士身份出现，有时又以“德博蒙小姐”出现，成了传奇人物，令人无法捉摸。

返回法国戴戎功劳越大，就越使法王的情妇蓬皮杜夫人嫉妒。

蓬皮杜夫人也是法国间谍史上有名的人物。她生怕法王爱上别的女人，私自建立起一支秘密警察部队，任命自己的亲信贝耶为警察中将，专门为她侦察情敌。后来发展到朝廷中的任何决策，都得由大臣们在她的住宅内先开会决定。她实际上掌握了当时法国的政治、经济和军事大权。

戴戎回国后，也曾得到蓬皮杜夫人的重用，但因他不甘心听命于这个狠毒的妇人，故转而参加了军队的谍报工作。

他作为法国驻英大使尼维纳斯伯爵的秘书被派往英国。当时法国首相正同英国首相比克福爵士谈判一项条约，以便拖延时间，作好同英国作战的准备。

戴戎的任务是刺探英国政府给比克福进行谈判时的具体指示。

说来难以相信，他轻而易举地获得了一份密件。有一天，比克福手下的一个官员到法国大使馆作礼节性拜会，他手中的一个公文包时时不离身，这引起了戴戎的注意。

戴戎不动声色地同那官员谈天，一边不断给他斟酒。他不知酒中有迷药，不一会便不省人事了。戴戎迅速打开公文包，将密件抄录了下来，那官员醒来见公文包原封未动，也就安心而走。

法国代表在谈判中利用得到的密件，迫使比克福不得不签订了条约，比克福还以为自己被英王乔治二世的宠臣首相布迪伯爵出卖了呢！

戴戎又立奇功，路易十五便给他以内阁大臣级的要职，就从那时起，蓬皮杜夫人开始憎恨他，要把他干掉。但戴戎已深知法国朝廷不是久留之地，于是自动要求到英国刺探英伦海峡的防御工事。

法国这次除派戴戎去英国外，还派了一位军事工程专家罗捷雷伯爵，这个伯爵对海岸工事进行了详细的调查研究，而戴戎只是充当路易十五与罗捷雷之间书信来往的中继人。

被迫出逃也许，从那时起，戴戎起了二心，他做了一件任何间谍也不会做的事：凡是法王与罗捷雷经他手传递的书信，他都抄录了副本，秘密收藏起来。

到1756年，英法之间爆发了“七年之战”。戴戎回到法国担任法军统帅德布洛利公爵的行营秘书，主管军事情报。他曾骑马冒着敌军炮火，押运军火，解救前线危急，扭转局势，反败为胜。

但他在法国的活动却在战后突然中断，因为蓬皮杜夫人已视他为眼中钉，故意将他的一个私敌派去做他的上司。戴戎盛怒之中，逃往英国。

他将过去秘密抄录的信件取出来勒索路易十五，如果不给他惊人数目的钱，他就公开揭露路易十五阴谋对付英国的秘密。但他并未得逞，法国派出不少特务到英国去杀他灭口。可是，戴戎也不好对付，不少特务都有去无回了。

法王无法，派了著名作家与外交家博马舍到英国同戴戎谈判，但戴戎还是发表了其中几封信，气得路易十五暴跳起来，随之戴戎也成了英国人很欢迎的知名人物。

最后，戴戎答应博马舍提出的要求，条件是法王不得再派人暗杀他，并给他一笔赔偿。在谈判中，路易十五驾崩，继任的路易十六深知再也不能让戴戎闹下去了，终于在1775年做出了让步，不再派人刺杀他，还迎他回国，只要不再发表那些密信就算了。

客死他乡戴戎于1777~1785年曾回法国居住了8年，这8年他是以女人身份出现的。以后在英国居住了25年。

法国大革命爆发，戴戎在英国取得政治庇护，长期居住在伦敦，时男时“女”地生活着。

对于戴戎的性别问题，在英国曾引起人们的极大兴趣，为他的性别打赌，赌注越来越大。1775年11月11日的《晨报》这样报道过：“伦敦城将因戴戎爵士的性别制订新的政策；目前的赌注是七对四赞成是女人不是男人，人们在争论不休，要求当事人在15天内解决这一难题。”但不管出现什么挑衅和侮辱，戴戎总是一笑置之，绝不讲出自己是男还是女。

1810年5月21日，戴戎以82岁高龄去世。“打赌”人为了赢得极高赌注，专门请了一个医生检查戴戎的尸体，以证实他的性别。

戴戎死前的5年，是同一个女人分住一层楼，当医生肯定戴戎是男性时，那女人晕了过去，因为她5年来一直把戴戎视为女人！

         
                    出自《世界间谍传》
]]> http://resentmenttree.blog.163.com/blog/static/300807202007521102546859 0 http://resentmenttree.blog.163.com/blog/static/300807202007521102546859 Thu, 21 Jun 2007 22:25:46 +0800 2007-06-22T09:41:43+08:00 <![CDATA[Deonde Beaumont]]> http://resentmenttree.blog.163.com/blog/static/300807202007516115110183

“作为骑士，应该追求最好的

但是，追求已失去的最好的，并不见得最好”

                                                             

                                                             ————Deonde Beaumont

                                                                                （1728—1810）

Deonde Beaumont 忠于国家的骑士 愿神与你同在

]]> http://resentmenttree.blog.163.com/blog/static/300807202007516115110183 0 http://resentmenttree.blog.163.com/blog/static/300807202007516115110183 Sat, 16 Jun 2007 23:51:10 +0800 2007-06-16T23:51:10+08:00 <![CDATA[游戏世界设定1]]> http://resentmenttree.blog.163.com/blog/static/3008072020075123344805

游戏有名字了，呵呵

Yggdrasil是服务器名字．
Freya是时装系统．

另外，考虑以后出现种族概念，先期为精灵和人类，可能还有矮人

]]> http://resentmenttree.blog.163.com/blog/static/3008072020075123344805 0 http://resentmenttree.blog.163.com/blog/static/3008072020075123344805 Tue, 12 Jun 2007 15:34:04 +0800 2007-06-12T15:34:04+08:00 <![CDATA[开发日志6——Login服务器基本功能完成]]> http://resentmenttree.blog.163.com/blog/static/30080720200742664017132     Login服务器基本功能完成，准备休息几天再开始写char服务器，顺便可以测试下Login服务器，看看还有什么需要改进的。呵呵 ]]> http://resentmenttree.blog.163.com/blog/static/30080720200742664017132 0 http://resentmenttree.blog.163.com/blog/static/30080720200742664017132 Sat, 26 May 2007 18:40:17 +0800 2007-06-12T15:34:30+08:00 <![CDATA[开发日志5——User Session问题等]]> http://resentmenttree.blog.163.com/blog/static/30080720200742635556507

    一个好的程序结构太重要了，细微调整了下iocp的工作方式，使一个wsasend完成后才进行下一个wsasend，减少部分无用的CRITICAL_SECTION。

   另外，参考了下网上的文章，在内存中建立User Session表还是需要的，目前构建结构和遍历方式中。

]]> http://resentmenttree.blog.163.com/blog/static/30080720200742635556507 0 http://resentmenttree.blog.163.com/blog/static/30080720200742635556507 Sat, 26 May 2007 15:55:56 +0800 2007-06-12T15:34:50+08:00 <![CDATA[开发日志4——关于iocp中的被截断数据包重发问题]]> http://resentmenttree.blog.163.com/blog/static/300807202007425112713216

    这个的问题终于搞明白了,原来是被网上提到的一些问题干扰了.对于发送缓冲区不为0的情况，所谓的发送数据不完整需要重发问题的过程如下：

1、wsasend发送大小为a的数据时，由于系统缓冲区满，发送缓冲区只能部分拷贝到系统缓冲区，wsasend返回已实际传送到系统缓冲区的大小b（b < a），需要发送剩余数据，但是为了保持非阻塞调用，暂时放弃。

2、工作线程GetQueuedCompletionStatus返回，BytesTransferred = b，由于b < a，为了保证数据发送完整，需要重发剩余长度为a - b的数据。

3、重复1、2的过程，直至数据发送完毕。

结论：

1、wsasend返回的实际发送数据大小b与GetQueuedCompletionStatus返回的BytesTransferred相等，也就是说GetQueuedCompletionStatus只有在提交的b大小的数据传送完后才会返回。

2、所谓的BytesTransferred小于wsasend发送大小a，是因为wsasend时系统缓冲区空间不足造成的，而不是GetQueuedCompletionStatus返回的BytesTransferred小于wsasend返回的已实际传送到系统缓冲区的大小b。

3、这种方式下，无法同时投递多个wsasend消息，投递多个wsasend消息可能导致传送数据被破坏，如wsasend发送ab+cd，可能会变成a+cd+b这样的结果。

我的解决办法：setsockopt(pIocpInfo->m_sock, SOL_SOCKET, SO_SNDBUF, (char *)&zero, sizeof(zero) );//设置发送缓冲区为0，这样可以保证1个包在发送过程中完整发送。

]]> http://resentmenttree.blog.163.com/blog/static/300807202007425112713216 0 http://resentmenttree.blog.163.com/blog/static/300807202007425112713216 Fri, 25 May 2007 23:27:13 +0800 2007-06-12T15:35:03+08:00 <![CDATA[IOCP cleanup. （IOCP清理）]]> http://resentmenttree.blog.163.com/blog/static/3008072020074255285439 The most important thing to remember when performing ICOP cleanup is the same when using overlapped I/O: do not free an overlapped structure if the I/O for it has not yet completed. The HasOverlappedIoCompleted macro allows you to detect if an I/O has completed from its overlapped structure.
切记很重要的一点，当执行使用重叠IO方式的IOCP的清理的时候，如果该I/O仍然没有完成的时候，不要释放重叠结构，HasOverlappedIoCompleted 宏允许你检测，一个I/O是否从它的重叠结构中完成了
There are typically two scenarios for shutting down a server. In the first scenario, you do not care about the completion status of outstanding I/Os and you just want to shut down as fast as you can. In the second scenario, you want to shut down the server, but you do need to know the completion status of each outstanding I/O.
有两种比较好的方案可以关闭一个服务端，第一种方案，你不需要关心未完成的I/O的完成状态，你只要尽可能快地关闭。第二种方案，你想关闭服务端，但是你必须知道每一个未完成的I/O的完成状态。
In the first scenario, you can call PostQueueCompletionStatus (N times, where N is the number of worker threads) to post a special completion packet that informs the worker thread to exit immediately, close all socket handles and their associated overlapped structures, and then close the completion port. Again, make sure you use HasOverlappedIoCompleted to check the completion status of an overlapped structure before you free it. If a socket is closed, all outstanding I/O on the socket eventually complete quickly.
在第一个方案中，你可以调用PostQueueCompletionStatus（N times(次)，这里的N是工作器线程的数量）投递一个指定的完成通知包通知工作器线程立即退出，关闭所有的套接字句柄和他们关联的重叠结构，并且关闭其对应的完成端口。再次在释放重叠结构之前用HasOverlappedIoCompleted 来检查和确认这个重叠结构的完成状态，如果套接字被关闭了，所有在这个套接字上的未完成的I/O最终很快会完成
In the second scenario, you can delay exiting worker threads so that all completion packets can be properly dequeued. You can start by closing all socket handles and the IOCP. However, you need to maintain a count of the number of outstanding I/Os so that your worker thread can know when it is safe to exit the thread. The performance penalty of having a global I/O counter protected with a critical section for an IOCP server is not as bad as might be expected because the active worker thread does not switch out if there are more completion packets waiting in the queue.
第二种方案，你可以延迟退出工作器线程，以便所有的完成通知包都能够出列。可以关闭所有套接字jub和IOCP句柄。然而，你需要维护一个未完成的I/O的计数器，以便你的工作器线程能够知道，它什么时候可以安全退出线程。
如果有很多完成通知包在队列中等待的话，激活的工作器线程将无法切换出去，由于这个原因，拥有一个被临界区保护的全局I/O计数器的IOCP服务器的性能将会急剧的下降并导致异常
]]> http://resentmenttree.blog.163.com/blog/static/3008072020074255285439 0 http://resentmenttree.blog.163.com/blog/static/3008072020074255285439 Fri, 25 May 2007 17:28:54 +0800 2007-05-25T17:28:54+08:00 <![CDATA[开发日志4]]> http://resentmenttree.blog.163.com/blog/static/3008072020074250613464

想了１天了，也翻了不少材料，还是始终没有想到一个好的解决方案．多线程的同步始终是件麻烦的事情，感觉互斥用的太多即麻烦又没有效率．缓冲区为０的wsasend消息，到底能不能一次发完，如果可以不做重发处理，就舒服多了．

]]> http://resentmenttree.blog.163.com/blog/static/3008072020074250613464 0 http://resentmenttree.blog.163.com/blog/static/3008072020074250613464 Fri, 25 May 2007 00:06:13 +0800 2007-05-25T17:30:30+08:00 <![CDATA[谁来负责管理缓冲区？]]> http://resentmenttree.blog.163.com/blog/static/30080720200742462720364

谁来负责管理缓冲区？

正如上面所说的，应用程序通过Winsock来和传输协议驱动程序交谈，而AFD.SYS负责为应用程序进行缓冲区管理。也就是说，当应用程序调用send()或WSASend()函数来发送数据时，AFD.SYS将把数据拷贝进它自己的内部缓冲区(取决于SO_SNDBUF设定值)，然后send()或WSASend()函数立即返回。也可以这么说，AFD.SYS在后台负责把数据发送出去。不过，如果应用程序要求发出的数据超过了SO_SNDBUF设定的缓冲区大小，那么WSASend()函数会阻塞，直至所有数据发送完毕。

从远程客户端接收数据的情况也类似。只要不用从应用程序那里接收大量的数据，而且没有超出SO_RCVBUF设定的值，AFD.SYS将把数据先拷贝到其内部缓冲区中。当应用程序调用recv()或WSARecv()函数时，数据将从内部缓冲拷贝到应用程序提供的缓冲区。

多数情况下，这样的架构运行良好，特别在是应用程序采用传统的套接字下非重叠的send()和receive()模式编写的时候。不过程序员要小心的是，尽管可以通过setsockopt()这个API来把SO_SNDBUF和SO_RCVBUF选项值设成0(关闭内部缓冲区)，但是程序员必须十分清楚把AFD.SYS的内部缓冲区关掉会造成什么后果，避免收发数据时有关的缓冲区拷贝可能引起的系统崩溃。

举例来说，一个应用程序通过设定SO_SNDBUF为0把缓冲区关闭，然后发出一个阻塞send()调用。在这样的情况下，系统内核会把应用程序的缓冲区锁定，直到接收方确认收到了整个缓冲区后send()调用才返回。似乎这是一种判定你的数据是否已经为对方全部收到的简洁的方法，实际上却并非如此。想想看，即使远端TCP通知数据已经收到，其实也根本不代表数据已经成功送给客户端应用程序，比如对方可能发生资源不足的情况，导致AFD.SYS不能把数据拷贝给应用程序。另一个更要紧的问题是，在每个线程中每次只能进行一次发送调用，效率极其低下。

把SO_RCVBUF设为0，关闭AFD.SYS的接收缓冲区也不能让性能得到提升，这只会迫使接收到的数据在比Winsock更低的层次进行缓冲，当你发出receive调用时，同样要进行缓冲区拷贝，因此你本来想避免缓冲区拷贝的阴谋不会得逞。

现在我们应该清楚了，关闭缓冲区对于多数应用程序而言并不是什么好主意。只要要应用程序注意随时在某个连接上保持几个WSARecvs重叠调用，那么通常没有必要关闭接收缓冲区。如果AFD.SYS总是有由应用程序提供的缓冲区可用，那么它将没有必要使用内部缓冲区。

高性能的服务器应用程序可以关闭发送缓冲区，同时不会损失性能。不过，这样的应用程序必须十分小心，保证它总是发出多个重叠发送调用，而不是等待某个重叠发送结束了才发出下一个。如果应用程序是按一个发完再发下一个的顺序来操作，那浪费掉两次发送中间的空档时间，总之是要保证传输驱动程序在发送完一个缓冲区后，立刻可以转向另一个缓冲区。

资源的限制条件

在设计任何服务器应用程序时，其强健性是主要的目标。也就是说，

你的应用程序要能够应对任何突发的问题，例如并发客户请求数达到峰值、可用内存临时出现不足、以及其它短时间的现象。这就要求程序的设计者注意Windows NT和2000系统下的资源限制条件的问题，从容地处理突发性事件。

你可以直接控制的、最基本的资源就是网络带宽。通常，使用用户数据报协议(UDP)的应用程序都可能会比较注意带宽方面的限制，以最大限度地减少包的丢失。然而，在使用TCP连接时，服务器必须十分小心地控制好，防止网络带宽过载超过一定的时间，否则将需要重发大量的包或造成大量连接中断。关于带宽管理的方法应根据不同的应用程序而定，这超出了本文讨论的范围。

虚拟内存的使用也必须很小心地管理。通过谨慎地申请和释放内存，或者应用lookaside lists(一种高速缓存)技术来重新使用已分配的内存，将有助于控制服务器应用程序的内存开销(原文为“让服务器应用程序留下的脚印小一点”)，避免操作系统频繁地将应用程序申请的物理内存交换到虚拟内存中(原文为“让操作系统能够总是把更多的应用程序地址空间更多地保留在内存中”)。你也可以通过SetWorkingSetSize()这个Win32 API让操作系统分配给你的应用程序更多的物理内存。

在使用Winsock时还可能碰到另外两个非直接的资源不足情况。一个是被锁定的内存页面的极限。如果你把AFD.SYS的缓冲关闭，当应用程序收发数据时，应用程序缓冲区的所有页面将被锁定到物理内存中。这是因为内核驱动程序需要访问这些内存，在此期间这些页面不能交换出去。如果操作系统需要给其它应用程序分配一些可分页的物理内存，而又没有足够的内存时就会发生问题。我们的目标是要防止写出一个病态的、锁定所有物理内存、让系统崩溃的程序。也就是说，你的程序锁定内存时，不要超出系统规定的内存分页极限。

在Windows NT和2000系统上，所有应用程序总共可以锁定的内存大约是物理内存的1/8(不过这只是一个大概的估计，不是你计算内存的依据)。如果你的应用程序不注意这一点，当你的发出太多的重叠收发调用，而且I/O没来得及完成时，就可能偶尔发生ERROR_INSUFFICIENT_RESOURCES的错误。在这种情况下你要避免过度锁定内存。同时要注意，系统会锁定包含你的缓冲区所在的整个内存页面，因此缓冲区靠近页边界时是有代价的(译者理解，缓冲区如果正好超过页面边界，那怕是1个字节，超出的这个字节所在的页面也会被锁定)。

另外一个限制是你的程序可能会遇到系统未分页池资源不足的情况。所谓未分页池是一块永远不被交换出去的内存区域，这块内存用来存储一些供各种内核组件访问的数据，其中有的内核组件是不能访问那些被交换出去的页面空间的。Windows NT和2000的驱动程序能够从这个特定的未分页池分配内存。

当应用程序创建一个套接字(或者是类似的打开某个文件)时，内核会从未分页池中分配一定数量的内存，而且在绑定、连接套接字时，内核又会从未分页池中再分配一些内存。当你注意观察这种行为时你将发现，如果你发出某些I/O请求时(例如收发数据)，你会从未分页池里再分配多一些内存(比如要追踪某个待决的I/O操作，你可能需要给这个操作添加一个自定义结构，如前文所提及的)。最后这就可能会造成一定的问题，操作系统会限制未分页内存的用量。

在Windows NT和2000这两种操作系统上，给每个连接分配的未分页内存的具体数量是不同的，未来版本的Windows很可能也不同。为了使应用程序的生命期更长，你就不应该计算对未分页池内存的具体需求量。

你的程序必须防止消耗到未分页池的极限。当系统中未分页池剩余空间太小时，某些与你的应用程序毫无关系的内核驱动就会发疯，甚至造成系统崩溃，特别是当系统中有第三方设备或驱动程序时，更容易发生这样的惨剧(而且无法预测)。同时你还要记住，同一台电脑上还可能运行有其它同样消耗未分页池的其它应用程序，因此在设计你的应用程序时，对资源量的预估要特别保守和谨慎。

处理资源不足的问题是十分复杂的，因为发生上述情况时你不会收到特别的错误代码，通常你只能收到一般性的WSAENOBUFS或者ERROR_INSUFFICIENT_RESOURCES 错误。要处理这些错误，首先，把你的应用程序工作配置调整到合理的最大值(译者注：所谓工作配置，是指应用程序各部分运行中所需的内存用量，请参考 http://msdn.microsoft.com/msdnmag/issues/1000/Bugslayer/Bugslayer1000.asp ，关于内存优化，译者另有译文)，如果错误继续出现，那么注意检查是否是网络带宽不足的问题。之后，请确认你没有同时发出太多的收发调用。最后，如果还是收到资源不足的错误，那就很可能是遇到了未分页内存池不足的问题了。要释放未分页内存池空间，请关闭应用程序中相当部分的连接，等待系统自行渡过和修正这个瞬时的错误。

]]> http://resentmenttree.blog.163.com/blog/static/30080720200742462720364 0 http://resentmenttree.blog.163.com/blog/static/30080720200742462720364 Thu, 24 May 2007 18:27:20 +0800 2007-05-25T17:29:19+08:00 <![CDATA[开发日志3]]> http://resentmenttree.blog.163.com/blog/static/30080720200742411543504     昨天睡前忽然想到send数据的时候好象还是有点问题，可能后一个投递的send消息会覆盖掉前一个消息的发送缓冲区，看了微软的sdk，要做的事情还是很多的呀。 ]]> http://resentmenttree.blog.163.com/blog/static/30080720200742411543504 0 http://resentmenttree.blog.163.com/blog/static/30080720200742411543504 Thu, 24 May 2007 11:05:43 +0800 2007-05-25T17:30:14+08:00 <![CDATA[开发日志2]]> http://resentmenttree.blog.163.com/blog/static/300807202007423102222140

    Login服务器的基本架构已经完成，开始考虑和char服务器交互的问题，感觉ja和ea的有些做法比较奇怪，一直在犹豫，怎么对char上登陆的User Session做合法性判断，难道在Login服务器内存里保留1份User Session结构的列表吗？超时登陆问题、恶意连接怎么去解决呢,定时遍历列表的效率会不会太低了；又或者把这个数据在用户登陆Login的时候发送给char服务器保存;还是利用通信中创建的用户类去保存呢？

]]> http://resentmenttree.blog.163.com/blog/static/300807202007423102222140 0 http://resentmenttree.blog.163.com/blog/static/300807202007423102222140 Wed, 23 May 2007 22:22:22 +0800 2007-05-25T17:29:58+08:00 <![CDATA[开发日志1]]> http://resentmenttree.blog.163.com/blog/static/30080720200742310635425

    服务器的网络模型终于确定下来了,IOCP模型的基本设计完成,虽然不能说效率有多高,但是总算基本稳定地达到了我自己的设计需求.

    参考ja和ea的代码,开始编写Login服务器,忽然发现ja和ea居然已经相差的这么多了,txt和sql的版本也大不同,只能自己参照协议实现了.本来准备写好Login服务器直接和ja版的其他服务器配合测试的,现在看来是不行了.忽然觉得事情变的越来越复杂,开始怀疑自己能不能坚持下去了.

]]> http://resentmenttree.blog.163.com/blog/static/30080720200742310635425 0 http://resentmenttree.blog.163.com/blog/static/30080720200742310635425 Wed, 23 May 2007 22:06:35 +0800 2007-05-25T17:29:40+08:00 <![CDATA[合辑 仙境传说-挚爱永恒 2004-01]]> http://resentmenttree.blog.163.com/blog/static/30080720200742393156399

1.守候永恒的爱(日文版)

作词：贞方祥　作曲：大久保薰　编曲：大久保薰　演唱：土屋亚有子/大久保薰

サヨナラとつぶやいて　泣いた君に背を向け歩いた

必ず归るからと　青い空に约束

空に浮かんだ云なら　あなたにも届くの

君に传えたいから　この空の　あの云を　追いかけて

＊遥か彼方　あなたを想い　未来の幸せを梦みてる

　だからいつも忘れたくない

　ふたリの爱　ふたリの爱　ふたリの梦　Love Forever

おはようとささやいて　朝の君で目觉めたあの顷

必ず待っていてと　青い空よ传えて

空に羽ばく鸟なら　あなたへと飞べるの

君に届けたいから　この空の　あの云を　追い越して

遥か彼方　あなたを想い　再び会える日を信じてる

だかろいつかその日のために

ふたリの爱と　ふたリの爱と　ふたリの梦　Love Forever

Repeat ＊

2.守候永恒的爱(中+日文版)

合唱：土屋亚有子/大久保薰

蔚蓝的天　云化成你的脸

你的笑　你的眼　又占据我的视线

暂停时间　没有离别想念

守候在你身边　直到永远

空に浮かんだ云なら　あなたにも届くの

别忘记　我们共同的誓言

この空の　那一片蓝天　追逐到永远

Forever in my heart　不管距离多么远

未来の幸せを梦みてる

飞到你的身边　倾诉着我的思念

我和你的爱恋　ふたリの爱と

爱直到永远　Love Forever

细语耳边　在梦醒的晨间

你的吻　你的恋　又在我心里盘旋

寄语蓝天　传递我的心愿

回到那一瞬间　期待不变

空に羽ばく鸟なら　あなたへと飞べるの

只要你　此刻就在我怀间

この空の　飞翔在蓝天　一直到永远

Forever in my heart　不管距离多么远

再び会える日を信じてる

飞到你的身边　倾诉着我的思念

我和你的爱恋　ふたリの爱と

爱直到永远　Love……Forever

Forever in my heart　不管距离多么远

未来の幸せを梦みてる

飞到你的身边　倾诉着我的思念

我和你的爱恋　ふたリの爱と

爱直到永远　Love……Forever

3.Christmas in love(爱在Ro雪季/日文版)

作词：Toru　作曲：钱幽兰　编曲：钱幽兰　演唱：Hana

せいれいは　しずけさに　やどり　はじめる

にぎわいの　まちなみも　なぜか　ここちよい

HOLD ME NOW! たぶん　きょうは

よわいことも　みとめられるの

KISS ME NOW! そばにいるだけで

いやされる　みたたされる　うしろを　ふりかえらず

WHITE CHRISTMAS ，FALL IN LOVE!!

あなたを　みていると　くじけそうな　まいにち

のりきれる　ようになる

ゆきのなか中で

わたしたちのことを　みまもるため　おりてく

しろいてんしたちの MERRY CHRISTMAS WITH LOVE!

4.爱在Ro雪季(中文版)

作词：钱幽兰　作曲：钱幽兰　编曲：钱幽兰　演唱：Hana

下雪的冬季　粉红色围巾　呼口气都是爱心

我在老地方　静静的等你　回想着点点滴滴的甜蜜

Hold me now!! 跟去年一样　靠在你胸前　静静的数着心跳

Kiss me now!! 融化我唇上的雪

圣诞的钟声　天使的祝福　围绕着有爱的每一天

White Christmas fall in love　在雪花纷飞浪漫季节

陪你发呆也是一种幸福　有你的日子我真的好快乐

我是多么爱你　深情的拥抱光耀围绕

点燃梦的烛光照亮希望　白色的天使祝福着　Merry Christmas～With love～

Repeat Once

5.梦想天空(韩国原曲)

作词：郑洗荣　作曲：郑洗荣　演唱：鲜于贞娥/混音：小宫征

Ohou It`s just one more day

No one said there world be dangerous

But I don`t care about it yea

I`m standing on the shore again

Alone I can go

Here I am out on my own again

My throughs get in my way

Sometimes there`s nothing left to say

Well I`ve got my doubts

But I`m trying so hard

To be a hero

I`m on the warpath

In the rugged strife

The grave is not my goal

It`s earnest and real

Don`t tell it an empty dream

My dream goes on

My life goes on

For ragnarok

Alone I can hear

Hear my voice

Singing for me again

I think about the past oh no

And I reflect on my mistakes

Well I`ve got my doubts

But I`m trying so hard

To be a hero

I`m on the warpath

In the rugged strife

The grave is not my goal

It`s earnest and real

Don`t tell it an empty dream

My dream goes on

My life goes on

For ragnarok

A journey must begin hear the calling in the wind again

Now it`s time to go

Leave aside don`t worry

Here my head up in my way again

My dream goes on

My life goes on

For ragnarok

My dream goes on again

6.守候永恒的爱(浪漫演奏版)

作曲：大久保薰　编曲：大久保薰

サヨナラとつぶやいて　泣いた君に背を向け歩いた

必ず归るからと　青い空に约束

空に浮かんだ云なら　あなたにも届くの

君に传えたいから　この空の　あの云を　追いかけて

＊遥か彼方　あなたを想い　未来の幸せを梦みてる

　だからいつも忘れたくない

　ふたリの爱　ふたリの爱　ふたリの梦　Love Forever

おはようとささやいて　朝の君で目觉めたあの顷

必ず待っていてと　青い空よ传えて

空に羽ばく鸟なら　あなたへと飞べるの

君に届けたいから　この空の　あの云を　追い越して

遥か彼方　あなたを想い　再び会える日を信じてる

だかろいつかその日のために

ふたリの爱と　ふたリの爱と　ふたリの梦　Love Forever

Repeat ＊

7.爱在Ro雪季(幸福演奏版)

下雪的冬季　粉红色围巾　呼口气都是爱心

我在老地方　静静的等你　回想着点点滴滴的甜蜜

Hold me now!!　跟去年一样　靠在你胸前　轻轻的数着心跳

kiss me now!! 融化我唇上的雪　圣诞的钟声　天使的祝福　围绕着有爱的每一天

White Christmas fall in love在雪花纷飞浪漫季节　陪你发呆也是一种幸福　有你的日子我真的好快乐

我是多么爱你　深情的拥抱光耀围绕　点燃梦的烛光照亮希望

白色的天使祝福着Merry Christmas～With love～

8.守候永恒的爱(伴唱版)

サヨナラとつぶやいて　泣いた君に背を向け歩いた

必ず归るからと　青い空に约束

空に浮かんだ云なら　あなたにも届くの

君に传えたいから　この空の　あの云を　追いかけて

遥か彼方　あなたを想い　未来の幸せを梦みてる

だからいつも忘れたくない

ふたリの爱　ふたリの爱　ふたリの梦　Love Forever

おはようとささやいて　朝の君で目觉めたあの顷

必ず待っていてと　青い空よ传えて

空に羽ばく鸟なら　あなたへと飞べるの

君に届けたいから　この空の　あの云を　追い越して

遥か彼方　あなたを想い　再び会える日を信じてる

だかろいつかその日のために

ふたリの爱と　ふたリの爱と　ふたリの梦　Love Forever

遥か彼方　あなたを想い　未来の幸せを梦みてる

だからいつも忘れたくない

ふたリの爱と　ふたリの爱と　ふたリの梦　Love Forever

9.爱在Ro雪季(伴唱版)

作曲：钱幽兰　编曲：钱幽兰

下雪的冬季　粉红色围巾　呼口气都是爱心

我在老地方　静静的等你　回想着点点滴滴的甜蜜

Hold me now!!　跟去年一样　靠在你胸前　轻轻的数着心跳

kiss me now!! 融化我唇上的雪　圣诞的钟声　天使的祝福　围绕着有爱的每一天

White Christmas fall in love在雪花纷飞浪漫季节　陪你发呆也是一种幸福　有你的日子我真的好快乐

我是多么爱你　深情的拥抱光耀围绕　点燃梦的烛光照亮希望

白色的天使祝福着Merry Christmas～With love～

10.梦想天空(韩国版+伴唱版)

]]> http://resentmenttree.blog.163.com/blog/static/30080720200742393156399 0 http://resentmenttree.blog.163.com/blog/static/30080720200742393156399 Wed, 23 May 2007 21:31:56 +0800 2007-05-23T21:31:56+08:00 <![CDATA[我的RO世界——序]]> http://resentmenttree.blog.163.com/blog/static/3008072020074235622661 一直无法忘记RO,放下又拿起,拿起又放下,反反复复,现在终于下决心尝试自己动手写一个这样的游戏,也算是给自己做一个了断吧.希望10年,20年以后再看到这个帖子的时候能开怀一笑.]]> http://resentmenttree.blog.163.com/blog/static/3008072020074235622661 0 http://resentmenttree.blog.163.com/blog/static/3008072020074235622661 Wed, 23 May 2007 17:06:22 +0800 2007-05-23T21:52:51+08:00