手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表分类:Misc

网络游戏同步原理荟萃

看到这篇文章的时候,我觉得很惊讶,虽然我对这方面的了解并不多,但在自己的想像中,还是对网游这些东西稍有一点想法,因为曾经有朋友做过简单的外挂,比如,抓包发包然后尝试模拟包,来使网游达到你想实现的效果。
外挂这东西,在2003年左右应该是一个巅峰吧,那时候,奇迹外挂、传奇外挂,确实让一部分人先富起来,可是后来的零点行动,这些人都永远的消失在外挂长河中。
那时候我就在想,外挂是什么原理,为什么我这边的动作,可以让服务端产生那样的效果?其实,这就是一个同步的问题,我个人理解是服务器上有个触发器,这边发包后,然后那边判断包是否正常,然后就会有一个相应的动作。当然,动作程序还是在本机上,地图也在本机上,发出去的包,只是告诉服务器我是这样在动作的。于是就出现了瞬移,卡点这种情况,因为发出去的包,和坐标位置在服务器上都是正常的。(以上是我的猜测)

下面是文章:
不知道大家是否碰到过这种情况,当某个玩家发出一个火球,这个火球有自己的运动轨迹,那么如何来判断火球是否打中了人呢?大部分情况,当策划提出这个要求的时候,一般会被程序否认,原因是:太麻烦了,呵呵。复杂点的还有包括两个火球相撞之类的事情发生。

那么网络游戏中,是否真的无法模拟实现这种模拟呢?

首先我们来看看模拟此种操作会带来什么样的麻烦:

1,服务器必须trace火球的运行轨迹,乍一想,挺慢的。

2,网络延迟,传过来有延迟,传过去有延迟,延迟还不稳定,麻烦。

3,都有两点解决不了了,接下来不愿意再想了。

呵呵,实际上呢,对火球的模拟比对人物运动的模拟要轻松很多,原因很简单,火球的方向不会变。下面来看看具体用什么样的结构来实现:

不知道大家是否还记得我去年这个时候提到过的Dead Reckoning算法,我们要模拟火球运动的关键就在于一个叫Moving Objects Tracing Server的服务器程序,这个服务器是干什么的呢。这个服务器接收主游戏服务器发过来的注册事件的信息,比如有个玩家,开始移动了,那么主游戏服务器就 把该玩家的运动PDU,包括方向,速度,加速度,起点发给MOTS (Moving Objects Tracing Server),然后MOTS自己开始对其运行进行模拟,当游戏服务器发来第二个PDU包的时候,则对各个物件的位置进行修正,并重新开始模拟。那么,我 们模拟的目的是什么呢?当然是发生某些事件,比如说碰撞,或者掉入地图的某个陷阱的时候,会将该事件回发给主逻辑服务器。然后逻辑服务器来处理该事件。

那么,对于火球的处理,也和处理其他玩家的同步一样,当接收到玩家的发火球的指令以后,产生一个火球,并指定其PDU信息,在MOTS上注册该个运 动物 体。当MOTS自行模拟到这个物体和其他玩家或者NPC物体产生碰撞,则通知主逻辑服务器,然后主逻辑服务器产生相应的动作。

那么关于延迟呢?有些人也许会说,比如说前面有个火球,我本地操纵的小人其实躲过去了,但是因为网络延迟,在服务器上我并没有躲过去,那么怎么算? 呵呵, 不知道大家玩过星际没有,有没有发现在星际中玩多人连线模式的时候,有一点最特别的地方,就是控制一个小兵的时候,点了地图上的某个位置,但是小兵并不会 马上开始移动,而是有一定的延迟,但是这一小点延迟并不能掩盖星际的经典,同样的理论用到这里也成立。对于客户端的控制,当玩家操纵的主角改变PDU信息 的时候,确保信息发送到服务器之后,再开始处理本地的操作指令,这样就能保证本地的预测和服务器的预测几乎是没有什么误差的,即使有很小的误差产生,以服 务器为主,这样玩家也不会有太大的抱怨。

————————————————————————————————————————-

网络游戏同步详解之一

