[转]SNS中的伪请求通信模式——回档

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


回档本来是服务端的概念。不过贵在有这个旧概念，现在的玩家基本能接受回档这个状况了，能够理解“虽然我买的东西没了但钱也还我了所以没有关系”。而假操作因为是延迟发送的，发送之前出了岔子，服务端压根不知道有这回事，在玩家看来就是回档。
岔子嘛，无非是出错了。出错可能是单纯的网络错误，也可能是请求验证失败被打回来了（比如你作 弊了，或者被服务端逻辑误杀了），更多的情况则是玩家切换页面，关闭浏览器，以及掉线，关机。
这可能是最大的隐患，因为这关系到用户习惯。一般这类游戏都需要设置保存按钮，这样点保存后，前面的操作能确保不会回档。还有的则是采用“保存后退出”这样的设定，就像计算机安全关机一样，你用界面关就不会丢数据，强制关就可能坏硬盘。保存后退出也能避免有强迫症的玩家没事就点保存导致服务器压力反而增大。
好在现在很多游戏都这么搞，大家都有这个意识，一般也不会抱怨了。

对于关闭浏览器的情况，其实可以用这样一个JS脚本来阻止
function (text) {
if (text != null)
{
window.onbeforeunload = onbeforeunload_handler;
function onbeforeunload_handler()
{
var warning = text;
return warning;
}
}
else
window.onbeforeunload = null;
}
当浏览器关闭或者刷新时，JS会先弹一个框出来，显示text的文字，点击了确认则刷新或者关闭，点取消就回到原界面。这个可能会有点烦，但确实有效。你可以在点击“保存后退出”取消这个JS的效果让他能顺利关闭浏览器，也可以在假请求列表为空时取消。

服务器验证回档则是比较麻烦的事情，毕竟回档对用户来说很不“友好”，按说应该尽可能避免。首先就是要靠测试减少BUG，因为现在客户端需要模拟，因此实际上所有算法和配置都是客户端服务端各一套，同步不好就验证失败然后回档。麻烦的是我们只知道不同步，而不清楚到底是哪一方的错。必要的情况，可以考虑减少服务端的验证，一些时候，BUG导致错误数据也不一定不能接受，但老回档实在是……

最后，还有一个回档的可能，那就是天灾——网络错误。虽然看起来网络错误可以靠重发解决，但事实上不是这么简单，所有不少团队都是直接“出错=F5刷新=回档”。
事实是这样的，如果你的请求的确没有发送到服务端，再发一次当然没问题。但同样显示网络错误，未必没有发送到服务端，有可能是服务端接受到请求后返回结果时没发回来……这样你重发的话，服务端就收到了两次请求。如果这两次请求都是买东西而且正好合法的话，玩家就郁闷了……风怒了是吧……
这个是有解决方案的，方法就是客户端和服务端都记录各自的请求发送次数，客户端发送的请求都带上这个次数，而服务端则忽略次数相同的请求，这样就不会因为重复请求则导致买了两个东西了。
当然闲这个做法麻烦直接F5刷性也成，毕竟是小概率。
这种做法也能有效阻止双开。

顺带说下save操作的更新频率。总之，太高服务端压力大，太低则回档跨度大。定多长时间看情况（1-5分钟吧）。首先我觉得主要靠时间。具体作法则是：
一旦有请求，则开始5分钟倒计时，时间到了保存。
倒计时期间的请求不再触发倒计时。
这样做的结果是让最小save间隔为x分钟。如果一直有请求，最小的间隔就是x分钟，一旦没有了请求，最长只要等x分钟就能自动保存，而且一直没有请求的话，就一直不会保存。
这行基本够用了。如果觉得单靠时间很死板，也可以加上条数限制，条数过多可以先于时间保存。