Unity3D游戏开发之网络游戏服务器架构设计(如何做一名好主程)
基于Unity的多人在线游戏服务器架构设计与实现
基于Unity的多人在线游戏服务器架构设计与实现在当今数字化时代，网络游戏已经成为人们日常生活中不可或缺的一部分。
随着技术的不断发展，多人在线游戏（MMOG）在市场上占据着越来越重要的地位。
而要实现一个稳定、高效的多人在线游戏，服务器架构设计是至关重要的一环。
本文将探讨基于Unity引擎的多人在线游戏服务器架构设计与实现。
1. Unity引擎简介Unity是一款跨平台的游戏开发引擎，被广泛应用于游戏开发、虚拟现实（VR）、增强现实（AR）等领域。
Unity提供了丰富的功能和工具，使开发者能够快速高效地创建出色的游戏作品。
在多人在线游戏开发中，Unity可以作为客户端引擎，负责处理游戏逻辑、渲染等任务。
2. 多人在线游戏服务器架构设计2.1 服务器端架构在设计多人在线游戏服务器架构时，需要考虑以下几个方面：逻辑服务器：负责处理游戏逻辑、计算、数据存储等任务。
消息服务器：处理客户端与服务器之间的通讯消息，确保消息的可靠传输。
资源服务器：存储游戏所需的资源文件，如图片、音频等。
数据库服务器：用于存储用户信息、游戏数据等。
2.2 数据同步与通讯在多人在线游戏中，数据同步和通讯是至关重要的。
服务器需要及时将玩家的操作同步给其他玩家，并确保各个客户端之间的数据一致性。
采用合适的通讯协议和技术可以有效提高数据传输效率和稳定性。
2.3 安全性与防作弊安全性是多人在线游戏开发中必须考虑的问题之一。
为了防止作弊行为对游戏平衡性造成影响，可以采用加密技术、安全验证等手段来保护游戏数据和玩家信息的安全。
3. 实现多人在线游戏服务器3.1 选择合适的服务器框架针对Unity开发的多人在线游戏，可以选择适合的服务器框架来实现服务器端逻辑。
常用的服务器框架包括Photon Server、Mirror 等，它们提供了丰富的功能和组件，能够帮助开发者快速搭建稳定高效的多人在线游戏服务器。
3.2 编写服务器端逻辑代码在选择好服务器框架后，需要编写服务器端逻辑代码来处理客户端请求、同步数据等任务。
网络游戏服务器端的设计与实现
网络游戏服务器端的设计与实现随着互联网技术的不断发展，网络游戏已经成为人们娱乐的重要方式之一。
网络游戏服务器端的设计与实现是游戏开发的关键部分，对于游戏的稳定性和用户体验至关重要。
本文将从以下几个方面详细介绍网络游戏服务器端的设计与实现。
服务器架构设计是网络游戏开发的关键部分，主要包括游戏逻辑处理、玩家数据管理、网络通信等方面。
为了提高游戏的性能和稳定性，可以采用以下几种方式：分布式架构：将游戏服务器划分为多个子系统，每个子系统负责不同的功能，如游戏逻辑处理、玩家数据管理、网络通信等。
每个子系统可以独立运行，提高了系统的可扩展性和稳定性。
负载均衡：通过在服务器集群中分布不同的工作任务，使每个服务器承担的负载均衡，避免单点故障的问题。
高可用性：为了保证游戏的稳定性和可靠性，可以采用高可用性的硬件设备和网络连接，以及备份和恢复机制。
网络通信是网络游戏的核心，对于游戏的实时性和稳定性至关重要。
下面介绍几种常用的网络通信技术：TCP/IP协议：TCP/IP协议是互联网的基础协议，它提供了可靠的数据传输服务。
在游戏开发中，可以使用TCP/IP协议实现服务器和客户端之间的可靠通信。
UDP协议：UDP协议是一种不可靠的数据传输协议，但它可以提供更快的传输速度。
在游戏开发中，可以使用UDP协议实现实时性要求较高的场景，如多人在线对战等。
WebSocket：WebSocket是一种双向通信协议，可以在服务器和客户端之间建立长连接，实现实时通信。
在游戏开发中，可以使用WebSocket实现实时性的游戏场景。
玩家数据管理是网络游戏服务器端的重要组成部分，主要包括玩家账号信息、游戏数据等方面。
为了确保玩家数据的可靠性和安全性，可以采用以下几种方案：数据库管理：使用关系型数据库或非关系型数据库来存储玩家数据，如MySQL、MongoDB等。
通过数据库的索引和查询功能，快速查找和更新玩家数据。
内存管理：使用内存数据库技术，如Redis、Memcached等，将玩家数据存储在内存中，提高数据的读写速度和可靠性。
Unity3D游戏开发之网络游戏服务器架构设计(如何做一名好主程)
Unity3D游戏开发之网络游戏服务器架构设计培训(如何做一名好主程)今天给大家讲一下如何做一个好的主程入手假如，我现在接手一个新项目，我的身份还是主程序。
在下属人员一一到位之前，在和制作人以及主策划充分沟通后，我需要先独自思考以下问题：1、服务器跑在什么样的操作系统环境下？2、采用哪几种语言开发？主要是什么？3、服务器和客户端以什么样的接口通讯？4、采用哪些第三方的类库？除了技术背景之外，考虑这些问题的时候一定要充分考虑项目需求和所能拥有的资源。
我觉得，先不要想一组需要几台机器各有什么功能这样的问题，也不要想需要多少个daemon进程。
假设就一台服务器，就一个进程，把所需要的资源往最小了考虑，把架构往最简单的方向想，直到发现，“哦，这么做无法满足策划要求的并发量”，再去修改设计方案。
操作系统：越单一越好。
虽然FreeBSD的网络性能更好、虽然Solaris非常稳定，但选什么就是什么，最好别混着来。
前端是FreeBSD，后端是Solaris，运营的人会苦死。
也不要瞧不起用Windows的人，用Windows照样也能支持一组一万人在线，总之，能满足策划需求，好招程序员，运营成本低是要点。
不同的操作系统有不同的特性，如果你真的对它们都很熟悉，那么必定能找到一个理由，一个足够充分的理由让你选择A而不是B而不是C。
但做决策的时候要注意不要因小失大。
Programming Language：传统来说，基本都是C/C++。
但是你也知道，这东西门槛很高，好的C/C++程序员很难招。
用Perl/Python/Lua行不行？当然可以。
但是纯脚本也不好，通常来说是混合着来。
你要明白哪些是关键部分，我是说执行次数最多的地方而不是说元宝，这些必须用性能高的语言实现（比如C/C++比如Java），其它像节日活动这样很久才执行一次的，随便吧。
脚本的好处是，可以快速搭原型。
所以，尽早的，在你做完基本的地图和战斗模块之后，立马跑机器人测试吞吐量。
大型网络游戏服务器架构设计与优化
大型网络游戏服务器架构设计与优化随着互联网技术的快速发展和广泛应用，网络游戏作为一种流行的娱乐方式，也得到了越来越多的玩家青睐。
在网络游戏中，大型的游戏服务器是保证游戏稳定性和用户体验的关键。
因此，设计一个高效稳定的网络游戏服务器架构，成为了网络游戏研发团队必须面对和解决的核心问题。
一、网络游戏服务器架构设计原则1. 可扩展性原则网络游戏的用户量是非常大的，服务器硬件配置不可能无限制的提升。
因此，服务器架构必须具备可扩展性，可以根据用户数量和峰值流量进行扩展。
同时，架构设计也要考虑到游戏发展的长期性，让未来的升级可以更加顺畅。
2. 高可靠性原则网络游戏是全天候运行的，一旦出现故障就会影响用户体验，甚至影响游戏经济平衡，导致用户离开。
因此，高可靠性原则是网络游戏服务器架构设计不可忽略的关键要素。
服务器应该具有自我修复功能，可以快速检测和隔离问题。
3. 低延迟原则延迟的高低直接会影响到游戏玩家的体验。
通常来说，游戏延迟在200ms左右，如果超过此值，就会出现卡顿和延迟等现象。
因此，网络游戏服务器架构设计需要 prioritize 低延迟，尤其是需要高准确性的实时游戏，比如说FPS，MOBA，竞速类等。
二、网络游戏服务器架构设计1. 服务器群为了提升服务器的可靠性和扩展性，我们可以采用服务器群架构。
服务器群是由多台服务器组成的集群，每台服务器彼此之间可以进行负载均衡，避免单一点故障造成全局性宕机。
在网络游戏中，服务器群中的服务器可以承担游戏运行环节的不同任务（比如，登录，场景，物品，....），实现分布式任务处理和负载均衡。
2. 分布式存储用户数据，游戏场景数据，游戏物品数据等是网络游戏必不可少的组成部分，因此对于这些数据的存储，我们采用分布式存储系统（比如，HBase, Redis）。
分布式存储系统可以解决单点故障和存储容量的问题。
同时利用分区和副本机制，可以控制数据的可用性和可恢复性。
3. 延迟优化网络传输延迟是游戏体验的重要因素，因此针对网络延迟进行优化是网络游戏服务器架构设计中的重点。
Unity3dC#分布式游戏服务器ET框架介绍-组件式设计
Unity3dC#分布式游戏服务器ET框架介绍-组件式设计前⼏天写了，受到很多⼈关注，QQ群⼏天就加了80多个⼈。
开源这个框架的主要⽬的也是分享⾃⼰设计ET的⼀些想法，所以我准备写⼀系列的⽂章，介绍下⾃⼰的思路跟设计，每篇⼀个主题，这次介绍的是组件设计。
在代码复⽤和组织数据⽅⾯，⾯向对象可能是⼤家第⼀反应。
⾯向对象三⼤特性继承，封装，多态，在⼀定程度上能解决不少代码复⽤，数据复⽤的问题。
不过⾯向对象不是万能的，它也有极⼤的缺陷：1. 数据结构耦合性极强⼀旦⽗类中增加或删除某个字段，可能要影响到所有⼦类，影响到所有⼦类相关的逻辑。
这显得⾮常不灵活，在⼀套复杂的继承体系中，往⽗类中改变字段会变得越来越⿇烦，⽐⽅说ABC是D的⼦类，某天发现需要增加⼀个AB都有的数据，但是C没2. 难以热插拔继承结构⽆法运⾏时增加删除字段，⽐如玩家Player平常是⾛路，使⽤坐骑后就骑马。
问题是坐骑的相关信息就需要⼀直挂在Player对象上⾯。
这就显得很不灵活，我不骑马的时候内存中为啥要有马的数据？接⼝也有同样的问题，⼀个类实现了⼀个接使⽤⾯向对象可能导致灾难性后果，游戏开发中有新⼈有⽼⼈，有技术好的，有技术差的。
⼈都是喜欢偷懒的，当你发现调整继承关系⿇烦的时候，有可能AB中增加⼀个字段为了省事直接就放到⽗类D中去了。
导致C莫名奇妙的多了⼀个⽆⽤的字段。
关键还没法发现，最后导致⽗类D越来越⼤，到最后有可能⼲脆就不⽤ABC了，直接让所有对象都变成D，⽅便嘛！是的，很多游戏就是这么⼲的，开发到最后根本就不管继承关系了，因为想管也管不了了。
⾯向对象在⾯对复杂的游戏逻辑时很⽆⼒，所以很多游戏开发者⼜倒退了回去，使⽤⾯向过程进⾏开发游戏，⾯向过程，简单粗暴，不考虑复杂的继承，不考虑抽象，不考虑多态，是开发届的freestyle，挽起袖⼦就开撸，但同时，代码逻辑的复⽤性，数据的复⽤性也⼤⼤降低。
⾯向过程也不是⼀种好的游戏开发模式。
利用Unity3D技术实现的多人在线游戏设计与优化
利用Unity3D技术实现的多人在线游戏设计与优化Unity3D是一款强大的跨平台游戏开发引擎，被广泛应用于游戏开发领域。
在当今数字化时代，多人在线游戏已经成为游戏市场的主流，因此利用Unity3D技术实现多人在线游戏设计与优化显得尤为重要。
本文将探讨如何利用Unity3D技术来设计和优化多人在线游戏，以提升游戏体验和性能。
1. 多人在线游戏设计在设计多人在线游戏时，首先需要考虑的是游戏的核心玩法和互动方式。
通过Unity3D的强大功能，可以轻松实现多人同时在线的游戏场景。
以下是设计多人在线游戏时需要考虑的几个关键点：1.1 游戏服务器架构在设计多人在线游戏时，服务器架构是至关重要的一环。
合理的服务器架构可以有效地支持大量玩家同时在线，并确保游戏运行稳定。
常见的服务器架构包括P2P（点对点）和Client-Server（客户端-服务器）架构。
根据游戏类型和需求选择适合的服务器架构是设计多人在线游戏的首要任务。
1.2 网络通信多人在线游戏离不开网络通信，而网络通信的质量直接影响着玩家的游戏体验。
在Unity3D中，可以利用UNET（Unity Networking）或第三方插件如Photon等来实现网络通信功能。
通过合理地设计网络通信模块，可以降低延迟、提高同步性能，从而改善玩家之间的互动体验。
1.3 玩家匹配与分组在多人在线游戏中，玩家匹配与分组是一个关键问题。
通过合理地设计匹配算法和分组机制，可以让玩家更好地享受游戏乐趣。
Unity3D提供了Matchmaking服务，可以帮助开发者实现玩家匹配与分组功能，同时也可以根据实际需求进行定制化开发。
2. 多人在线游戏优化除了设计阶段，优化阶段同样至关重要。
优化可以提高游戏性能、减少资源消耗、改善用户体验。
以下是利用Unity3D技术实现多人在线游戏优化的几个关键点：2.1 网络优化在多人在线游戏中，网络优化是至关重要的一环。
通过减少网络数据传输量、合理使用压缩算法、优化网络连接等手段，可以降低延迟、提高同步性能，从而改善玩家之间的互动体验。
网络游戏服务器开发框架设计介绍
⽹络游戏服务器开发框架设计介绍在开发过程中，会先有⼀份开发⼤纲或是⼀份策划案，但是这些在我的开发中可能不会有，或者即使有，也很有可能是我随性写下来的，但是我会尽可能写好它。
⽹络通信层，我会放到单独的SOCKET编程中去讲解，这⾥的主题是游戏的架构设计以及系统模块间的协同⼯作。
所以，在这⾥假设所有的⽹络层都已经开发完毕，具体的⽹络层开发代码不会再这⾥出现，因为这需要很多年的开发经验，或者对SOCKET有⼀定的了解才能够讲述清楚或理解，所以我不想再我还没有⾜够的把握之前去说这样的问题，主要问题是不想让⼈说我不专业；另⼀⽅⾯是不希望给没有接触过SOCKET编程或了解不多的⼈带来误导或困扰。
在开发游戏具体功能前，第⼀个要做的就是理清系统功能，这⾥的系统功能并不是具体的游戏功能，⽽是从软件⾓度出发的，⾏业内部称其为分布式服务器开发，讲的是如何构建⼀个可移植、可分布到不同⽹络机器独⽴或依赖运⾏的应⽤程序。
本系列开发教程是我个⼈游戏经历和⼯作历程的⼀个沉淀，也是我个⼈主观的⼀个未实现版本，在这⾥，我希望它可以以教程的⽅式存在，并去按部就班的⼀步⼀步实现出来。
所有的源码代码都是开源的，我不会有丝毫保留，这样做的⽬的是⽅便很多像我⼀样的游戏狂热者⼊门⽆门，另⼀⽅⾯也是希望前辈们可以对我的错误进⾏指正。
下⾯将具体描述服务器的划分以及功能实现。
此系列开发教程，总共将分为10个模块：它们分别为LoginGate服务器、LoginServer服务器、GameGate服务器、GameServer服务器、IMServer服务器、AIServer服务器、CenterServer服务器、BillingServer服务器、WebServices服务器、DBServer服务器。
1LoginGate：登陆⽹关服务器，将所有的LoginServer服务器地址暴露给最终⽤户，每个LoginGate服务可以挂接n个LoginServer，将最终⽤户的所有请求转发给⽬标LoginServer。
网络游戏服务器的架构设计与优化
网络游戏服务器的架构设计与优化一、背景介绍随着互联网的飞速发展，网络游戏已经成为人们娱乐生活中不可或缺的一部分。
为了支持网络游戏的大规模用户同时在线，网络游戏服务器的架构设计和优化显得尤为重要。
本文将对网络游戏服务器的架构设计和优化进行详细介绍，以期能够帮助开发者更好地设计和优化网络游戏服务器。
二、网络游戏服务器的架构设计1. 服务器集群服务器集群是网络游戏服务器架构中最基本的部分。
通过将服务器分布到多个物理服务器中，可以提高服务器的容错性和可扩展性，降低单个服务器的负载压力。
同时，服务器集群还可以提高整个游戏系统的性能和稳定性。
2. 分布式存储网络游戏服务器涉及大量的用户数据和游戏数据，因此采用分布式存储技术也是非常必要的。
通过将数据分散到多台物理服务器中，既可以减轻单台服务器的负载压力，又可以提高数据的可用性和整个系统的性能。
常见的分布式存储技术包括Hadoop、Cassandra等。
3. 负载均衡负载均衡是网络游戏服务器架构设计中的重要组成部分，通过将请求分散到多个服务器中，可以避免单个服务器过载，提高整个游戏系统的性能和稳定性。
常用的负载均衡算法包括轮询、随机、最少连接等。
4. 数据缓存数据缓存可以提高网络游戏服务器的性能，尤其是针对一些高频率访问的数据。
通过将数据缓存在内存中，可以大大减少数据库的访问次数，从而提高整个系统的吞吐量和响应速度。
常见的数据缓存技术包括Redis、Memcached等。
5. 消息队列消息队列可以帮助游戏服务器将请求与处理分离开来，提高游戏系统的并发性能和可伸缩性。
通过将请求放入消息队列中，可以大大减少瓶颈和延迟，提高整个系统的响应速度和容错性。
常用的消息队列包括RabbitMQ、Kafka等。
三、网络游戏服务器的优化1. 硬件优化网络游戏服务器的硬件优化是一个非常重要的部分，直接关系到系统的性能和稳定性。
在选择硬件设备时，需要考虑到服务器的性能、内存、存储空间、网络带宽等因素，同时还需要选择具有高可靠性和容错性的设备。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Unity3D游戏开发之网络游戏服务器架构设计培训(如何做一名好主程)今天给大家讲一下如何做一个好的主程入手假如，我现在接手一个新项目，我的身份还是主程序。
在下属人员一一到位之前，在和制作人以及主策划充分沟通后，我需要先独自思考以下问题：1、服务器跑在什么样的操作系统环境下？2、采用哪几种语言开发？主要是什么？3、服务器和客户端以什么样的接口通讯？4、采用哪些第三方的类库？除了技术背景之外，考虑这些问题的时候一定要充分考虑项目需求和所能拥有的资源。
我觉得，先不要想一组需要几台机器各有什么功能这样的问题，也不要想需要多少个daemon 进程。
假设就一台服务器，就一个进程，把所需要的资源往最小了考虑，把架构往最简单的方向想，直到发现，“哦，这么做无法满足策划要求的并发量”，再去修改设计方案。
操作系统：越单一越好。
虽然FreeBSD的网络性能更好、虽然Solaris非常稳定，但选什么就是什么，最好别混着来。
前端是FreeBSD，后端是Solaris，运营的人会苦死。
也不要瞧不起用Windows的人，用Windows照样也能支持一组一万人在线，总之，能满足策划需求，好招程序员，运营成本低是要点。
不同的操作系统有不同的特性，如果你真的对它们都很熟悉，那么必定能找到一个理由，一个足够充分的理由让你选择A而不是B而不是C。
但做决策的时候要注意不要因小失大。
Programming Language：传统来说，基本都是C/C++。
但是你也知道，这东西门槛很高，好的C/C++程序员很难招。
用Perl/Python/Lua行不行？当然可以。
但是纯脚本也不好，通常来说是混合着来。
你要明白哪些是关键部分，我是说执行次数最多的地方而不是说元宝，这些必须用性能高的语言实现（比如C/C++比如Java），其它像节日活动这样很久才执行一次的，随便吧。
脚本的好处是，可以快速搭原型。
所以，尽早的，在你做完基本的地图和战斗模块之后，立马跑机器人测试吞吐量。
这时候项目开发进度还不到10%，不行就赶紧改。
此处特别举个例子就是Java GC的问题。
既然你要用java，而jvm需要通过执行garbage collection来回收内存，而garbage collection会使整个应用停顿，那你不妨试一试，内存在达到峰值的时候会停多久？策划可以接受吗？如果不可以，你可以采用其它的GC策略再试一试。
这个问题应该不是Java独有的。
网游和网站应用相比它很注重流畅性。
这是你务必需要考虑的。
至于选择什么样的脚本语言，以及脚本在你的游戏中究竟是占80%还是20%？需要根据需求来看。
有没有游戏完全不用脚本？有。
有没有游戏滥用脚本？也有。
如果你引入脚本的目的是因为策划不会C/C++而你希望策划能自己独立实现更多的游戏功能。
你希望策划去写脚本？脚本也是程序，策划写的脚本难道就比程序员写脚本好？还是因为策划工资便宜？策划因为脚本写错了导致大故障还少吗（此处特别以网易的产品举例）？综合权衡下，还是算了吧。
问问你一起工作的程序员哥们儿，他们最喜欢什么语言，什么用起来最顺手，就用什么当脚本。
注意不光要考虑开发速度快，还要考虑调试方便。
总体来说，操作系统和编程语言的选择，随大流即可。
标新立异没什么好处。
小地方的实现你可以玩玩，整体还是要越保守越好。
通信然后说通讯的问题。
服务器和客户端怎么连接上的？往最下面看，物理和链路层。
有可能是以太网，有可能是ADSL，在北京还有很多像歌华宽带这样的采用75欧同轴电缆或者电力线上网的。
你不要企图在这一层做什么优化，你要充分考虑的是不同的网络传输媒质网络延迟不一样。
更恶心的是你正常的数据包可能会被某些网吧的SB路由器当做P2P数据包给封掉，或是甚至被解析成Wake-On-Lan这样的含义。
杨建还会给你讲，什么是MTU，把数据包限制在多大才能尽量让请求在一个包内发完。
是的，这些很精细的东西，等咱游戏做的差不多了再慢慢研究。
先略过。
往上看，IP层。
再往上，你要考虑用TCP还是UDP或是二者混合。
UDP的优势是overhead 小、延迟低，典型的用例就是《天下贰》，据说是纯UDP。
再比如《龙之谷》，据说是有小部分是UDP。
负面的一点呢，就是它太过于简单所以用起来太过于复杂。
你要是对自己没信心，TCP吧，随大流就好。
往上，采用什么样的应用协议。
大多数rpc协议都是既支持TCP又支持UDP的。
我所用过的有sun rpc、corba、webservice、json、java RMI以及一些专有协议。
如果你有精力，还是自己搞一套吧，网游所用的东西，还是越专有越好，给抓包做外挂的人加一点门槛。
这里非常强调的一点，你采用什么样的序列化方式与你采用什么样的网络协议是无关的，你的应用协议和你传输协议应该也是无关的（既支持TCP又支持UDP的）。
如果做框架的人把自己限制的太死或者耦合太紧，那么用框架的人会非常痛苦。
所以，没必要在此为了性能做过多优化。
结构简单清晰是王道。
很多人对网络开发的认识还停留在定义一个struct、memcpy到socket buffer、send，然后一个劲的给别人强调遇到指针怎么办、数组的长度不能超过多少、整个包的长度不能超过多少等等。
序列化其实是面向对象程序设计的一个很核心的要素。
连glib/gtk/Berkeley DB这些纯C的框架都是基于OOP设计的，所以我觉得您就算是C程序员也没必要排斥它。
我讲这个是说，你应当做应用的人尽可能的避免用memcpy/memset这样的方式初始化数据、传送数据。
如果你是C程序员，你多提供一些g_object_new这样的函数；如果你是C++程序员，写好你的构造和析构函数；如果你是JAVA程序员还死活不懂OOP，那算了吧，改行吧。
网络这一层有些很精妙的东西，尤其是当你规模扩大需要分布式扩展的时候。
你想想看为什么sun rpc需要先去rpcbind询问一次然后才连真正的进程呢？RMI返回的时候为什么需要同时返回IP和端口号呢？web service那么通用，大部分浏览器都支持直接从浏览器调用web service那么为什么主流的方式却是json呢？sun rpc是所有RPC机制中历史最久的吧？它在设计第一版的时候，每个rpc调用都是由一问一答来组成，称为two-way messaging。
客户端在发出请求之后，一直等服务器的答复，如果一直到指定时间后依然没收到答复，那么执行timeout逻辑。
在第一个请求收到答复（或者timeout）之前，无法发起第二个答复。
直到某一天，Sun的程序发现他们需要异步处理一些事情，于是设计了one-way messaging，客户端在发起请求的时候，只要把这个东西塞到本地的IO队列里，就返回。
但是如果socket buffer满了怎么办？还是会等在那里。
于是觉得这个还不彻底，于是又做了Non-Blocking Messaging，在kernel的socket buffer前面加了一个用户态的rpc buffer，大多数时候它都是空的，当socket buffer堆满了的时候，再往这里面塞。
如果这个buffer也满了怎么办？我觉得无非就三种处理手段：１、阻塞。
如果这么做，就是说本来是套非阻塞的设计但是某些情况下还是会阻塞？那么给用的人解释起来太麻烦用起来也太麻烦。
算了。
２、悄然丢弃。
不是所有的数据都可以丢。
聊天的无所谓，但是交易的就不行。
所以需要在消息类型上加判断。
３、关闭连接。
最简单粗暴，却也最有效。
在使用two-way messaging的时候，一定要记住设置超时，省得像某些傻瓜一样因为一个请求把整个server堵死。
但是我觉得timeout设多久完全是个经验值，太大了没作用，太小了失败的太多。
至少在有一点我们可以大松一口气，就是不用担心数据量大到需要多网卡同时分担中断。
通常来说网络游戏的流量都是很小的，对玩家来说一个56K的猫或者128K的DSL就够了。
如果你的策划给你提了一个很BT的需求导致要耗费大量带宽，那么你最好把这个应用分到单独的tcp 连接上，省得因为它阻塞而导致关键的业务（比如地图消息）停滞。
我一直想把rpc的部分实现塞到kernel里。
对客户端的好处是增加了逆向工程的成本，对服务器的好处是网关可以很高效。
就像LVS那样，前端收完包之后在kernel里处理完然后立刻转出去，不用切换到用户态。
而GameServer处理完之后，甚至不用经过网关，直接回复。
目的不在于分担网关的压力，而是说降低响应延迟。
就算让GameServer承担部分加密和压缩的计算量，它的CPU也足够用。
不过对于网游，考虑动态扩容为时太早。
一般都是新开几组服务器。
数据我在做服务器安装包的时候，分的很清楚：程序、配置文件、数据库。
程序，就是编译好的二进制文件。
最好是全静态编译，因为它简单。
动态链接的优点以及其它一些高级话题我后面讲，但是通常来说，动态的复杂的结构得不偿失。
配置文件总体来说可以分为文本文件和二进制文件（废话）。
文本文件的好处是开发过程中易于调试和修改，最终发布后也易于追踪问题。
二进制文件的好处是小、精巧、不易把信息泄露给外人知道。
java的打jar包的技术算是一个折衷的优势吧？我最看重的是易于调试和修改，所以基本都用文本文件。
而这其中，表现力最强的就是xml，所以基本都是xml。
但是xml多了怎么管理就是个问题。
我得整理份文档，每个xml都是什么格式，做什么用途的，最好每个xml再写一个xsd。
事实是配置文件是随着需求变化最频繁的部分，而换个角度说我之前强调的序列化。
所以，正确的思路是这样：1、程序员分析需求文档，确定需要什么样的对象来表示配置2、某套序列化框架，它利用某种xml解析库把xml变成内存中的对象3、策划提供xml只要这个框架做的好，根本不需要文档或xsd来描述xml。
我这里说策划提供xml，那么策划怎么提供xml呢？按照我所看见的策划的习惯，他们最喜欢的是两种方式：1、对于结构简单的数据，编辑excel表2、对于结构复杂的（如涉及树、环的），提供专门的编辑工具对于1，我们可以给excel做plugin,或者做一个工具从excel表导出成xml。
对于2，让编辑工具可以导出成xml。
但是最终很重要很重要很重要的一点就是要让所有的工具集成在一起，做好版本管理以及跨版本diff和merge。
如何管理数据要比如何定义数据如何描述数据更难更重要。
很多同事和我的共识都是：要做一款好游戏，工具很重要。
多个项目做完后，外人能看见的最大的积累就是工具和流程。
数据库数据库在游戏中的重要性，是一个很令人玩味的东西。
你可以听见很多人告诉你说，我们做游戏根本不需要数据库。
是的，像单机游戏那样，在某个目录下创建一个文件，save/load就行了。