同步在网络游戏中是非常重要的,它保证了每个玩家在屏幕上看到的东西大体是一样的。其实呢,解决同步问题的最简单的方法就是把每个玩家的动作都向其 他玩家广播一遍,这里其实就存在两个问题:1,向哪些玩家广播,广播哪些消息。2,如果网络延迟怎么办。事实上呢,第一个问题是个非常简单的问题,不过之 所以我提出这个问题来,是提醒大家在设计自己的消息结构的时候,需要把这个因素考虑进去。而对于第二个问题,则是一个挺麻烦的问题,大家可以来看这么个例 子:
比如有一个玩家A向服务器发了条指令,说我现在在P1点,要去P2点。指令发出的时间是T0,服务器收到指令的时间是T1,然后向周围的玩家广播这条 消息,消息的内容是“玩家A从P1到P2”有一个在A附近的玩家B,收到服务器的这则广播的消息的时间是T2,然后开始在客户端上画图,A从P1到P2 点。这个时候就存在一个不同步的问题,玩家A和玩家B的屏幕上显示的画面相差了T2-T1的时间。这个时候怎么办呢?

有个解决方案,我给它取名叫预测拉扯,虽然有些怪异了点,不过基本上大家也能从字面上来理解它的意思。要解决这个问题,首先要定义一个值叫:预 测误差。然后需要在服务器端每个玩家连接的类里面加一项属性,叫TimeModified,然后在玩家登陆的时候,对客户端的时间和服务器的时间进行比 较,得出来的差值保存在TimeModified里面。还是上面的那个例子,服务器广播消息的时候,就根据要广播对象的TimeModified,计算出 一个客户端的CurrentTime,然后在消息头里面包含这个CurrentTime,然后再进行广播。并且同时在玩家A的客户端本地建立一个队列,保 存该条消息,只到获得服务器验证就从未被验证的消息队列里面将该消息删除,如果验证失败,则会被拉扯回P1点。然后当玩家B收到了服务器发过来的消息“玩 家A从P1到P2”这个时候就检查消息里面服务器发出的时间和本地时间做比较,如果大于定义的预测误差,就算出在T2这个时间,玩家A的屏幕上走到的地点 P3,然后把玩家B屏幕上的玩家A直接拉扯到P3,再继续走下去,这样就能保证同步。更进一步,为了保证客户端运行起来更加smooth,我并不推荐直接 把玩家拉扯过去,而是算出P3偏后的一点P4,然后用(P4-P1)/T(P4-P3)来算出一个很快的速度S,然后让玩家A用速度S快速移动到P4,这 样的处理方法是比较合理的,这种解决方案的原形在国际上被称为(Full plesiochronous),当然,该原形被我篡改了很多来适应网络游戏的同步,所以而变成所谓的:预测拉扯。

另外一个解决方案,我给它取名叫验证同步,听名字也知道,大体的意思就是每条指令在经过 服务器验证通过了以后再执行动作。具体的思路如下:首先 也需要在每个玩家连接类型里面定义一个 TimeModified,然后在客户端响应玩家鼠标行走的同时,客户端并不会先行走动,而是发一条走路的指令给服务器,然后等待服务器的验证。服务器接 受到这条消息以后,进行逻辑层的验证,然后计算出需要广播的范围,包括玩家A在内,根据各个客户端不同的TimeModified生成不同的消息头,开始 广播,这个时候这个玩家的走路信息就是完全同步的了。这个方法的优点是能保证各个客户端之间绝对的同步,缺点是当网络延迟比较大的时候,玩家的客户端的行 为会变得比较不流畅,给玩家带来很不爽的感觉。该种解决方案的原形在国际上被称为(Hierarchical master-slave synchronization),80年代以后被广泛应用于网络的各个领域。

最后一种解决方案是一种理想化的解决方案,在国际上被称为Mutual synchronization,是一种对未来网络的前景的良好预测出来的解决方案。这里之所以要提这个方案,并不是说我们已经完全的实现了这种方案,而 只是在网络游戏领域的某些方面应用到这种方案的某些思想。我对该种方案取名为:半服务器同步。大体的设计思路如下:

首先客户端需要在登陆世界的时候建立很多张广播列表,这些列表在客户端后台和服务器要进行不及时同步,之所以要建立多张列表,是因为要广播的类 型是不止一种的,比如说有local message,有remote message,还有global message 等等,这些列表都需要在客户端登陆的时候根据服务器发过来的消息建立好。在建立列表的同时,还需要获得每个列表中广播对象的TimeModified,并 且要维护一张完整的用户状态列表在后台,也是不及时的和服务器进行同步,根据本地的用户状态表,可以做到一部分决策由客户端自己来决定,当客户端发送这部 分决策的时候,则直接将最终决策发送到各个广播列表里面的客户端,并对其时间进行校对,保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。 那么再采用预测拉扯中提到过的计算提前量,提高速度行走过去的方法,将会使同步变得非常的smooth。该方案的优点是不通过服务器,客户端自己之间进行 同步,大大的降低了由于网络延迟而带来的误差,并且由于大部分决策都可以由客户端来做,也大大的降低了服务器的资源。由此带来的弊端就是由于消息和决策权 都放在客户端本地,所以给外挂提供了很大的可乘之机。

