如何制作网站?
1) asp 看别人的代码然后根据他的流程自己学者模仿一个
2) Frontpage就可以了
3) 我用了两三天吧,但是我当时是学会了VB的
4) 不涉及算法 最难的是版面设计
5) 看别人的代码然后根据他的流程自己学者模仿一个
技术要求:
(1) 基本知识:知道B/S模式工作原理,有B/S模式的概念。
(2) 开发环境:会使用IIS、FrontPage(或Dreamweaver)写静态和动态的网页,会调试。
(3) HTML:能读懂HTML代码,知道各个标签的含义(html, head, body, title, script, a, front, div, table, thead, tbody, tr, td, th, img, input, button, select, option, textarea, meta)。不需要会手工编写,但能在用工具软件编完的代码视图基础上添加、删除、修改HTML代码。最好能够连CSS也会用。参见《XML编程技术大全》选修课课本2、3章或其他书籍。建议研究、修改一下XML选修课课件的代码。
(4) ASP:能用ASP进行结构化编程(顺序、循环、选择结构)。能知道ASP程序要在HTML代码的什么位置添加。能运用ASP语法。能使用request和session操纵信息。能使用response对象的redirect、write、end方法。能够把从一个网页提交的数据在下一网页得到并显示出来。使用ADODB组件读写、编历数据库。
(5) JavaScript:能够把一下内容运用在HTML标记的onclick属性中:windowopen、windowclose、innerHTML、getElementByID、getElementByName、historygo、historyback。
(别看上面的要求很多,但是学起来很快的。按照(1)~(5)的顺序学,我没说的不作要求,重在实践!先期比较苦,但有成效。)
我有当时我们做的一个新闻发布系统,教程,小作业和一些有用的资料,你可以留下你的邮箱,我发给你。
网上免费发手机短信方法大全
如今,很多朋友经常用手机短信联络,成为“拇指一族”。传统的书信速度慢,电话花费又太贵,E-mail和QQ,也还有双方都要上网的缺点,对比起来,手机短信几乎是随时随地能马上传达。但是发手机短信的人经常会在享受发短信之余,对着不菲的话费单发愁。于是特意到网上逛一番,找到一些免费发手机短信的地方……
1.麻烦网
网址:http�//www.mfun86
.com/sms/index.asp。除了收费的短信外,还有限制每条为35个字的“快乐短信”,这是免费的,只能移动用户使用。但是需要手机注册。
2.雪宝宝短信在线
网址:http://smsyetibbcom/
.com/sms。注册一个账号即可,不需要手机注册。可以发给联通和移动(网上可以免费发给联通的网址实在不多)。站长保证无论是发送方还是接受方都不会收费。好处:所有的短信发送网站上都有记录的,方便你查询和发给其他人。短信可以长达128个汉字。在实际测试中,发现发给联通的有时候会出现接收方收不到短信的情况。据网站说明可能会开展积分制度,积分高的用户可以保证发送成功率为100%。这个网站除了免费短信外,还有免费留言簿、免费计数器、免费的网络电子相册 登录后还可以查询邮编、区号和手机号所在地。
3.zmcc
网址:http�//www.zmcc.com.cn。浙江移动的官方网站。需要浙江移动的手机才能注册。发送范围有限,据测试,至少浙江附近的移动手机是能收到的。目前是免费的,但今后可能要收费,不过收费也是0.1元一条。好处:上面还有通讯录之类的,便于你把常用的手机号码存在上面。而且是官方的网站,注册了手机号也应该不会乱来。不像有些网站知道了你的手机号马上给你一个包月。
4.生命颜色社区
网址:http�//www.go2up.com/cgi-bin/bbs.cgi。不需要注册手机号码,只需要注册论坛账号就可以给所有移动手机发送。注意不登录是看不到免费发送手机短信栏目的。可以自定义短信署名。限制短信长度为160个字符。实际测试中,有时候会发出去了,但对方会收不到。目前确实免费。注意不要点击“发送给联通请按这里”这个链接,到网易界面上去了,那可是收费的……
5.浙大无线工作坊
网址:http�//www.it.zju.edu.cn。他们的目的是配合中国移动精品网络,推广移动梦网。注册需要移动手机号码,不过确实不收费。登录之后可以给所有的移动手机发短信,没有条数限制,据我自己测试没有出现收不到的情况。而且,可以几个人用同一个账号同时登录。需要注意的是发送的时候会显示注册的手机号码。短信可以长达70个字。
6.BQQ
网址:http�//bqq.tencent.com。需要下载BQQ服务器和客户端,还需要向tencent网站申请企业QQ号码(这一步需要填写手机号码以接收认证码,Tencent网站上保证这里填写的手机号码只用来接收认证码,不会用于其他用途,也不会对这个号码收费)。申请到了这个企业QQ号码之后,就可以每天免费发送15条短信了。如果通过了认证(认证需要单位公章或者单位固定电话认证),每天就有100条的免费短信可以发了。短信发送是在BQQ客户端进行。支持通讯录和手机号码分组,接收和发送都是免费的。新的3.1版本还支持把发短信的权限分配给企业内部的其他人,并且可以限制每个人最多发送条数。即使同一个企业的不同的发送者,由于BQQ内部号码不同,也可以区分开的。对方回复的费用就是普通发短信费用,如果你有短信包月的话,回复BQQ短信的费用是不能算在包月里面的。如果你的短信内容比较短,BQQ会在短信后面做个广告的,呵呵。短信长度只能50个汉字。
HTML是最简单、最基本的网页编程语言,同时所有的空间也都支持HTML,HTML网站,一般主要是用于一些广告页/简单的介绍式企业网站/广告页等,基本上不具备互动性,主要制作展示性网站,也叫静态语言,静态并非是说网站上没有动画,而是说没有互动性。同时HTML也是运行速度最快的一样语言,也是对服务器压力最小的,所以动态网站往往都会把网页在显示的时候转化为HTML格式。
动态语言,即为互动式语言,主要是ASP、ASPNET、PHP、JSP等,其中ASP最为常见,网络上大部分网站都是ASP编程语言的,论坛、聊天室、具有注册以及管理功能的网站,基本上都是动态网站,动态网站的优点就是可以实现复杂功能,缺点就是运行速度慢,动态网站必须有相应的支持空间才可以运营。现在PHP语言的发展很快,大多数网站开始转向适用php。国外的开源程序几乎都是php语言的。
C#开源项目(国外的还是很多) 一、Ajax框架 AjaxNET Professional
(AjaxPro)是最先把AJAX技术在微软NET环境下的实现的AJAX框架之一。它在客户端脚本之上创建代理类来调用服务器端的方法。
MagicAjaxNET是一款在ASPNET下创建Web页面提供AJAX技术的框架。它使开发人员很容易把AJAX整合到他们的页面而不需要替换ASPNET控件或自己写javascript脚本代码。
AnthemNET是为ASPNET开发环境提供的开源AJAX工具包,它可以运行于ASPNET 11和20。
二、工作流(workflow)
WorkflowNet是使用微软Net技术基于wmfc标准的创建工作流引擎。
NetBPM是JBpm移植到net平台下的一款开源工作流软件。NetBpm可以很容易和Net应用程序集成在一起,可以创建,执行和管理工作流程序。 Bpm
Tool支持将业务模型转换成软件模型。业务开发人员可以使用模型驱动的方法设计,实现,执行和跟踪业务流程。因此开发人员能够更容易的关注业务逻辑的变化。
其实微软自己的WPF做WorkFlow也很厉害。
三、文本编辑 FCKeditor是一款功能强大的开源在线文本编辑器(DHTML
editor),它使你在web上可以使用类似微软Word 的桌面文本编辑器的许多强大功能。它是轻量级且不必在客户端进行任何方式的安装。 FreeTextBox
是一个基于 Internet Explorer 中 MSHTML 技术的 ASPNET 开源服务器控件。这是一款优秀的自由软件(Free
Software),我们可以轻松地将其嵌入到 Web Forms 中实现 HTML 内容的在线编辑,在新闻发布、博客写作、论坛社区等多种 Web
系统中都会有用途。 VietPad是一个功能完整的跨平台的Java/NET的Vietnamese
Unicode开源文本编辑器。支持打开,编辑,打印,转换,排序,和保存基于文本的Unicode格式的Vietnamese文件。
NetSpell是一款NET框架下的开源拼写检查引擎。 PPC_edit是一款应用在Pocket PC上的开源文本编辑器,它支持TXT, RTF, HTML,
WordML, DocBook 和 ZIP格式的文件,屏幕上会显示国际标准的软键盘。
四、博客(Blog)
NovaShare是一款Blog引擎,它使你创建基于交互式的web的新闻和论坛网站,很像WonkoSlice或Slashdot。管理员可以发布文章和发起投票,浏览者可以创建用户帐号,发表议论等等。
dasBlog是从BlogX 网上日志引擎发展而来。像Trackback ,Pingback
一样增加许多附加的特征,有完整的Blogger/MovableType
API支持,API注释,完整的Radio-style模板定制,支持Mail-To-Weblog/POP3的附件和内嵌,基于WEB的
DHTML,OPML,配置的编辑器。 DotText是一个被使用了数百个blogs的强劲的blog引擎。这是一个N-tiered应用的例子。
tBlogger是一个C#开发的完整的blog网站程序,使用XML配置。
Blog现在可以使用MVC的其他开源项目来构建,这些项目在codeplex上有很多,其中微软自己的就有OXite。
五、系统构建
NETZ是一款免费开源工具,它可以压缩和打包微软 NET 框架可执行文件(EXE,
DLL)以使他们更小。更小的可执行文件占用的磁盘空间较少且因为读取文件时对磁盘的访问较少而使读取数度更快。它和PE(portable
executable)打包工具不一样,NETZ是使用 C# 编写的存粹的 NET 解决方案。NETZ可以用来打包几乎每一种 NET
支持的语言编写的程序。NETZ支持 NET EXE 和 非共享(non-shared)的 DLL
文件。压缩过的程序能以相同的方式解压缩这些对最终用户是透明的。 NAntContrib为NAnt提供定制任务的工具。
Prebuild是XML驱动的一款跨平台pre-build工具,使开发人员很容易就可以为IDE和NET开发工具生成项目或构建文件。它支持 Visual
Studio NET 2002, 2003, 2005, SharpDevelop, MonoDevelop 和 NAnt。
BusyBeeBuilder是NET平台下功能强大,易于使用,可扩展的开源构建自动操作工具。 DracoNET 是 Windows
服务应用程序。它的设计使其容易持续的集成新特性。DracoNET监视你的源代码储存库。当探测到你的项目有变化时自动重新创建项目并把包含变化列表的创建结果发送到你的Email。
Build Studio为软件的自动构件处理提供了一套完整的解决方案。 CruiseControlNET是NET平台下的一款整合服务器。
NAnt类似Apache项目下的Ant,是Net下的开源构建工具。适用在自动编译NET应用的场合,如NET项目的每日构建(nightly
build)。
说老实话,我并不认为系统构建工具的作用真的有那么强大,如果你真的计划做一个很大的项目,且持续开发时间很长,那么你可以使用上面的系统构建工具。
五、图表制作
ZedGraph是C#编写的NET类库,提供了用户控件和web控件。它可以创建2D的线性图、条形图和饼图。它功能完整且有详细的功能自定义,不过
使用默认的选项就足够好用了。一款类似 PieChart, StackBar, LineChart的C#开源图表组件。
NPlot是一款NET下的开源图表类库它值得称道的地方是优雅且灵活的API设计NPlot包含了Windows Form控件,
ASPNET控件和一个创建Bitmap的类。还有一个可用的GTK#控件。 XSCharting是C#开发的图表组件,提供了多种多样的图表选项。
DaveChart是一个免费的DotNet类库。 NChart 提供了很多值得应用在商业,教育等多个领域的2 D图表。
微软自己已经提供了一个chat绘制控件,也就是原来的dunat,如果那个可以满足你的要求,那么完全没有必要使用上面的。但是如果你需要研究画图,作自己定义的chat,那么这些开源的项目将对你有很大的帮助。
六、聊天系统
Dot Net Chat
server是基于DotNet框架开发的聊天服务器和客户端项目。说老实话,我对这个很感兴趣,有时间,要瞧瞧它的代码是咋实现的。
七、内容管理系统(CMS)
Ludico是C#编写的居于ASPNET
20的Portal/CMS系统。它的模块化设计是你可以按照你希望的使用或开发网站功能。它里面有高级的用户管理,一个所见即所的(WYSIWYG)的编辑器等。
mojoPortal是一款C#开发的面相对象网站框架,它可以运行于Windows的ASPNET 和GNU/Linux 或Mac OS X的Mono的平台上。
Cuyahoga是C#开发的灵活的CMS / Portal 解决方案。它可以运行于Microsoft NET 和Mono 平台,支持SQL Server,
PostgreSQL或MySQL作为底层数据库。 Umbraco是一款在net平台下C#开发的开源内容管理系统,该系统效率,灵活,用户界面都不错。 Kodai
CMS是NET平台下的一款功能齐全的内容管理系统。 Rainbow项目是一款使用Microsoft’’s
ASPNET和C#技术开发的有丰富功能的开源内容管理系统。 NkCMS是使用ASPnet和Sql server 2000开发的内容管理系统。
Amplefile是一款内容管理系统,是Net环境下的windows应用程序,使用了Net remoting
GoKryo是一个用ASPNET(C#)NET 实现的简单的内容管理系统,后台数据库使用Microsoft SQL Server 。 ndCMS是
ASPnet
(C#)下的一个内容管理系统。它提供了用户管理,文件管理,一个WYSIWYG编辑器,模板管理,拼写检查和内置的http压缩。ndCMS的目标是提供一个简单而快速的方式部署Net站点以节省你的时间和金钱。
这些开源的CMS我试用了几个,说真的,拿来研究可以,要真的实施,估计很难。
九、论坛系统
YetAnotherForum可以作为ASPNET开发的网站的论坛或是留言板。它使用MSSQL作为底层数据库。
十、安装制作
izfree是一套套免费的工具用于帮助创建使用Microsoft”’’s Windows
Installer 技术的安装程序。使用izfree你可以为你的应用程序制作强劲的安装程序。
Windows Installer XML
(WiX)可以重XML源文件创建Windows程序安装包的工具集。它支持命令行方式,开发人员可以把结合它来创建MSI和MSM安装包一个可以和商业软件安装产品相比的开源打包工具。
一般的需求试用VS
自带的就可以了,更复杂的需要用到InstallShield,这样看起来开源的就没啥意义了。
十一、IoC容器
Springnet是从java的Spring
Framework移植过来的。java的Spring包含了许多功能和特性,在当前的Springnet都有提供。Springnet最初发布的版本包含了一个很有特色的IoC容器。
Castle是一组应用开发的工具,内含一个简单的IoC容器。
StructureMap是NET环境下的一个轻量级依赖注入工具,StructureMap也是一个灵活的、可扩展的通用“插件”机制的NE
我用过StrucutureMap,但是给我的感觉是,试用这个似乎没多发帮助。
十二、网络客户端
NET FTP Client是C#编写的开源类库。
NET Telnet是微软NET
Framework下的C#开发的开源telnet类库。它的灵感来至Java Telnet Application。
metro这个项目是C#编写的类库,它提供了一套丰富的类使开发IP version 4, TCP,
UDP and ICMP等工作更容易。它包含了有很有用的工具如包嗅探器,网络分析工具例如路由跟踪,ping等。
LJNET是LiveJournal站点的客户端。它为LJ在线日志服务提供了简单而强大的用户接口。
NET VNC Viewer 是一款完全用C#开发的开源VNC观察器。它兼容Smartphones,
Pocket PC和Windows的电脑(NET CF or NET Framework)。它比起其它观察器的优点是可以在Pocket
PC上全屏显示而且可以旋转屏幕。
GVDownloader允许你从google videos, metacafe, putfile,
youtube, breakcom 和更多的地方快速下载内含的视频和多媒体。它的包含一个强劲IE插件和位于你系统托盘的独立程序。
DotNetOpenMail能够使你在微软net框架开发的aspnet,
WinForm应用程序发送Email。它是C#编写的开源组件,它不需要使用SystemWebMail类库就可以容易的创建带附件HTML和
Plain-text的Email。程序员不需要知道很多相关的细节就可以使用不同的字符集或不同的MINE编码来创建
multipart/alternative,multipart/related和multipart/mixed的MIME消息。
DotMSN是一款独立的开源类库,它不需要和官方的MSN Messenger交互,因此不必安装MSN
Messenger就可以使用DotMSN和MSN
Messenger服务通信DotMSN是C#编写的,所以NET环境支持的语言都能够使用DotMSN类库使用简单而且实现方便。它灵活,坚固,
轻量级利于整合到任何应用系统使用DotMSN的应用系统能实现从创建消息机器人到自定义客户端等各种不同的功能如果你的应用程序需要和
Messenger服务通信,DotMSN是一个不错的工具
SharpSSH使用C#实现了SSH2协议,它支持SSH, SCP 和 SFTP
OpenPOPNET一组和POP Servers通信的NET类库。
IceChat是为连接多样的IRC Servers设计的Internet Relay Chat
Client。
lphant是为edonkey/emule开发的开源客户端程序。
NET FTP Client C#开发的类库。
OpenSmtpnet 是 C# 开发的开源SMTP组件。它不依赖NET Framework
的SystemWebMail 包中的类。允许开发人员使用不同于MS SMTP的SMTP 服务器且提供了web
service而可以通过HTTP发送email。
这里面有几个值得推荐,例如DotMsn这个,在某些场合就很有用处。
端游、手游服务端常用的架构是什么样的?
类型1:卡牌、跑酷等弱交互服务端卡牌跑酷类
因为交互弱,玩家和玩家之间不需要实时面对面PK,打一下对方的离线数据,计算下排行榜,买卖下道具即可,所以实现往往使用简单的 HTTP服务器:
登录时可以使用非对称加密(RSA, DH),服务器根据客户端uid,当前时间戳还有服务端私钥,计算哈希得到的加密 key 并发送给客户端。之后双方都用 HTTP通信,并用那个key进行RC4加密。客户端收到key和时间戳后保存在内存,用于之后通信,服务端不需要保存 key,因为每次都可以根据客户端传上来的 uid 和 时间戳 以及服务端自己的私钥计算得到。用模仿 TLS的行为,来保证多次 HTTP请求间的客户端身份,并通过时间戳保证同一人两次登录密钥不同。
每局开始时,访问一下,请求一下关卡数据,玩完了又提交一下,验算一下是否合法,获得什么奖励,数据库用单台 MySQL或者 MongoDB即可,后端的 Redis做缓存(可选)。如果要实现通知,那么让客户端定时15秒轮询一下服务器,如果有消息就取下来,如果没消息可以逐步放长轮询时间,比如30秒;如果有消息,就缩短轮询时间到10秒,5秒,即便两人聊天,延迟也能自适应。
此类服务器用来实现一款三国类策略或者卡牌及酷跑的游戏已经绰绰有余,这类游戏因为逻辑简单,玩家之间交互不强,使用 HTTP来开发的话,开发速度快,调试只需要一个浏览器就可以把逻辑调试清楚了。
类型2:第一代游戏服务器 1978
1978年,英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序《MUD1》,在University of Essex于1980年接入 ARPANET之后加入了不少外部的玩家,甚至包括国外的玩家。《MUD1》程序的源代码在 ARPANET共享之后出现了众多的改编版本,至此MUD才在全世界广泛流行起来。不断完善的 MUD1的基础上产生了开源的 MudOS(1991),成为众多网游的鼻祖:
MUDOS采用 C语言开发,因为玩家和玩家之间有比较强的交互(聊天,交易,PK),MUDOS使用单线程无阻塞套接字来服务所有玩家,所有玩家的请求都发到同一个线程去处理,主线程每隔1秒钟更新一次所有对象(网络收发,更新对象状态机,处理超时,刷新地图,刷新NPC)。
游戏世界采用房间的形式组织起来,每个房间有东南西北四个方向可以移动到下一个房间,由于欧美最早的网游都是地牢迷宫形式的,因此场景的基本单位被成为 “房间”。MUDOS使用一门称为LPC的脚本语言来描述整个世界(包括房间拓扑,配置,NPC,以及各种剧情)。游戏里面的高级玩家(巫师),可以不断的通过修改脚本来为游戏添加房间以及增加剧情。早年 MUD1上线时只有17个房间,Roy Trubshaw毕业以后交给他的师弟 Richard Battle,在 Richard Battle手上,不断的添加各种玩法到一百多个房间,终于让 MUD发扬光大。
用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上,使用纯文字进行游戏,每条指令用回车进行分割。比如 1995年国内第一款 MUD游戏《侠客行》,你敲入:”go east”,游戏就会提示你:“后花园 - 这里是归云庄的后花园,种满了花草,几个庄丁正在浇花。此地乃是含羞草生长之地。这里唯一的出口是 north。这里有:花待 阿牧(A mu),还有二位庄丁(Zhuang Ding)”,然后你继续用文字操作,查看阿牧的信息:“look a mu”,系统提示:“花待 阿牧(A mu)他是陆乘风的弟子,受命在此看管含羞草。他看起来三十多岁,生得眉清目秀,端正大方,一表人才。他的武艺看上去不是很高,出手似乎极轻”。然后你可以选择击败他获得含羞草,但是你吃了含羞草却又可能会中毒死亡。在早期网上资源贫乏的时候,这样的游戏有很强的代入感。
用户数据保存在文件中,每个用户登录时,从文本文件里把用户的数据全部加载进来,操作全部在内存里面进行,无需马上刷回磁盘。用户退出了,或者每隔5分钟检查到数据改动了,都会保存会磁盘。这样的系统在当时每台服务器承载个4000人同时游戏,不是特别大的问题。从1991年的 MUDOS发布后,全球各地都在为他改进,扩充,退出新版本,随着 Windows图形机能的增强。1997游戏《UO》在 MUDOS的基础上为角色增加的x,y坐标,为每个房间增加了地图,并且为每个角色增加了动画,形成了第一代的图形网络游戏。
因为游戏内容基本可以通过 LPC脚本进行定制,所以MUDOS也成为名副其实的第一款服务端引擎,引擎一次性开发出来,然后制作不同游戏内容。后续国内的《万王之王》等游戏,很多都是跟《UO》一样,直接在 MUDOS上进行二次开发,加入房间的地图还有角色的坐标等要素,该架构一直为国内的第一代 MMORPG提供了稳固的支持,直到 2003年,还有游戏基于 MUDOS开发。虽然后面图形化增加了很多东西,但是这些MMORPG后端的本质还是 MUDOS。随着游戏内容的越来越复杂,架构变得越来越吃不消了,各种负载问题慢慢浮上水面,于是有了我们的第二代游戏服务器。
类型3:第二代游戏服务器 2003
2000年后,网游已经脱离最初的文字MUD,进入全面图形化年代。最先承受不住的其实是很多小文件,用户上下线,频繁的读取写入用户数据,导致负载越来越大。随着在线人数的增加和游戏数据的增加,服务器变得不抗重负。同时早期 EXT磁盘分区比较脆弱,稍微停电,容易发生大面积数据丢失。因此第一步就是拆分文件存储到数据库去。
此时游戏服务端已经脱离陈旧的 MUDOS体系,各个公司在参考 MUDOS结构的情况下,开始自己用 C在重新开发自己的游戏服务端。并且脚本也抛弃了 LPC,采用扩展性更好的 Python或者 Lua来代替。由于主逻辑使用单线程模型,随着游戏内容的增加,传统单服务器的结构进一步成为瓶颈。于是有人开始拆分游戏世界,变为下面的模型:
游戏服务器压力拆分后得意缓解,但是两台游戏服务器同时访问数据库,大量重复访问,大量数据交换,使得数据库成为下一个瓶颈。于是形成了数据库前端代理(DB Proxy),游戏服务器不直接访问数据库而是访问代理,再有代理访问数据库,同时提供内存级别的cache。早年 MySQL4之前没有提供存储过程,这个前端代理一般和 MySQL跑在同一台上,它转化游戏服务器发过来的高级数据操作指令,拆分成具体的数据库操作,一定程度上代替了存储过程:
但是这样的结构并没有持续太长时间,因为玩家切换场景经常要切换连接,中间的状态容易错乱。而且游戏服务器多了以后,相互之间数据交互又会变得比较麻烦,于是人们拆分了网络功能,独立出一个网关服务 Gate(有的地方叫 Session,有的地方叫 LinkSvr之类的,名字不同而已):
把网络功能单独提取出来,让用户统一去连接一个网关服务器,再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网管进行交换。这样类型的服务器基本能稳定的为玩家提供游戏服务,一台网关服务1-2万人,后面的游戏服务器每台服务5k-1w,依游戏类型和复杂度不同而已,图中隐藏了很多不重要的服务器,如登录和管理。这是目前应用最广的一个模型,到今天任然很多新项目会才用这样的结构来搭建。
人都是有惯性的,按照先前的经验,似乎把 MUDOS拆分的越开性能越好。于是大家继续想,网关可以拆分呀,基础服务如聊天交易,可以拆分呀,还可以提供web接口,数据库可以拆分呀,于是有了下面的模型:
这样的模型好用么?确实有成功游戏使用类似这样的架构,并且发挥了它的性能优势,比如一些大型 MMORPG。但是有两个挑战:每增加一级服务器,状态机复杂度可能会翻倍,导致研发和找bug的成本上升;并且对开发组挑战比较大,一旦项目时间吃紧,开发人员经验不足,很容易弄挂。
比如我见过某上海一线游戏公司的一个 RPG上来就要上这样的架构,我看了下他们团队成员的经验,问了下他们的上线日期,劝他们用前面稍微简单一点的模型。人家自信得很,认为有成功项目是这么做的,他们也要这么做,自己很想实现一套。于是他们义无反顾的开始编码,项目做了一年多,然后,就没有然后了。
现今在游戏成功率不高的情况下,一开始上一套比较复杂的架构需要考虑投资回报率,比如你的游戏上线半年内 PCU会去到多少?如果一个 APRG游戏,每组服务器5千人都到不了的话,那么选择一套更为贴近实际情况的结构更为经济。即使后面你的项目真的超过5千人朝着1万人目标奔的话,相信那个时候你的项目已经挣大钱了 ,你数着钱加着班去逐步迭代,一次次拆分它,相信心里也是乐开花的。
上面这些类型基本都是从拆分 MUDOS开始,将 MUDOS中的各个部件从单机一步步拆成分布式。虽然今天任然很多新项目在用上面某一种类似的结构,或者自己又做了其他热点模块的拆分。因为他们本质上都是对 MUDOS的分解,故将他们归纳为第二代游戏服务器。
类型4:第三代游戏服务器
2007从魔兽世界开始无缝世界地图已经深入人心,比较以往游戏玩家走个几步还需要切换场景,每次切换就要等待 LOADING个几十秒是一件十分破坏游戏体验的事情。于是对于 2005年以后的大型 MMORPG来说,无缝地图已成为一个标准配置。比较以往按照地图来切割游戏而言,无缝世界并不存在一块地图上面的人有且只由一台服务器处理了:
每台 Node服务器用来管理一块地图区域,由 NodeMaster(NM)来为他们提供总体管理。更高层次的 World则提供大陆级别的管理服务。这里省略若干细节服务器,比如传统数据库前端,登录服务器,日志和监控等,统统用 ADMIN概括。在这样的结构下,玩家从一块区域走向另外一块区域需要简单处理一下:
玩家1完全由节点A控制,玩家3完全由节点B控制。而处在两个节点边缘的2号玩家,则同时由A和B提供服务。玩家2从A移动到B的过程中,会同时向A请求左边的情况,并向B请求右边的情况。但是此时玩家2还是属于A管理。直到玩家2彻底离开AB边界很远,才彻底交由B管理。按照这样的逻辑将世界地图分割为一块一块的区域,交由不同的 Node去管理。
对于一个 Node所负责的区域,地理上没必要连接在一起,比如大陆的四周边缘部分和高山部分的区块人比较少,可以统一交给一个Node去管理,而这些区块在地理上并没有联系在一起的必要性。一个 Node到底管理哪些区块,可以根据游戏实时运行的负载情况,定时维护的时候进行更改 NodeMaster 上面的配置。于是碰到第一个问题是很多 Node服务器需要和玩家进行通信,需要问管理服务器特定UID为多少的玩家到底在哪台 Gate上,以前按场景切割的服务器这个问题不大,问了一次以后就可以缓存起来了,但是现在服务器种类增加不少,玩家又会飘来飘去,按UID查找玩家比较麻烦;另外一方面 GATE需要动态根据坐标计算和哪些 Node通信,导致逻辑越来越厚,于是把:“用户对象”从负责连接管理的 GATE中切割出来势在必行于是有了下面的模型:
网关服务器再次退回到精简的网络转发功能,而用户逻辑则由按照 UID划分的 OBJ服务器来承担,GATE是按照网络接入时的负载来分布,而 OBJ则是按照资源的编号(UID)来分布,这样和一个用户通信直接根据 UID计算出 OBJ服务器编号发送数据即可。而新独立出来的 OBJ则提供了更多高层次的服务:
对象移动:管理具体玩家在不同的 Node所管辖的区域之间的移动,并同需要的 Node进行沟通。
数据广播:Node可以给每个用户设置若干 TAG,然后通知 Object Master 按照TAG广播。
对象消息:通用消息推送,给某个用户发送数据,直接告诉 OBJ,不需要直接和 GATE打交道。
好友聊天:角色之间聊天直接走 OBJ/OBJ MASTER。整个服务器主体分为三层以后,NODE专注场景,OBJ专注玩家对象,
GATE专注网络。这样的模型在无缝场景服务器中得到广泛的应用。但是随着时间的推移,负载问题也越来越明显,做个活动,远来不活跃的区域变得十分活跃,靠每周维护来调整还是比较笨重的,于是有了动态负载均衡。动态负载均衡有两种方法,第一种是按照负载,由 Node Master 定时动态移动修改一下各个 Node的边界,而不同的玩家对象按照先前的方法从一台 Node上迁移到另外一台 Node上:
图11 动态负载均衡
Node Master定时查找地图上的热点区域,计算新的场景切割方式,然后告诉其他服务器开始调整,具体处理方式还是和上面对象跨越边界移动的方法一样。但是上面这种方式实现相对复杂一些,于是人们设计出了更为简单直接的一种新方法:
图12 基于网格的动态负载均衡
于网格的动态负载均衡还是将地图按照标准尺寸均匀切割成静态的网格,每个格子由一个具体的Node负责,但是根据负载情况,能够实时的迁移到其他 Node上。在迁移分为三个阶段:准备,切换,完成。三个状态由Node Master负责维护。准备阶段新的 Node开始同步老 Node上面该网格的数据,完成后告诉NM;NM确认OK后同时通知新旧 Node完成切换。完成切换后,如果 Obj服务器还在和老的 Node进行通信,老的 Node将会对它进行纠正,得到纠正的 OBJ将修正自己的状态,和新的 Node进行通信。
很多无缝动态负载均衡的服务端宣称自己支持无限的人数,但不意味着 MMORPG游戏的人数上限真的可以无限扩充,因为这样的体系会受制于网络带宽和客户端性能。带宽决定了同一个区域最大广播上限,而客户端性能决定了同一个屏幕到底可以绘制多少个角色。
从无缝地图引入了分布式对象模型开始,已经完全脱离 MUDOS体系,成为一种新的服务端模型。又由于动态负载均衡的引入,让无缝服务器如虎添翼,容纳着超过上一代游戏服务器数倍的人数上限,并提供了更好的游戏体验,我们称其为第三代游戏服务端架构。网游以大型多人角色扮演为开端,RPG网游在相当长的时间里一度占据90%以上,使得基于 MMORPG的服务端架构得到了蓬勃的发展,然而随着玩家对RPG的疲惫,各种非MMORPG游戏如雨后春笋般的出现在人们眼前,受到市场的欢迎。
类型5:战网游戏服务器
经典战网服务端和 RPG游戏有两个区别:RPG是分区分服的,北京区的用户和广州区的用户老死不相往来。而战网,虽然每局游戏一般都是 8人以内,但全国只有一套服务器,所有的玩家都可以在一起游戏,而玩家和玩家之使用 P2P的方式连接在一起,组成一局游戏:
玩家通过 Match Making 服务器使用:创建、加入、自动匹配、邀请 等方式组成一局游戏。服务器会选择一个人做 Host,其他人 P2P连接到做主的玩家上来。STUN是帮助玩家之间建立 P2P的牵引服务器,而由于 P2P联通情况大概只有 75%,实在联不通的玩家会通过 Forward进行转发。
大量的连接对战,体育竞技游戏采用类似的结构。P2P有网状模型(所有玩家互相连接),和星状模型(所有玩家连接一个主玩家)。复杂的游戏状态在网状模型下难以形成一致,因此星状P2P模型经受住了历史的考验。除去游戏数据,支持语音的战网系统也会将所有人的语音数据发送到做主的那个玩家机器上,通过混音去重再编码的方式返回给所有用户。
战网类游戏,以竞技、体育、动作等类型的游戏为主,较慢节奏的 RPG(包括ARPG)有本质上的区别,而激烈的游戏过程必然带来到较 RPG复杂的多的同步策略,这样的同步机制往往带来的是很多游戏结果由客户端直接计算得出,那在到处都是破解的今天,如何保证游戏结果的公正呢?
主要方法就是投票法,所有客户端都会独立计算,然后传递给服务器。如果结果相同就更新记录,如果结果不一致,会采取类似投票的方式确定最终结果。同时记录本剧游戏的所有输入,在可能的情况下,找另外闲散的游戏客户端验算整局游戏是否为该结果。并且记录经常有作弊嫌疑的用户,供运营人员封号时参考。
类型7:休闲游戏服务器
休闲游戏同战网服务器类似,都是全区架构,不同的是有房间服务器,还有具体的游戏服务器,游戏主体不再以玩家 P2P进行,而是连接到专门的游戏服务器处理:
和战网一样的全区架构,用户数据不能象分区的 RPG那样一次性load到内存,然后在内存里面直接修改。全区架构下,为了应对一个用户同时玩几个游戏,用户数据需要区分基本数据和不同的游戏数据,而游戏数据又需要区分积分数据、和文档数据。胜平负之类的积分可以直接提交增量修改,而更为普遍的文档类数据则需要提供读写令牌,写令牌只有一块,读令牌有很多块。同帐号同一个游戏同时在两台电脑上玩时,最先开始的那个游戏获得写令牌,可以操作任意的用户数据。而后开始的那个游戏除了可以提交胜平负积分的增量改变外,对用户数据采用只读的方式,保证游戏能运行下去,但是会提示用户,游戏数据锁定。
类型8:现代动作类网游
从早期的韩国动作游戏开始,传统的战网动作类游戏和 RPG游戏开始尝试融合。单纯的动作游戏玩家容易疲倦,留存也没有 RPG那么高;而单纯 RPG战斗却又慢节奏的乏味,无法满足很多玩家激烈对抗的期望,于是二者开始融合成为新一代的:动作 + 城镇 模式。玩家在城镇中聚集,然后以开副本的方式几个人出去以动作游戏的玩法来完成各种 RPG任务。本质就是一套 RPG服务端+副本服务端。由于每次副本时人物可以控制在8人以内,因此可以获得更为实时的游戏体验,让玩家玩的更加爽快。
说了那么多的游戏服务器类型,其实也差不多了,剩下的类型大家拼凑一下其实也就是这个样子而已。
0条评论