[转]SNS中的伪请求通信模式——限制以及与原模式的混合

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

既然说，这种假请求不能适用于所有情况，那我们就有两个课题。一，什么时候不适用，二，该怎么办。

其实不适用的情况并不多，主要存在两点：
一个就是不确定的几率事件。傻子都知道，让客户端来计算random是不靠谱的，因为这很容易作 弊，最普通的就是操作后随机获得一件物品。随便做点伪装包就可以保证次次都出物品，而且服务端还不能拒绝这种请求（因为的确是可能发生的）。平常的做法，就是由服务端计算random然后返回。但因为假操作的关系，我们得不到这个下行数据。
那该怎么办呢？一个应对方案是事先计算出获得的物品，客户端不是随机，而是把服务端以前随机的数据调出来。这样的问题是这个随机好的数据是事先保存在客户端的，那么通过抓包就能“预知”结果，对于某些情况（比如三选一）就会很麻烦了，虽然一般玩家不抓包，但这样会让外挂很容易做……
所以这个要看需求。能够接受就能勉强用这个，否则就是属于不适用假操作的范围，要另想办法。

另一个则是好友对自己的操作。通俗点就是偷菜。以前，偷菜时会立即请求服务器，如果两个人同时偷菜，后面的则会偷菜失败。这并没有什么。但如果是假操作，偷菜失败这个结果就不能立即知道了，玩家看到的只能是偷菜成功。而我们又不能让他们俩都成功，实际请求服务器的时候虽然能知道，但这时候怎么办呢？让玩家把偷走的菜吐出来？
没有人可以接受这种说明的。但这个倒不是没有解决办法，如果允许一份菜多个人偷的话……服务端可以记录这个玩家偷过哪些人的菜，只要保证他不能重复偷一家的菜就行。但如果一份菜只能有一个人偷的话，的确就是没辙。

没办法的时候，就只能用老办法请求服务器然后下行结果。但在这里，还有一个需要注意的地方。

比如，我做了一堆操作，这些操作使用假请求的方式实现的，请求会被延迟，而且它们都是加钱的操作，玩家会先看到自己的钱增加了。然后我又发了一个花钱买东西的操作，这个请求不是假的，而是立即请求的。
这就会出现问题。
比如我原来有100块，假请求+100，完毕后我有200，然后买了一个200块的东西。这本来没有问题。问题在假请求虽然加了100，但买东西时还没有发送到服务器呢，所以服务器只认为你有100块，那当然算购买失败了。
但玩家看到的就是“我明明有200块，但服务器硬说钱不够。”这个是没法解释的，因此必须避免。
做法就是在真请求前，把将所有累计的假请求发送出去。

因此，假请求如果要使用，量必须大，必须频繁。否则每次真请求前都要确认一次，弄不好比原来还慢。当假请求必须使用的时候，我们一定要想办法减少真请求的频度，上面其实都有例子。而且不少东西稍微调整下策划就可以做。比如将所有坏运气替换成好运气，你需要服务端下行新的运气，但如果改成所有坏运气全部失效，那就不需要下行了。一些实在没法做的功能也可以考虑砍掉

理想情况是上行请求里真请求一个都没有……但一般设计的时候，只要真请求频度低就可以了。