综合以上三种关于网络同步派系的优缺点,综合出一套关于网络游戏传输同步的较完整的解决方案,我称它为综合同步法(colligate synchronization)。大体设计思路如下:

首先将服务器需要同步的所有消息从划分一个优先等级,然后按照3/4的比例划分出重要消息和非重要消息,对于非重要消息,把决策权放在客户端,在客户端逻辑上建立相关的决策机构和各种消息缓存区,以及相关的消息缓存区管理机构,如下图所示:

上图简单说明了对于非重要消息,客户端的大体处理流程,其中有一个客户端被动行为值得大家注意,其中包括对服务器发过来的某些验证代码做返回, 来确保消息缓存中的消息和服务器端是一致的,从而有效的防止外挂来篡改本地消息缓存。其中的消息来源是包括本地的客户端响应玩家的消息以及远程服务器传递 过来的消息。

对于重要消息,比如说战斗或者是某些牵扯到玩家一些比较敏感数据的操作,则采用另外一套方案,该方案首先需要在服务器和客户端之间建立一套 Ping System,然后服务器保存和用户的及时的ping值,当ping比较小的时候,响应玩家消息的同时先不进行动作,而是先把该消息反馈给服务器,并且阻 塞,服务器收到该消息,进行逻辑验证之后向所有该详细广播的有效对象进行广播(包括消息发起者),然后客户端收到该消息的验证,才开始执行动作。而当 ping比较大的时候,客户端响应玩家消息的同时立刻进行动作,并且同时把该消息反馈给服务器,值得注意的是这个时候还需要在本地建立一个无验证消息的队 列,把该消息入队,执行动作的同时等待服务器的验证,还需要保存当前状态。服务器收到客户端的请求后,进行逻辑验证,并把消息反馈到各个客户端,带上各个 客户端校对过的本地时间。如果验证通过不过,则通知消息发起者,该消息验证失败,然后客户端自动把已经在进行中的动作取消,恢复原来状态。如果验证通过, 则广播到的各个客户端根据从服务器获得校对时间进行对其进行拉扯,保证在该行为完成之前完成同步。

至此,一个比较成熟的网络游戏的同步机制已经初步建立起来了,接下来的逻辑代码就根据各自不同的游戏风格以及侧重点来写了。

同步是网络游戏最重要的问题,如何同步也牵扯到各个方面的问题,比如说游戏的规模,游戏的类型以及各种各样的方面,对于规模比较大的游戏,在同 步方面可以下很多的工夫,把消息分得十分的细腻,对于不同的消息采用不同的同步机制,而对于规模比较小的游戏,则可以采用大体上一样的同步机制,究竟怎么 样同步,没有个定式,是需要根据自己的不同情况来做出不同的同步决策的网游同步算法之导航推测(Dead Reckoning)算法:

——————————————————————————————————————————

网络游戏同步详解之二

在了解该算法前,我们先来谈谈该算法的一些背景资料。大家都知道,在网络传输的时候,延迟现象是很普遍的,而在基于Server/Client结构 下的网络游戏的同步也就成了很头疼的问题,在保证客户端响应用户本地指令流畅的情况下,没法有效的保证的同步的及时性。同样,在军方也有类似的事情发生, 即使是同一LAN里面的机器,也会因为传输的延迟,导致一些运算的失误,介于此,美国国防部投入了大量的资金用于研究一种比较的好的方案来解决分布式系统 中的延迟问题,特别是一个叫分布式模拟运动(Distributed Interactive Simulation)的系统,这套系统呢,其中就提出了一套号称是Latency Hiding & Bandwidth Reduction的方案,命名为Dead Reckoning。呵呵,来头很大吧,恩,那么我们下面就来看看这套系统的一些观点,以及我们如何把它运用到我们的网络游戏的同步中。

