网络协议编写的三层境界

 

本文不会涉及到你该使用UDP还是TCP,是FTP还是HTTP,也就是跟P都没有关系。^^ 同时,也不涉及该使用私有协议还是标准协议,还是在标准协议下使用私有协议, 而是会谈及在具体的协议编写的时候,使用哪种编写的方式会更好。由于本人的知识有限,谈及利弊时,主要以使用C++编写服务端时的经验为主,至于同时适不适用于其他语言,就靠童鞋们自己分辨了。
第一层境界:新手入门
??? 因为我一开始工作的第一家公司就是精于服务端程序编写的公司(运营过百万级同时在线以上),所以实际上我以前都不太清楚真有公司处于此水平,直到真的碰到时,我才惊慌失措,感叹不已。
特点:信手拈来,直观质朴
也就是写一个结构,在任何需要使用的时候(典型环境就是打包解包,读写文件)一个变量一个变量的通过memcpy等方式处理。简单是简单,没有任何抽象。
但是,

1.非常的不符合DRY原则,在此情况下,服务器端的打包解包代码和客户端的打包解包代码都得两份。别说服务器只需要打包,客户端只需要解包,这是太理想的情况,太经常一个小结构会需要传来传去的。而无论这个结构用多少次,你都得多为其写一次代码。

2.扩展性差:任何底层协议的改动,你都得更改除了相关数据结构意外的地方,(这也算是不符合DRY原则带来的副作用)而且此更改你往往得通过搜索才能完成。甚至,同一个数据结构即使仅仅是打包解包都做不到DRY原则。需要进行版本控制时,相关代码也会散布在各打包解包各处,更何况,当你想要以其他方式(比如写入文件)保存此数据结构的时候,你又得重新来一次,简直就是不人道的。
3.容易出错:在上层打包解包代码,都需要关注于每个结构的每个字段的数据类型,任何一个类型错误,你能够预期到的最好结果就是crash。
第二层境界:序列化
??? 通过序列化的概念,通过函数抽象实现同一个数据结构打包解包的DRY。通过函数重载,减少不同类型的不同处理。

特点:统一接口,各司其职
??? 面向对象有的时候会代码对象层次过多等乱七八糟的问题,但是此处面向对象的使用,我感觉实在是太淋漓尽致的体现将面向对象的好处了。我记得以前有个关于对象设计的原则,那就是告诉对象要做什么,而不是去获取数据自己来做。在第一层境界中的做法就完全是自己获取结构中的数据,外部来完成工作,为什么不更面向对象一点,让这种工作由对象本身来完成呢?此时,因为序列化的本质是从接口到二进制之间的转换,对于网络打包解包,文件读写可以做到通过传入不同参数用同样的接口来完成,对于每个类/结构的数据只需要进行一次的编码,极大的减少了错误的发生概率。 能达到这个境界的工作已经算是比较有技术的公司了。
但是,
1.对于服务器客户端语言不同时的情况,再次的无法实现DRY,典型的应用就是以JAVA写服务器,而以C++写游戏时。
2.版本控制还是太过于手动化。
第三层境界: 代码生成代码
??? 《Unix编程艺术》中描述的至高境界....代码生成代码,元编程的本质。第一次领悟这种境界是通过Google Protobuf,后来还知道一个thrift。

特点:描述结构,自动生成
??? 以Google Protobuf为例,在写一个网络协议的时候,你不是直接的用一种语言编写协议,而是用特定的描述语言来描述这个协议的内容,然后通过工具自动的生成你需要的特定语言的结构。这样的好处是一次的描述,可以自动的为你生成多个语言的协议文件。(DRY,Protobuf官方支持C++,JAVA,Python,第三方支持的更多)更重要的是,这个接口的打包解包接口已经也生成好了,直接调用即可。当然,这个方法也不是完美的,简单的说,你需要学习怎么描述这个协议,你需要用工具生成代码,简单的说就是比直接写增加了复杂性。

小结:
? 其实还有其他的协议编写方式,比如用XML,Json的纯文本协议,这个也是一种较佳的方式,调试非常方便,只是效率上比起二进制的还有差距,而在第三层境界中,为了调试方便,为生成的结构增加一个日志输出接口,也能较为方便的调试。

 

自己 

评论:

2 条评论

发表评论 取消回复

电子邮件地址不会被公开。 必填项已用*标注