转自：http://erlangdisplay.iteye.com/blog/1012785
Erlang游戏开发-协议
选择什么协议?
协议包含通讯协议和数据格式.
通讯协议
通讯协议目前常用的是:HTTP 和TCP .其有各自的特点根据游戏的特点而进行选择.
HTTP
HTTP比较成熟,使用极其广泛.具有丰富的基础软件和工具.
对于简单的social game可以使用HTTP作为通讯协议.
这类游戏对实时性要求不是很高,使用HTTP也很容易做到性能扩展,可以较好的满足需求.
如果游戏前端使用HTML+js开发,那么只能使用HTTP了,需要较好的交互性和实时性时,只能
使用HTTP长轮询来实现了.如果前端使用flash开发,游戏交互复杂,实时性要求高,那么HTTP
便不合适了.
TCP
HTTP是高级的应用协议,而TCP便是比较基础的协议了.HTTP也是基于TCP实现.
对于一些web game,基本上采用TCP.其并发量不大(单服web game通常在线千人左右),而
实时性要求很高,尤其是ARPG游戏.因此TCP是不二选择.其前端大多使用flash实现(因为
HTML5之前,html+js无法创建TCP socket).至于非80,非443端口的防火墙问题,貌似现在
的网络环境下可以忽略.
数据格式
文本格式,比如xml,json或自定义均可作为传输的数据格式,文本格式最大的好处是可读,
便于调试,缺点是数据量比较大,冗余信息太多.(当然可以通过压缩来弥补).因此在web
game中很少使用文本作为数据传输格式.
除却文本就是二进制协议了.二进制协议也分多种:protobuf,thrift等通用二进制传输协议和
自定义二进制格式.使用protobuf和thrift的好处是通用性,多种语言均支持,再一个规模比较
大,使用多种开发语言的环境中比较合适.作为web game,通常是一个工作室负责一款产品,
client和server使用的技术和语言相对确定,因此这些通用二进制传输协议就不是最好的选择,
同时,其因为通用,也导致了一些性能下降.
目前大部分游戏是采用自定义二进制协议,基本结构为:头部几个字节表示数据体长度,随后为
数据体.在数据体中,可以划分出几个字节(如2个)表示某种消息.我们会为每种消息都定义数据
格式. 其大致的样子如下: [2字节数据长度][2字节消息类型,具体的消息体].
Erlang中如何处理?
再Erlang中实现这样的协议非常简单, 设置inet:setopts/2的 packet 选项为2,便可支持我们上面
的协议.Erlang自动会首先获取2个字节,作为长度,随后继续接受数据,知道这个包接收完成,
省去了我们自己处理解包,粘包的痛苦 :)(注意2个自己使用无符号的big-endian编码方式).
有了数据体,接下来需要处理2个字节的消息类型,Erlang还提供了一个贴心的选项:{header , size}(注意这个选项只有在socket设置binary选项的时候有效).再这里我们设置{header, 2},这样我们收到的数据体,不是一整块,而是这样:[Byte1, Byte2 | Binary],Byte1,Byte2是Erlang为我们截取出的数据体的头2个字节. 对于熟悉Erlang的朋友,我提一个问题:
这个数据是格式规则的列表么?答案是No,这个列表是一个"畸形"的列表,因为其最后一个元素不是列表.有些绕远了… 
还有,在Erlang中TCP,拥有一个active 选项,其取值为:true, false, once.看过书的都明白,其是用来控制TCP数据的接收方式.通过使用 inet:setopts(Sock, [{active, once}]),我们可以让数据乖乖的听话,主动发给我们一个数据,然后变不主动,我们处理完这个消息后,然后在设置active once,其继续再发给我们一个数据. 这样的好处是,不会因为{active, true},给我们发送了大量的数据,导致我们应接不暇.也不会让我们每次都手动 gen_tcp:recv/2数据,那么累人.
游戏中协议的消息类型达上百中,这个过程如果手工编码会非常累,应该在开始的时候,再确定好协议格式后,就书写脚本完成协议编解码的自动生成,一劳永逸!大大减少调试出错的可能.协议修改后,通过一个命令就可以重新生成代码.非常happy.(有的团队,更加geek,直接使用erlang:term_to_binary作为二进制协议,由flash端进行erlang term的解析,非常强大).
最后就是要动手,首先把网络和协议搞定,游戏之路就开始了