首先,这套同步方案是基于我那篇《网络游戏的同步》一文中的Mutual Synchronization同步方案的,也就是说,它并不是Server/Client结构的,而是基于客户端之间的同步的。下面我们先来说一些本文中将用到的名词概念:
网状网络:客户端之间构成的网络
节点:网状网络中的每个客户端
极限误差:进行同步的时候可能产生的误差的极值

恩,在探讨其原理的之前,我们先来看看我们需要一个什么样的环境。首先,需要一个网状网络,网状网络如何构成呢?当有新节点进入的时候,通知该 网络里面的所有节点,各节点为该客户端在本地创建一个副本,登出的时候,则通知所有节点销毁本地关于该节点的副本。然后每个节点该保存一些什么数据呢?首 先有一个很重要的包需要保存,叫做协议数据包(PDU Protocol Data Unit),PDU包含节点的一些相关的运动信息,比如当前位置,速度,运动方向,或者还有加速度等一些信息。除PDU之外,还有其他信息需要保存,比如 说节点客户端人物的HP,MP之类的。然后,保证每个节点在最少8秒之内要向其它节点广播一次PDU信息。最后,设置一个极限误差值。到此,其环境就算搭 建完成了。下面,我们就来看看相关的具体算法:

假设在节点A有一个小人(路人甲),开始跑路了,这个时候,就像所有的节点广播一次他的PDU信息,包括:速度(S),方向(O),加速度 (A)。那么所有的节点就开始模拟路人甲的运动轨迹和路线,包括节点A本身(这点很重要),同时,路人甲在某某玩家的控制下,会不时的改变一下方向,让其 跑路的路线变得不是那么正规。在跑路的过程中,节点A有一个值在不停的记录着其真实坐标和在后台模拟运动的坐标的差值,当差值大于极限误差的时候,则计算 出当前的速度S,方向O和速度A(算法将在后面介绍),并广播给网络中其他所有节点。其他节点在收到这条消息之后呢,就可以用一些很平滑的移动把路人甲拉 扯过去,然后重新调整模拟跑路的数据,让其继续在后台模拟跑路。

很显然,如果极限误差定义得大了,其他节点看到的偏差就会过大,如果极限偏差定义得小了,网络带宽就会增大。如果定义这个极限误差,就该根据各 种数据的重要性来设计了。如果是回合制的网络游戏,那么在走路上把极限误差定义得大些无所谓,可以减少带宽。但是如果是及时打斗的网络游戏,那么就得把极 限误差定义得小一些,否则会出现某人看到某人老远把自己给砍死的情况。

Dead Reckoning的主要算法有9种,但是只有两种是解决主要问题的,其他的基本上只是针对不同的坐标系的一些不同的算法,这里就不一一介绍了。好,那么我们下面来看传说中的最主要的两种算法:
第一:目标点 = 原点 + 速度 * 时间差
第二:目标点 = 原点 + 速度 * 时间差 + 1/2 * 加速度 * 时间差
呵呵,传说中的算法都是很经典的,虽然我们早在初中物理的时候就学过。

该算法的好处呢,正如它开始所说的,Latency Hiding & Bandwidth Reduction,从原则上解决了网络延迟导致的不同步的问题,并且有效的减少了带宽,不好的地方就是该算法基本上只能使用于移动中的同步,当然,移动 的同步是网络游戏中同步的最大的问题。

该方法结合我在《网络游戏的同步》一文中提出的综合同步法的构架可以基本上解决掉网络游戏中走路同步的问题。相关问题欢迎大家一起讨论。

有关导航推测算法(Dead Reckoning)中的平滑处理:

根据我上篇文章所介绍的,在节点A收到节点B新的PDU包时,如果和A本地的关于B的模拟运动的坐标不一致时,怎么样在A的屏幕上把B拽到新的 PDU包所描叙的点上面去呢,上文中只提了用“很平滑的移动”把B“拉扯”过去,那么实际中应该怎么操作呢?这里介绍四种方法。

第一种方法,我取名叫直接拉扯法,大家听名字也知道,就是直接把B硬生生的拽到新的PDU包所描叙的坐标上去,该方法的好处是:简单。坏处是:看了以下三种方法之后你就不会用这种方法了。

