上网乱逛看到的 应该是很久以前的文章吧XD 跟KK系统有关的文章 http://blog.csdn.net/mu_gong/archive/2005/02/19/293246.aspx 内文(by Onyx) 分散式多使用者空间 挑战人数上限 万王之王(The King Of Kings) 在去年12月底正式对外开放测试，到现在不到一年的时间内 ，屡次突破LP Mud的人数上限，到目前为止可以容纳320个使用者，可以说是台湾最大的LP Mud。 在传统的Mud里，使用者能从事的活动不外乎砍杀怪物，解谜题，完成任务以及与其他的玩 家互动。在万王之王中，除了这些事之外，万王之王提供了一套方法让使用者可以发挥想像 力，创造自己的国家，建构自己想像中的梦幻世界 即使你不会写程式。 第一次尝试这种类型的Mud，并没有想到会如此受欢迎。在不到一年的时间，甚至许多功能 都尚未完成的时候，不停的有新人加入这个游戏空间。原来是不希望设上限人数的，我们希 望 :「想玩就可以来玩。」。但是人数一再增加，整个系统慢了下来，於是我们不停的尝试 各种方法来提高人数上限，包括改写Mud library、更换硬体、更新MudOS版本、修改linux kernel以突破file descriptor上限256的限制等等。 几次电脑升级之後，目前万王之王的硬体设备是Pentium 200(虽然是用O的)，96 MB RAM，4 50MB IDE硬碟。於是我们开始思考: 非得如此不可吗？一定要不断追求更新更快的机器才能 容纳更多人吗？ 人数上限受限於哪些因素 人数上限的定义 response time : 从使用者下达指令到收到结果的这段时间称作response time. response time = 网路传输时间(来回) + 执行指令的时间 影响网路传输时间的因素包括routing, propergation delay time, bandwidth等等因素， 多半是我们无法掌握的，(经由实际测量，220人的时候所需的bandwidth约为0.2 Mbps，一 般的10 Mbps Ethernet足可胜任) 因此我们将重点集中在执行指令的时间，也就是Mud serv er端的改进。 执行使用者指令所花的时间跟在线上的人数有关，当人数越多，response time越长 。在使用者能接受的response time内所能容纳的人数定做人数上限。 LP Mud的 运作情形 LP Mud整个系统包括Mud OS, Mud library两层。Mud library以一种物件导向的语言LPC写 成，用来建构整个虚拟的世界。使用者所看到的世界，所使用的指令等等都属於Mud librar y这一层。Mud OS则可以看作是Mud的driver，是真正让Mud动起来的。在以下的说明中，Mud OS跟driver代表相同的意思，而Mud server则是包含了OS与library两层。 执行的时候，driver会将LPC写成的 library转为中间码，执行的时候以中间码执行，因此 是一种interpreter的方式在运作。这里要注意的是，并不是一开始就将整个library编译为 中间码，只有一小部份必须在启动的时候完成转换，大部分的程式都是在用到的时候才进行 编译与执行的动作。转成中间码後，除非被清除掉，否则不需要重新编译。 Mud OS可以看成是一个virtual machine，执行专属的中间码。在virtual machine是single thread的，也就是说一次一定会把一个指令或物件里的一个method执行完毕，才轮到下一 个。 Mud 需要处理以下三件事情 : 1. 每隔固定的间隔时间必须执行的 : 比如说每个生物的心跳。 2. call_out queue : 有些指令在执行的时候为了要造成延迟的效果，会以call_out函 数指定过了几秒後要跳到哪个函数执行，有点像sleep()。Mud OS会将call_out发出的请求 依时间挂在一个queue, 每隔一阵子就去检查是否到了执行的时间。 3. 使用者下的指令。 整个过程大概可以写成 : While (1) { process_heart_beat(); // 心跳，每两秒一次 process_call_out(); // call out queue process_user_command(); // user command } Fig. 1 人数的限制 回到前面的式子 response time = 网路传输时间(来回) + 执行指令的时间 而 执行指令的时间 = f ( 硬体的速度，virtual machine的效能，指令本身的复杂度，物件数 目，使用者数目) 其中物件的数目受直接受使用者数目的影响，而小心设计可以降低指令的复杂度。 从Fig 1的流程来看： 1. 使用者越多，花在process_heart_beat的时间越长，因此response time越长。 2. 使用者越多，要等前面所有的使用者指令都执行完的时间越久，response time越长 。 3. 使用者越多，整个虚拟世界里会被载入到记忆体的物件越多，因此寻找物件的时间越 长。在Mud里几乎每个动作都必须寻找物件，直接影响到指令执行的时间长短。 人数上限受限於所能忍受的response time, 而response time除了与硬体的速度、OS以及 v irtual machine的效能、library的结构有关以外，另一个主要的影响就是物件的数目了。 如何提高人数上限 1. 提升硬体设备 : a. 使用更快速的CPU b. 使用高速记忆体与硬碟 这是最简单的方法了，然而硬体升级的速度比不上进入网路世界的人口成长，而且如果每次 人数饱和就更新机器，将需要一笔可观的费用。 2. 加强virtual machine的效能，小心设计library ‥ 现在TAnet上的Mud多半是拿国外的virtual machine(Mud OS, driver)来使用，使 用新版本的virtual machine可以大幅提高执行速度。 ‥ 小心设计library，尽量不要设计的太复杂，将最花时间的一些动作与指令最佳化 。 ‥ 最佳化library能够收到的效果有限，往往最多只能增加10~20个使用者。 3. 降低单机的负担 这个想法很简单，很直接 : 既然一台机器能容纳的人有限，那就用两台机器来跑吧。分两 台机器来跑Mud不但分散了使用者，分散了区域，分散了物件，分散了网路I/O，减少了单机 的负担。将来如果人数又达饱和了，旧的机器可以继续使用，只需要再加入新的机器，一些 较低阶的机器也可以用来分担部份负担。需要考虑的是分散後，机器与机器间的communicat ion overhead会不会大於所获得的好处。 分散式多使用者空间 在数台不同的机器上跑同样的Mud，人物资料档案、区域档案等等复制一份放在各机器，这 是最简单的方法，但是这样各机器中的人物资料就不一致了。这样子最多只能称作是两个一 模一样的Mud。 另一个方法是用NFS。人物资料档存在同一个硬碟，各机器透过NFS来读取人物资料档。 这样不管使用者连线上哪台机器，他的资料是一致的。这种方法要解决的问题是：同一个使 用者可以以「同一个身分」，「同时」连线上这几台不同的机器，造成存在记忆体中的人物 资料不一致的情形。其次，这个方法只有分散使用者，并没有把虚拟世界的区域一并分散， 每台机器都必须有一份完整的虚拟世界，而且在不同机器的使用者即使在走到同一个房间里 也看不到对方。 设计前提 虽然这是一个分散式的虚拟世界，我们希望使用者感觉不出来，也就是强调他的transparen cy。另外，为了留住所有的使用者，我们希望所有的使用者能够以原来习惯的方法(telnet, tintin, zmud等等) 来加入这个世界而不需要改变。这两点成了设计上最大的挑战。 架构 Mud server Mud server Agent telnet tintin/zmud 专属 client 说明 1. 每个机器上都执行一份完整的Mud OS与Mud library ( 包括daemon、基本物件以及指 令的部份 )，而将虚拟世界切割开来，每个机器上只负责一部份的区域。 2. 透过一个configuration 档案来指定Mud server所负责的区域，当Mud server启动的 时候，必须跟agent程式报告所负责的区域。agent拥有 区域机器对应关系的资料。 3. 以KK为例子，区域的切割点可以是港口、国界或者是recall、summon、teleport等指 令。 4. 当使用者由区域A走到区域B的时候，可以由以下两种方法传送过去。 a. 使用专属client 如果使用者使用专属於这种Mud的client程式，在他走到切割点，想要走到另一个区域的时 候，Mud server A首先发出一个请求到agent，询问该区域是哪个server负责的区域。若age nt回覆为server B，A通知client程式与B 连接。client完成与B的连接後，切断与A的连线 。 b. 使用原有的client telnet、tinti、zmud等并没有主动转移connection的功能。当然我们可以发出一个讯息告 诉使用者 : 你现在该连往哪个机器，但是这样就不符合我们预期的目标了。而且对新使用 者而言，他可能并不知道该怎麽做。因此这时候我们需要一个界面，也就是架构图里的agen t，帮使用者处理这些转移connection的事物。 由agent 当使用者欲从A地走到B地(或者说从机器A移到机器B) Mud server发出通知告诉age nt，由agent转移connection，而使用者与agent的connection不需要切断或是重新连接。 5. agent的功能 ‥ agent拥有 区域机器对应的资料，在必要的时候甚至可以改变区域的分配，重新 分布使用者(dynamic load balancing)。 ‥ agent必须要能forward使用者所输入的指令给Mud server，将Mud server的回应 过滤後传回给使用者。 ‥ 所有连线的使用者都必须透过agent读取部份的资料(password，上次离线时的地 点) ，可以避免一个人多次登录(login)的问题。 可能遭遇的问题 1. channel广播讯息 例如chat、rumor等channel。 所有的channel讯息都以同样的方式处理。1. Server广播给所有与自己连接的 client，2. 送到其他的server，再由各server自行将讯息广播出去。 2. 跨server的交谈 例如tell、reply、finger，都是送讯息给特定使用者。 server送出交谈内容到各server，由各server自行寻找该特定使用者。 3. daemon资料的consistancy 一般的Mud不会有这个问题，然而KK里由於多了kingdom daemon，国家发展状态的资料存在k ingdom daemon中。如果kingdom daemon只放在某台server上执行，将会有跨server的 quer y 动作，这是我们不希望发生的。跨server的 “query” 动作不但牵涉到分散式的物件管 理(如何找到某特定物件)，所造成的communication overhead也会相当惊人。一旦每个serv er上都有一个kingdom daemon，势必要付出代价来维护他的consistancy。 4. agent负担过重 在没有专属client的辅助的时候，可以发现所有的connection都集中到agent，人数的瓶颈 也就转移到agent。 结语 在现在的电脑使用者中，知道 mud 而且玩 mud 的人应该还是少数，虽然 mud 比 起 pcgame 更有优势，但是目前还有待推广，将来使用 mud 的人相信会比现在更多，使用 者增加後所带来的机器负荷和网路负荷都是 mud 设计者所必须面对的挑战。分散式的 mud 正可以解决这两个挑战，而将负荷降低到可以接受的范围。未来在 mud 往图形化的方向进 步的路程中，各种的负荷只会越来越重，相信适当的分散处理将是未来的 mud 必需具备的 能力。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 59.113.225.127 ※ 编辑: happyhero 来自: 59.113.225.127 (01/29 23:45) ※ 编辑: happyhero 来自: 59.113.225.127 (01/29 23:45)