开发网络游戏必须掌握以下两大块技术。即使所处的团队实行分工制度,开发人员也需要对这两方面有所了解。 网络编程(Network Programming) 游戏编程(Game Programming) 为了便于读者更容易理解之后的内容,本章首先介绍一下网络编程和游戏编程的基本概念,对开发网络游戏来说,它们是非常重要的。本章将按照如下顺序进行讲解。 网络游戏开发者所需了解的网络编程基础 套接字编程 RPC 指南 游戏编程基础 首先,0.1~ 0.3 节将介绍网络编程。这一部分的要点如图0.A 所示,请先掌握以下重点,然后我们马上进入正题。 图0.A 网络游戏的层次体系 0.1网络游戏开发者所需了解的网络编程基础 首先,我们来学习网络游戏编程所需的网络编程基础知识。 0.1.1 网络编程是必需的 在实现网络游戏的过程中,网络上各个主机之间的数据传输(发送数据、接收数据)极其重要,因此,为了处理通信(也就是与远程终端进行数据的输入输出),必须掌握网络编程。 利用网络游戏的通信中间件(网络中间件)可以在很大程度上隐藏复杂的处理过程,但是如果不理解网络通信的内部机制,就很难有效运用中间件的功能,调试效率也会变低。因此,虽然不用亲自从底层开始编写所有的代码来实现网络通信,但是理解其中的机制还是很有必要的。此外,理解了本书中所介绍的这方面内容,也有助于理解网络通信中的基本技术。 网络游戏与网络游戏相关的网络编程基础知识并不多,本章将重点介绍那些网络游戏所需的网络编程基础知识。理解了这一块内容才能有效地加以运用,所以一起努力吧! 0.1.2 网络编程与互联网编程 为了使运行在两台以上机器的相关进程能够协调工作,必须在它们之间实现一些必要的通信功能,网络编程就是指实现进程间通信所需的编程技术。 网络编程的范畴非常广泛。比如,在使用USB 接口将外置HDD(Hard Disk Drive,硬盘驱动器)连接到PC 的情况下需要网络编程,因为要使PC 上运行的进程与HDD 控制器上运行的进程进行通信。再有,SCSI(Small Computer System Interface)、红外线通信,以至空调的遥控器等都离不开网络编程。除了任天堂DS 之间使用有线连接的情况之外,网络游戏中的网络编程一般只使用与互联网有关的技术。这种互联网方面的通信编程称为“互联网编程”(InternetProgramming),在国外有很多这方面的参考资料。 实现多人网络游戏的前提就是使用互联网,因此本书只讨论以互联网编程为主的网络编程技术。 0.1.3 互联网编程的历史和思想 在互联网通信的事实标准中,IP(Internet Protocol,网际协议)、TCP(TransmissionControl Protocol,传输控制协议)、UDP(User Datagram Protocol,用户数据报协议)等网络通信协议自定义以来的三十几年里,基本的通信方式并没有发生什么变化。IP 协议等以安全、舒适地使用互联网服务为目的而产生的网络协议,被技术标准化组织IETF(Internet Engineering Task Force,互联网工程任务组)作为基础资料收录在RFC①(RequestFor Comments②)中。RFC 并不具有法律上的强制力,但是遵守这些标准可以带来经济上的利益,所以很多人都以此为准。 RFC 以编号排定,比如,TCP 是在RFC 793 中定义的,DNS(Domain Name System,域名系统)的实现是在RFC 1123 中,HTTP(HyperText Transfer Protocol,超文本传输协议)的HTTP 1.0 则是在RFC 1945 中定义的。每次版本更新后,RFC 的编号也会随之更新。截至本书撰写时(2010 年9 月),RFC 的文档总数已经超过了6000 份③。 IETF 的RFC 是为了共享通信形式和协议而产生的,它里面并没有定义实际的编程接口,因此要开始网络编程,还必须进一步掌握一些基础知识。 0.1.4 OSI 参考模型——透明地处理标准和硬件的变化 如果每次出现新标准时,比如出现了更高速的1Tbit 以太网,都要修改程序,那将非常麻烦,而且网络设备类型多种多样,所以由此产生了希望能尽可能不依赖于这些设备,来透明地处理网络通信问题的要求。 在过去,每次为了应对设备更新都不得不修改程序,而随着网络中主机数量的不断增加,为了降低由此产生的成本,20 世纪80 年代,美国发起了制定标准化模型的运动。 其研究成果就是OSI 参考模型(OSI Reference Model)。OSI 参考模型的优点为:如果基于该模型进行设计,那么即使标准和硬件发生了变更,位于其上方的层次也不需要做过多的改动。通信系统是一种“设备与设备互连”的系统,所以应该尽可能不要对相连的设备造成影响,而是对其本身进行修改,这才是我们期望的设计方式。 OSI 参考模型提出了7 层结构,以下介绍各个层次的功能。 ---------------------------- ① http://www.ietf.org/rfc.html ② RFC 是一系列以编号排定的文件。文件收集了有关互联网相关信息,以及UNIX 和互联网社区的软件文件。——译者注。 ③ 顺带一提,RFC 1(http://www.rfc-editor.org/rfc/rfc1.txt)描述了使用串行电缆将两台主机进行连接的过程,这实在是很简单的一件事情,令人不禁感慨互联网黎明期的艰辛。 ------------------------------ 第7 层:应用层 提供具体的通信服务,比如文件和邮件的传送,访问远程数据库等。这一层的协议包括HTTP、FTP(File Transfer Protocol,文件传输协议)等。 第6 层:表示层 规定数据的表现形式,比如将以EBCDIC① 表示的文本文件转换为以ASCII 码表示的文件 第5 层:会话层 规定应用程序之间的通信从开始到结束之间的顺序(在连接中断的情况下,尝试恢复连接) 第4 层:传输层 实行网络中应用程序进程之间端到端的通信管理,如差错恢复、重发控制等 第3 层:网络层 对网络中的通信链路进行选择(路由选择)、中继 第2 层:数据链路层 控制直接相连(相邻)的通信设备之间的信号收发 第1 层:物理层 规定物理连接,包括连接器的引脚数、连接器形状等,以及铜缆与光纤之间电气信号的转换等 OSI 参考模型并不是一种非遵守不可的技术标准,它是一种有助于技术人员理解并记忆的概念性指导方针。对于各类技术人员和企业来说,遵循OSI 参考模型来设计产品可以获得不少好处,所以这一模型自然而然地得到了普及。 只要在OSI 参考模型的上层与下层之间提供相同的接口,即使任意一层中的组成要素发生了变更,系统仍能照常运作。 ----------------------------- ① 广义二进制编码的十进制交换码(Extended Binary Coded Decimal Interchange Code)。在主机中使用的字符编码。 ----------------------------- 0.1.5 网络游戏系统及其层次结构 现在,请回看一下本章开头介绍的图0.A。根据OSI 参考模型的层次结构,对网络游戏的系统进行总结之后,我们划分出了如图0.A 所示的分层。 第4 层大多使用TCP 协议、不需要直接操纵第3 层以下的分层在为了让应用程序能够在互联网上进行广泛通信的第4 层(传输层)协议中,TCP和UDP 这两种协议是事实上的标准。如果要求收发信号按顺序、可靠地进行传输,就要使用TCP 协议;如果对此不作要求,就可以使用UDP。 另一方面,网络游戏要求只有在必要的情况下才使用UDP,除此之外一概用TCP。只要具有了TCP 和UDP 的功能,就基本不需要再进行更进一步的细微调整了,因此,没有必要直接操纵第4 层以下的分层(第3 层至第1 层),将它们交给操作系统来处理就可以了。 但是,为了最大限度地提升性能,在第3 层以下也有几个需要注意的地方,这几点我将在下一节的后半部分予以说明。 第5 层以上的分层需要在游戏中予以实现 如图0.A 所示,网络游戏中尚不存在能作为第5 层、第6 层事实标准的协议。因此,一般来说,第5 层以上的功能都需要由网络游戏的开发人员来实现。这是因为根据游戏的类型和策划内容,在要求上有些微妙的差异,因而无法做到统一。但是在使用针对网络游戏的通信中间件的情况下,可以避免从零开始进行开发,从而能够大幅减少开发量。 接下来,我将介绍一下套接字API 和套接字编程基础,以及使用套接字API 的针对游戏的通信中间件的实现。 0.1.6 套接字API 的基础知识 BSD 套接字API① 是为了实现互联网连接而开发的API,它是在所有操作系统(包括嵌入式系统)上进行网络开发的首选。使用TCP / IP(不是BSD 套接字)开发的API 不胜枚举,但是如今在广泛用于网络游戏的环境上(包括游戏机)全都可以使用套接字API。 标准化的C、Java 和Ruby、Perl、C# 等几乎所有的编程语言都能使用这一API②。套接字API 在20 世纪80 年代开始普及,此后基本没有进行过变更,因此当时开发的程序有很多至今仍在照常运行。 由于篇幅有限,本书对套接字API 的介绍仅限于最基本的内容,网络上有大量学习资料可供参考,请读者务必进行查阅③。此外,前文提到过的IETF 的互联网方法、OSI参考模型以及套接字API 等从互联网开创时期开始的历史和通信方面的基础理论,在《UNIX 网络编程》系列图书(该系列是网络编程领域的圣经)中也有介绍。该书中,套接字API 的示例丰富且全面,其中的内容在所有网络游戏中都有用到。即使说网络游戏开发团队的书架上都有这本书也不为过。 ------------------------- ① Berkley Socket,也叫做Socket。 ② C 以外的编程语言(Java 和ActionScript 等)不能直接调用Socket API,但是可以使用在一定程度上仿效Socket 行为的API。 ③ 网络游戏也是同样,可以参考以下网站: http://x68000.q-e-d.net/~68user/net http://www.few.vu.nl/~jms/socket-info.html ------------------------- 0.1.7 网络游戏和套接字API——使用第4 层的套接字API 使用套接字API 可以控制位于第1 层、第2 层(物理层和数据链路层)之上的第3层的IP 协议、第4 层的UDP、TCP、ICMP(Internet Control Message Protocol,Internet控制报文协议)等协议。套接字API 中包括直接控制IP 协议的第3 层的API 和使用TCP等协议的第4 层的API。网络游戏只使用“第4 层的套接字API”。 面向连接(流式)和无连接(数据报式) 数据包会在网络的各条路径中传输,在这个过程中,数据包可能会因为路由器的处理能力不足或者通信链路拥堵等原因而丢失。在这种情况下,作为互联网基础的第3 层IP 协议并不会重发数据包,所以它是不可靠的。此外,数据包的到达顺序也无法保证。但是一旦收取成功,其内容不会发生改变①。 如果使用第4 层的套接字API,就可以在不具可靠性的IP 协议之上实现两种类型的通信:第一种是面向连接的通信(流式,STREAM),在建立了连接的两台主机之间维持通信线路畅通,保证通信持续进行;另一种是无连接的通信(数据报式,DGRAM),只进行一次数据包的交换,不维持各主机之间的通信线路。 在IP 上层实现的面向连接的协议是TCP 协议,使用TCP 的典型代表是HTTP 和SSH(Secure Shell)。HTTP 和SSH 对长时间传输、保证传输顺序一致、可靠性高的数据通信来说,是很有必要的。② 另一方面,无连接的代表协议是UDP,该协议将IP 数据包进行分割后发送出去。接收端只具有将其复原的功能,并不能保证数据包的到达顺序和可靠性,这一点与IP 协议区别不大。使用UDP 协议的典型代表是DNS 查询。 * * * 之前提到过,网络游戏中都会用到TCP 和UDP,但是为了让游戏中的主机能够持续进行通信,基本上都使用面向连接的TCP 协议③。在下一节中,我们将介绍一个以TCP 为前提的套接字编程示例。 ------------------------------ ① 错误的修正由第2 层以下的层次来保证。 ② 如果HTML(HyperText Markup Language)的顺序改变了,标记的前后关系就会完全混乱。 ③ 除了网络地址转换(NAT Traversal,将在5.6 节介绍)等特殊情况。 ------------------------------ 专栏 网络编程的特性和游戏架构的关系 服务器、客户端所需具备的性能和功能 那么网络游戏到底需要哪些网络编程技术呢?为了回答这一问题,我们先来简单了解一下网络编程的特性与游戏架构之间的关系。网络编程的特性根据游戏架构的不同而有所差异,作为铺垫,我们以第2 章中会讲到的C/S MMO、C/S MO、P2P MO 这几种游戏架构为例(有关上述分类请参见表2.4)①,看一下它们之间的区别。 C/S 架构的游戏(C/S MMO、C/S MO) 高性能、功能强大的服务器端编程 × 一般的客户端编程所有的处理都在服务器进行,每台服务器要容纳尽可能多的用户。另一方面,客户端的通信相对比较简单。 P2P 架构的游戏(P2P MO) 一般程度的(Web)服务器端编程 × 高性能、功能强大的客户端编程进行游戏处理的服务器只起辅助作用,由于客户端也要扮演服务器的角色,为此需要在客户端实现支持大量通信量的功能。 总而言之,C/S 架构的游戏要求编程结构满足“服务器端具有高性能”,而P2P 架构的游戏则要求“客户端具有高性能”。 尽管如此,本书中涉及的一些实时游戏,不管在服务器端还是客户端,都要求高性能、高功能的网络编程。 高性能、高功能服务器的特性——网络游戏所需具备的要素 C/S MMO、C/S MO 游戏所要求的高性能、高功能服务器需要具备以下这些特性。 A 小带宽 每秒几次至20 几次,达到几百位通信量的持续连接。 B 极高的连接数 每台服务器需要维持数千至数万个连接。 C 低延迟 处理、结果返回的延迟只能在几毫秒至20 毫秒以内。 -------------------------------- ① 后面将会详细讲述,C/S 架构游戏是指客户端/ 服务器(Client/Server)模式的游戏,P2P MO指利用P2P(Peer to Peer)通信的游戏。MMO(Massively Multiplayer Online)指容纳大量用户的多人网络游戏,而MO(Multiplayer Online)则是指玩家数相对较少的多人游戏。 -------------------------------- D 稳定 服务器端保持游戏状态(Stateful),敌人等可以移动的物体实时地持续行动。Web 服务器的特性与此截然不同。所以一般来说,Web 系统中使用的编程技术在其他的网络游戏中是不使用的。本书稍后也会谈及其中的差异。 高性能、高功能客户端的特性——网络游戏客户端所需具备的要素另一方面,P2P 架构的游戏要求高性能、高功能客户端具备以下特性。 A 小带宽 每秒几次至20 几次,达到几百位通信量的持续连接。 B 连接数少 每个客户端只连接几台机器。 C 低延迟 处理、结果返回的延迟只能在几毫秒至20 毫秒以内。 D 稳定 服务器端保持游戏状态,敌人等可以移动的物体实时地持续行动,此外,画面渲染等非常重要的处理也要同时进行。 E 多样性 必须应对客户端的各种网络状况。 与服务器端相比,客户端的连接数较少,但是在进行渲染等重要处理的同时,必须在延迟很低的情况下进行通信,还要应对网络状况的多样性A,不管是性能上还是功能上,都需要具备一般的Web 服务所不具有的要素。
网络游戏核心技术与实战——0.1网络游戏开发者所需了解的网络编程基础
书名: 网络游戏核心技术与实战
作者: 中嶋谦互
出版社: 人民邮电出版社
译者: 毛姝雯 | 田剑
出版年: 2014-4
页数: 443
定价: 99.00元
装帧: 平装
ISBN: 9787115349354