第二种方法,叫直线行走(Linear),即让B从它的当前坐标走直线到新的PDU包所描叙的坐标,行走速度用上文中所介绍的经典算法:
目标点 = 原点 + 速度 * 时间差 + 1/2 * 加速度 * 时间差算出:
首先算出从当前坐标到PDU包中描叙的坐标所需要的时间:
T = Dest( TargetB – OriginB ) / Speed
然后根据新PDU包中所描叙的坐标信息模拟计算出在时间T之后,按照新的PDU包中的运动信息所应该达到的位置:
_TargetB = NewPDU.Speed * T
然后根据当前模拟行动中的B和_TargetB的距离配合时间T算出一个修正过的速度_S:
_S = Dest( _TargetB – OriginB ) / T
然后在画面上让B以速度_S走直线到Target_B,并且在走到之后调整其速度,方向,加速度等信息为新的PDU包中所描叙的。

这种方法呢,非常的土,会让物体在画面上移动起来变得非常的不现实,经常会出现很生硬的拐角,而且对于经常要修改的速度_S,在玩家A的画面上,玩家B的行动会变得非常的诡异。其好处是:比第一种方法要好。

第三种方法,叫二次方程行走(Quadratic),该方法的原理呢,就是在直线行走的过程中,加入二次方程来计算一条曲线路径,让Dest( _TargetB – OriginB )的过程是一条曲线,而不是一条直线,恩,具体的实现方法,就是在Linear方法的计算中,设定一个二次方程,在Dest函数计算距离的时候根据设定的 二次方程来计算,这样一来,可以使B在玩家A屏幕上的移动变得比较的有人性化一些。但是该方法的考虑也是不周全的,仅仅只考虑了TargetB到 _TargetB的方向,而没有考虑新的PDU包中的方向描叙,那么从_TargetB开始模拟行走的时候,仍然是会出现比较生硬的拐角,那么下面提出的 最终解决方案,将彻底解决这个问题。

——————————————————————————————————————————

网络游戏同步详解之三

最后一种方法叫:立方体抖动(Cubic Splines),这个东东比较复杂,它需要四个坐标信息作为它的参数来进行运算,第一个参数Pos1是OriginB,第二个参数Pos2是 OriginB在模拟运行一秒以后的位置,第三个参数Pos3是到达_TargetB前一秒的位置,第四个参数pos4是_TargetB的位置。

Struct pos {
Coordinate X;
Coordinate Y;
}
Pos1 = OriginB
Pos2 = OriginB + V
Pos3 = _TargetB – V
Pos4 = _TargetB
运动轨迹中(x, y)的坐标。
x = At^3 + Bt^2 + Ct + D
y = Et^3 + Ft^2 + Gt + H
(其中时间t的取值范围为0-1,在Pos1的时候为0,在Pos4的时候为1)
x(0-3)代表Pos1-Pos4中x的值,y(0-3)代表Pos1-Pos4中y的值
A = x3 – 3 * x2 +3 * x1 – x0
B = 3 * x2 – 6 * x1 + 3 * x0
C = 3 * x1 – 3 * x0
D = x0
E = y3 – 3 * y2 +3 * y1 – y0
F = 3 * y2 – 6 * y1 + 3 * y0
G = 3 * y1 – 3 * y0
H = y0

上面是公式,那么下面我们来看看如何获得Pos1-Pos4:首先,Pos1和 Pos2的取值会比较容易获得,根据OriginB配合当前的速度和方向可以获得,然而Pos3和Pos4呢,怎么获得呢?如果在从Pos1到Pos4的 过程中有新的PDU到达,那么我们定义它为NewPackage。

Pos3 = NewPackage.X + NewPackage.Y * t + 1/2 * NewPackage.a * t^2
Pos4 = Pos3 – (NewPackage.V + NewPackage.a * t)

如果没有NewPackage的情况下,则Pos3和Pos4按照开始所规定的方法获得。

至此,关于导航推测的算法大致介绍完毕。

原文来自:http://xinsync.xju.edu.cn/index.php/archives/4079

Tags: 同步, 原理

新春添置相机

新春,添置一台相机,拍了一些照片,有小孩的,有自己的。先放两张作为测试相机用,然后放点小家伙的照片。。。。

大小: 87.41 K
尺寸: 480 x 271
浏览: 2134 次
点击打开新窗口浏览全图

大小: 76.11 K
尺寸: 480 x 360
浏览: 1964 次
点击打开新窗口浏览全图

Tags: 相机, sony, t700

新年快乐

