当前位置: 编程技术>移动开发
本页文章导读:
▪mp3资料解析代码 mp3文件解析代码头文件：
#ifndef _MP3_H_
#define _MP3_H_
#include "stdint.h"
enum {
BITRATE_MPEG1,
BITRATE_MPEG2,
BITRATE_NUM
};
enum {
SAMPLERATE_MPEG1,
SAMPLERATE_MPEG2,
SAMPLERATE_MPEG25,
SAMPLERATE_NUM
};
#define MP3_FRAME_SY.........
▪ 论任务逻辑宜放在服务器端的缘故 论任务逻辑宜放在服务器端的原因 原来有一个同事，现在在顽石工作，负责维护《二战风云》。昨天我问他关于网游任务系统的实现时，他说，《二战风云》的任务系统完全是在服务器端.........
▪ 联通vac割接接话柄现说明 联通vac割接接口实现说明最近经常有人加我QQ问关于vac传过来的消息包格式相关的问题，如果不是采用java来实现的话，只能是采用收发xml消息包的方式来实现.如下图说明：
1.联通vac推送.........
[1]mp3资料解析代码
来源: 互联网 发布时间: 2014-02-18
mp3文件解析代码
头文件：
源文件：
[2] 论任务逻辑宜放在服务器端的缘故
来源: 互联网 发布时间: 2014-02-18
论任务逻辑宜放在服务器端的原因
原来有一个同事，现在在顽石工作，负责维护《二战风云》。昨天我问他关于网游任务系统的实现时，他说，《二战风云》的任务系统完全是在服务器端实现的。原因没有细说，大概是便于更新之类。当然，二战最开始是个网页游戏，跟手机网游的情况不太一样，不能一概而论。晚上睡不着觉，我又想了想这个问题，得到的结论是：任务静态数据（例如文本描述信息），适合放在客户端；任务逻辑适合放在服务器。
昨天开会讨论服务器和客户端做任务系统的优缺点，从大家的发言里我总结了以下几点：
1.客户端做任务逻辑，运行比较快；网络端做的话，人数多的时候性能压力大。
2.客户端做的话，涉及的网络通信量比较小，耗流量少，用户体验好。
3.对于上线后新增、修改任务的情况，网络端做更自由；客户端做，采用更新任务数据包的方式，也可以接受。
4.网络端安全性比较高，但是这点我们不用太考虑。
一句话，目标是，在满足日后修改要求的前提下，选一种易实现的方式，尽可能减少流量损耗，加快运行速度，提升用户体验。
哪种方式流量消耗少？
客户端做任务逻辑是否网络通信量少。我认为不是，因为，网络端做逻辑判断时也是不需要与客户端通信的，只需要在任务完成后的一个恰当时机，假推送“任务完成了”这个消息给客户端。客户端做的话，还要有新增修改任务逻辑时更新任务数据所耗费的流量。至于任务描述文本、任务奖励这些比较静态的数据，倒是适合放在客户端，确实省流量。可能开会讨论时大家说的省流量，指的是这一点。另外并不是所有的数据在客户端都是有效的，甚至有些数据不存在于客户端里。客户端在判断任务逻辑时，不论任务是否完成，都需要联网取得或验证这些数据。
哪种方式运行速度快？
客户端做任务逻辑判断，其实要消耗客户端的机器资源，但是客户只有一个，客户机又很快，逻辑判断的运算量也小，这个可以不考虑。主要的问题是服务器端做任务逻辑，会不会导致服务器端性能压力大，响应不及时。我认为不会。原因是服务器端一般只需要在客户端做出某些操作时（或者心跳时）进行这个判断，并不是时时判断的。同时，大量的网页策略游戏证明，至少服务器端判断带来的性能压力，是有成熟的。
哪种方式用户体验好？
省流量，给用户省钱，不容易被破解，不容易出外挂，很少需要更新数据包，更容易有网页版，速度上还相差无几。综上，我认为静态数据客户端存，逻辑判断服务器做这种方式，用户体验更好。
两种思路：
1.服务器只用作数据交互
2.客户端只用作播放器
这两种思路在实现上都可以说是具有指导意义的高度概括模型。但是我认为，在更新方便和安全性这两点上面，模型1无论怎么努力，也打不到模型2能做到的程度。
原来有一个同事，现在在顽石工作，负责维护《二战风云》。昨天我问他关于网游任务系统的实现时，他说，《二战风云》的任务系统完全是在服务器端实现的。原因没有细说，大概是便于更新之类。当然，二战最开始是个网页游戏，跟手机网游的情况不太一样，不能一概而论。晚上睡不着觉，我又想了想这个问题，得到的结论是：任务静态数据（例如文本描述信息），适合放在客户端；任务逻辑适合放在服务器。
昨天开会讨论服务器和客户端做任务系统的优缺点，从大家的发言里我总结了以下几点：
1.客户端做任务逻辑，运行比较快；网络端做的话，人数多的时候性能压力大。
2.客户端做的话，涉及的网络通信量比较小，耗流量少，用户体验好。
3.对于上线后新增、修改任务的情况，网络端做更自由；客户端做，采用更新任务数据包的方式，也可以接受。
4.网络端安全性比较高，但是这点我们不用太考虑。
一句话，目标是，在满足日后修改要求的前提下，选一种易实现的方式，尽可能减少流量损耗，加快运行速度，提升用户体验。
哪种方式流量消耗少？
客户端做任务逻辑是否网络通信量少。我认为不是，因为，网络端做逻辑判断时也是不需要与客户端通信的，只需要在任务完成后的一个恰当时机，假推送“任务完成了”这个消息给客户端。客户端做的话，还要有新增修改任务逻辑时更新任务数据所耗费的流量。至于任务描述文本、任务奖励这些比较静态的数据，倒是适合放在客户端，确实省流量。可能开会讨论时大家说的省流量，指的是这一点。另外并不是所有的数据在客户端都是有效的，甚至有些数据不存在于客户端里。客户端在判断任务逻辑时，不论任务是否完成，都需要联网取得或验证这些数据。
哪种方式运行速度快？
客户端做任务逻辑判断，其实要消耗客户端的机器资源，但是客户只有一个，客户机又很快，逻辑判断的运算量也小，这个可以不考虑。主要的问题是服务器端做任务逻辑，会不会导致服务器端性能压力大，响应不及时。我认为不会。原因是服务器端一般只需要在客户端做出某些操作时（或者心跳时）进行这个判断，并不是时时判断的。同时，大量的网页策略游戏证明，至少服务器端判断带来的性能压力，是有成熟的。
哪种方式用户体验好？
省流量，给用户省钱，不容易被破解，不容易出外挂，很少需要更新数据包，更容易有网页版，速度上还相差无几。综上，我认为静态数据客户端存，逻辑判断服务器做这种方式，用户体验更好。
两种思路：
1.服务器只用作数据交互
2.客户端只用作播放器
这两种思路在实现上都可以说是具有指导意义的高度概括模型。但是我认为，在更新方便和安全性这两点上面，模型1无论怎么努力，也打不到模型2能做到的程度。
[3] 联通vac割接接话柄现说明
来源: 互联网 发布时间: 2014-02-18
联通vac割接接口实现说明
2.SP要回复联通vac消息包格式：
最近经常有人加我QQ问关于vac传过来的消息包格式相关的问题，如果不是采用java来实现的话，只能是采用收发xml消息包的方式来实现.如下图说明：
1.联通vac推送给SP的消息包格式：
2.SP要回复联通vac消息包格式：
如果大家想使用asp、php等语言实现的话就按照上面的消息包格式来实现就行。至于具体怎么弄我也不是很清楚，所以请各位不要再问怎么实现的问题了。
至于用java实现的方式，我是用java+axis实现的，源码在下面的网址：
http://download.csdn.net/detail/hongyu6/1640633，然后网友下载该源码不知怎么用的建议先去看看axis相关webservice的资料。因为我是从2009年开始弄的vac割接，当时网上资料基本没有。而现在网上资料很多了，所以相信大家一定能实现。
现在网络没有搜不到的东西，而所以学会问问题，找问题才是关键！这样既节约自己的时间，也节约别人的时间！
最新技术文章: