[转]SNS中的伪请求通信模式——开端

[url]http://uh.9ria.com/space-12147-do-blog-id-5248.html[/url]

因为这并没有什么特定的名字，所以就随便取了一个，不用特别在意。具体而言，就是现在facebook上许多SNS游戏使用的通信方法。既然是要做facebook上的游戏的话，用“抄”的思路来考虑，那么可能就会接触这样的东西了。
如果有兴趣的话，可以翻 墙上facebook看看，同时开着firebug，然后必然会有疑惑。你会发现自己做了无数操作却没有任何请求，而下面，说的则是具体的做法。知道了做法，自然就知道原因了。
事先说明，正常人知道这种做法，一定会觉得这是相当乱来的方式。我还是那句话，这种做法已经被广泛使用了，事实证明，至少facebook上的用户是完全可以接受（而且已经接受了），所以请不要考虑这样的问题。

简单来说——比如我们通常的做法，会在相应的时候请求服务器，这里面有下行的读取数据的请求，也有上行的发送操作的请求。
然后，其实有个很早的优化方法，就是将多个连续的请求合并成一个请求组同时发送，这样可以减少连接次数，缩短等待时间。而这些看起来半天不发送请求的游戏，其实就是将这个做法夸张后的结果。本来，只有连续的请求才会被合并，这样逻辑上并没有区别，而这个做法则是将一段时间内（可能5分钟）的请求全部累计起来发送……
所以，你操作的时候当然看不到后台请求，因为这还在累计阶段，直到等待一段时间后，实际的请求才会发送到服务端，然后服务端再逐条进行出来。不管你当初做了多少操作，服务端也只会处理一次。其中，还可以进行多种优化处理，因此这种做法可以有效的减少服务端压力。而且因为请求被合并了，用户操作时等待的时间也缩短了，对于响应较慢的短连接的游戏这是很重要的。

这并不难实现。对于客户端，也仅仅是把请求内容累计起来，然后用定时器发送出去，服务端也就是接受一组请求然后用原来的办法一条一条处理（这部分可以进行优化，诸如分解与合并来提高性能），因为实际交互流程并没有变化，也没有所谓的作 弊隐患。

当然，这和原来的做法还是有很大区别的，尤其是对于一些原本比较差的项目而言。这样做，本地配置数据和持久层都是必要的。本地配置数据可以将一些服务器的定义数据缓存到客户端，一般会采用XML方式，这样服务器只需要返回物品ID，客户端就可以直接生成一个完整的物品数据而无需服务器提供。而持久层则能保证只要在第一次登录时获得足够必要的数据，之后只有用户本身的操作的话，就不需要服务器再提供新的数据。而这两部分并不在本文的讨论范围内。

这是必须的。可以想到，既然请求只是被储存起来而不是立即发送，自然就不能马上取到发送后的服务器返回了。但我们不可能等到那个时候，所以结果只能先由客户端模拟，然后在请求时确认。关键就在这里，如果没有本地配置文件，也没有持久层的话，客户端根本没有所需的数据。比如你购买了一个物品，虽然你买了，但在请求没有发送前是不会有新的数据的，所以为了显示这个已经购买的假象，你必须能取到物品的图片，说明，而为了操作正常，新买的物品应当能在物品栏中正常显示，以至于正常使用。前者就是配置文件的功劳，后者则需要持久层。这两个东西以前是用来优化的，不少项目其实都是实现了的，所以要再实现伪请求只需要简单写点代码就可以很容易模拟出显示效果。当然如果没做……

总之如果要说这个又得很多篇幅，现在就不提了，所以这里就默认大家都做了这个工作吧。但即使是这样，将请求累计起来发送还是有一些新问题。问题还在于模拟，说白了，这个就是要求所有的上行请求都不包含下行，而显然不是所有的请求都能够做到这点的。因此，它具有一定的适用范围，并不是通用的代替方法。