新年了,这回可是真正的农历新年。
小时候每年的盼望到现在却变成了休假的代名词,但也只有这个日子,才会给自己一个理由回家。和家人一起团聚。
今年没有回家,主要还是因为小家伙太小,怕经不起折腾,而且这段时间温度骤降,怕他引起感冒等。
希望父母和亲人们身体健康,万事如意。
朋友们新年工作顺利,闷声发大财。

再祝福一下:牛年,牛气象。

Tags: 牛年, 新年快乐

xml?xsl?css?xhtml

虽然,我写页面代码都是editplus写的,从来不用DW或者其他所见所得编辑器,但并不代码我的CSS就写的特别好,其实我一直很有疑问。CSs是否就是王道?

然后我看到这篇文章,觉得也是我心里想的东西。就贴出来了。。。

其实去年年底,jQuery 1.3尚未发布的时候就已经盘算着将中文文档以xml的形式发布了。这样有个好处,就是页面结构可以用xsl随便换。各位同学想做不同的发行版可以随便换 着玩~实际上我现在愈发觉得css的局限性了,很多时候所谓的css为了后期维护方便,可以任意修改布局而无需动页面结构之类的话语已经觉得难以置信了。 我就不信有多少同学遇到过改版的时候只改css而不改html的。当然也有可能是我的局限性而非css的局限性。

所谓的圣杯布局双飞翼布局确实在很大程度上能解决布局(Layout)上的问题,但别忘了,开发工作可不只是布局,还有排版(Typography),数据结构和页面表现结构交织在一起的时候,想崩溃都觉得老板会从地域里拖你起来。

xml+xslt这种手段其实我几年前就看到过,当时也曾为之心动,无奈当时技术水平有限无法体会其中精妙。然借此jQuery 1.3文档大改之际便又萌发了尝试的冲动。

xml+xslt好吗?很好!居然ie 5就开始支持了,ie 6支持的程度也很不错,基本上没有遇到什么兼容性问题,比起万恶的ie6对css的支持度好多了。目前我除了发现document()函数在ie中表现的跟其他浏览器不一致之外,以及Firefox居然不支持disable-output-escaping=”yes”,并且争论长达7年多尚未有解决的迹象。除此之外似乎没发现更多问题。

实际上让一部分处理页面的逻辑放到了前端来做,后台只负责输出数据,这种数据(XML),结构(XSLT),表现(CSS),行为(JS)4者相对 分离的状态是十分有利于这个前端产业工业化发展的。随着前端工种的进一步细分,我觉得这里大有可挖。好处显而易见,如果要大面积改版(即便是小范围),由 于后台只负责输出数据而没有HTML格式,高度分离的情况下,基本上只需要前端小组改一下即可。即便是对后台语言完全不了解都可以(我承认这不好)。
此外,xslt支持include/import等语句,包括上面提到的document(),可以很方便的实现页面各个部分的模块化。

但随之带来的问题也显而易见,数据过于结构化,页面内容轻易被人抓取而后分析(都不用分析……直接解析……)
此外,很多pda,手机之类的可能对xslt无法解析,但我估计屏幕阅读器应该没问题,因为很多屏幕阅读器都是基于现有浏览器的,也就是说现有浏览器支持,他也就支持。
还有上面提到的模块化问题,一不小心就可能导致连接数过多。每个模块的粒度得把握好。

解决这些问题的一个简单途径是,xml+xslt在服务器端解析生成。服务器端可以通过检测浏览器来判断直接输出xml+xslt还是输出生成的页面。这对于pda和手机之类的能提高很大兼容性。而对于一般浏览器又无需消耗服务器资源。
网上有篇流传甚广的文章XML在B/S架构开发中的应用,正是描述了此类情景。我考据下来可能是原著地址(我找到个更早的地址但上面的写的作者也是他,请宽恕我的网络考古情结)。

其中也提到了http://xml.apache.org/cocoon/ 似乎可以直接使用,没深究。

好了,得回到正题了。jQuer现在弄了个专门是放api的地址:http://api.jquery.com。 说实话,我一直很不喜欢他现在弄的样子,当我需要在不同的方法之间切换的时候很不方便。有喜欢的可以自己尝试。另外,分析代码发现原来这个api也是从 wiki里扣出来的xml进行解析得来的。另有air版,喜欢的可以自己下。扣的程序是Python 2.4写的,遗憾我这里只有Py3k环境,执行失败,且自己道行过浅,无法改成3.0版以供自己用。忘有此能力的同学能帮我改一下,可直接从jq的svn 里拿到,点击下载。没有达人帮忙其实也没事,见到还有地址可以在线生成,前面在线生成的地址如果不加参数则可以直接查看这个生成器的文档。用urllib.request.urlretrieve(url,path)直接下载真的是很惬意的事情,Python真的是很强悍啊……
我随便写了个xslt,可以直接浏览jQuery 的英文文档。暂不提供下载,喜欢的就自己另存为吧……不喜欢的就自己写一套吧……
暂时计划是将中文文档转换成xml(这步已经在前天完成,转的我残念……请原谅我能力有限只能用这么离奇的办法转 格式……)。不过之前写这个的时候还没有看到上面那个wiki2xml生成器(其实早就见过了,被我无视了而已……),所以对应的标签以及格式还不是很对 上号。改天整整。另外,单个xml拆分成散件的xml的py脚本也写完了,实验成功,现在生成chm版的文档只差单文件xml的校对和chm文件的目录以 及索引之类的编辑工作了。不用太期待……一揪回家了……新年饭局又多……饿……大半夜的吐槽可真不好……睡去了……
原文:http://shawphy.com/2009/01/about-jquery-xml-doc.html

————————END————————

到底什么是最好,什么是最方便?我也一直很犹豫,也很苦恼。。

随手转贴的:我为什么要使用google的CDN

 

看到这篇文章,就随手转贴了一下,因为我自己也在使用这样的功能,而且,现在的网站几乎都有google的广告。所以从yahoo的14条军规来说,这并不违反这个规则:使用CDN,尽量不要有超过4个域名的链接。所以你想呀,有一些google广告和yahoo的统计再加上1至2个其他的链接,肯定是没有超过4个域名了。CDN,有现成的,使用了,也算是完成了14条军规中的一些了。不是吗?所以。。。。。。

原文:http://shawphy.com/2009/01/why-google-cdn.html

自从之前jQuery 1.3版起,就已经没有提供pack版了,而我也十分赞成使用Google CDN进行代码托管。

这样做有以下几个好处:
1,更小下载量。
都知道jQuery 1.3 pack后有38k之多,如果当然可以删除版权注释以获得更小的代码,遗憾的是这不仅无耻且只节约1个k都不到。而同样利用Google APIs 提供的GZip过的Min版,只有18k,对用户来说下载量更小。

2,减轻服务器压力。
虽然现代浏览器都有了缓存,但以前我看到过资料说某大型网站发现他们70%的访客缓存都是空的(哪位同学能帮忙找到资料请下面留言,不胜感激~)。所以,让Google为我们提供服务,而不用自己操心自己的流量~少个库可以少个连接数,何乐而不为。

3,多个网站共享缓存。

如果用户访问的多家网站都使用Google提供的jQuery,那么对于用户来说,只需要缓存一次后即可只读取缓存中的数据!而不是每个网站都要重新下载一份。对此进一步加快用户访问速度。

4,更快执行速度。
jQuery 1.3.1发布的发布信息中, 为jQuery不提供pack版给出了官方的解释。除了不易debug,在Adobe AIR和Caja-capable等环境下无法使用之外,更重要的是因为执行速度问题。随着jQuery逐渐变“胖”,用pack压缩后在浏览器端“解压 缩”所需要的资源越来越大。想象一个超大的字符串多次replace后再eval的情景……这不比直接读取一个不需要解压缩的min版来得快。John给 出了一些数据,有兴趣的同学可以看看。

反对的声音:
“不安全”、“没安全感”、“放别人的机器太危险了”、“他们服务器倒了呢?”、“以前刚开始的时候就down过”

我认为(晕……怎么我觉得我在写四六级作文……)Google服务器down的几率与我们自己服务器down的几率不会有显著性差异(抱歉,我又空 口无凭说话了……不过如果哪位同学能给出数据来拒绝我的零假设,认可备选假设的,欢迎提供,再次不胜感激~)。所以就放他们那边吧,挺安全的。

另外我还听到关于不能让整个世界为着Google转,Google阴谋论,Google威胁论的声音。实际上Google确实正朝这个方向发展,让 整个互联网围着他转。可以看他提供的一些服务,什么云计算,什么App Engine之类的,都企图让人们的应用都建立在Google至上,当Google成为了空气的时候,他已经无处不在了。这点来说,值得担忧。

Tags: cdn, google, yahoo