ACE，Python和Java（我所知道的）中要獲得多線程的能力，都是通過從一個(gè)線程對(duì)象基類繼承，重載特定的成員函數(shù)來實(shí)現(xiàn)。簡單的來看，它用起 來也相當(dāng)簡單，理解起來也不復(fù)雜，但，用過一段時(shí)間之后，就會(huì)發(fā)現(xiàn)處理復(fù)雜問題時(shí)，你會(huì)遇到許多的限制。
1.必須從一個(gè)線程對(duì)象基類繼承嗎？
現(xiàn)在看來是的，否則，你只有使用系統(tǒng)OS提供的線程函數(shù)了。
2.我已經(jīng)有個(gè)類了，它不是從線程對(duì)象基類繼承的，我要使用多繼承嗎？
是的，除非重寫。
3.我有一個(gè)函數(shù)，想讓他在另一個(gè)線程執(zhí)行，一定要寫個(gè)類嗎？
是的。
4.我有一個(gè)類，它的每個(gè)成員函數(shù)我都想他們?cè)诹硗獾木€程中執(zhí)行，怎么辦？
線程對(duì)象基類只有一個(gè)線程函數(shù)，你必須通過某種通訊機(jī)制去讓它執(zhí)行不同的成員函數(shù)。
4.當(dāng)線程在執(zhí)行一個(gè)對(duì)象的某個(gè)成員時(shí)，這個(gè)對(duì)象被刪除了怎么辦？
沒辦法，你必須自己管理對(duì)象的生存期。
嗚呼！問題越來越多，該怎么辦？我們需要某種透明的線程模型，他能處理任意的需要被異步執(zhí)行的類的成員函數(shù)或者普通函數(shù)，它能提供一種策略，使得我們能 自動(dòng)管理處理不同線程中的對(duì)象的生存期。我們現(xiàn)在有了這種工具了嗎？
熟悉Boost的人可能覺得boost.thread也許提供了這種能力。很不幸，它滿足了一部分上述需求。
正在實(shí)現(xiàn)上述需求的一個(gè)線程模型。它將任務(wù)與任務(wù)的執(zhí)行者分離，它支持人任何的任務(wù)，不論它是普通的函數(shù)，還是具有任意參數(shù)的成員函數(shù)，你均能將它作為 一個(gè)任務(wù)拋到其他的線程執(zhí)行，它是非侵入式，通過它所支持的生命期管理，你不用在擔(dān)心對(duì)象在異步執(zhí)行時(shí)被銷毀。它用模板實(shí)現(xiàn)。
開始了一些基礎(chǔ)庫的代碼編寫，基本的設(shè)計(jì)原則是：
1.基于模板
2.盡量使用組合
3.盡量不依賴第三方庫
基礎(chǔ)庫將包含以下幾個(gè)核心的功能：
1.對(duì)象生存期的自動(dòng)管理
2.透明的內(nèi)存管理
3.透明的線程管理
4.數(shù)據(jù)的對(duì)象化存儲(chǔ)
5.遠(yuǎn)程對(duì)象通訊/代理
現(xiàn)在做的是個(gè)Mysql對(duì)象化訪問的組件。我們知道m(xù)ysql是關(guān)系數(shù)據(jù)庫，但我們提供了一組在一定程度下的對(duì)象化操作mysql的功能，使用這個(gè)組
件，你將面對(duì)的是一個(gè)個(gè)對(duì)象，而不在是一張張表，但，面向?qū)ο髷?shù)據(jù)庫現(xiàn)在還處于理論的驗(yàn)證期，現(xiàn)在還沒有成熟的數(shù)據(jù)庫產(chǎn)品被大規(guī)模使用，主要使用的還是關(guān)系數(shù)據(jù)庫，我們提供的這一層對(duì)象化訪問層不可能做到完全的面向?qū)ο髷?shù)據(jù)庫能力，但可以滿足一般的需求，但這就足夠了，至少我是這么認(rèn)為。
所謂的無縫服務(wù)器是指一個(gè)游戲只有一個(gè)游戲世界，游戲中所有的角色都互相可見，可交互的。
傳統(tǒng)的游戲服務(wù)器是分區(qū)的。進(jìn)入游戲之前，先要選擇游戲服務(wù)器組，再選擇一個(gè)服務(wù)進(jìn)入。進(jìn)入游戲后如何要從一個(gè)地圖到另一個(gè)地圖，則要切換服務(wù)器（客戶端或者接入服務(wù)器內(nèi)部切換），對(duì)玩家來說，則是畫面切換，像大話西游，傳奇都是這樣。魔獸世界在進(jìn)入服務(wù)器后，如果不前往另一個(gè)大陸，則無換面切換，但 這不是真正的無縫。
無縫服務(wù)器復(fù)雜的根本是服務(wù)大量（甚至海量）玩家的要求。玩家多意味著交互多，數(shù)據(jù)流量大，必然要將請(qǐng)求發(fā)往多個(gè)服務(wù)器處理，于是問題就來了，那就是服務(wù)器交互。傳統(tǒng)分區(qū)服務(wù)器設(shè)計(jì)也是多服務(wù)器的，但服務(wù)器相數(shù)量較小，交互的復(fù)雜性不大。但，考慮無縫服務(wù)器要服務(wù)的是海量的玩家請(qǐng)求，服務(wù)器數(shù)量比傳統(tǒng)服務(wù)器大的多。
考慮下面的情況：
A玩家連接svr1，B玩家連接svr2，C玩家連接服務(wù)器svr3。現(xiàn)在A要砍B一下，svr1接到了A砍B的請(qǐng)求，但在svr1上沒有B玩家，它如何才能找到B呢？也許加一個(gè)全局的玩家位置服務(wù)器可以解決這個(gè)問題，這個(gè)服務(wù)器上記錄了每個(gè)玩家位于哪個(gè)服務(wù)器。但，考慮下，這個(gè)全局服務(wù)器只有一臺(tái)嗎？它可以處理所有的玩家嗎？如果人數(shù)太多，在增加一臺(tái)這樣的服務(wù)器會(huì)怎么樣？它們之間如何交互？很快就會(huì)發(fā)現(xiàn)，這個(gè)方法行不同。其實(shí)，這種全局服務(wù)器 的存在是分區(qū)服務(wù)器時(shí)代的產(chǎn)物，在無縫的前提下，不會(huì)在有全局服務(wù)器這樣的東西。全局意味著唯一，而無縫則要求無限動(dòng)態(tài)擴(kuò)展。
無縫服務(wù)器的關(guān)鍵是維護(hù)一個(gè)服務(wù)的網(wǎng)狀結(jié)構(gòu)，只有這樣，才可能動(dòng)態(tài)擴(kuò)展。
HI All：
?歡迎大家的加入MMORPG無縫服務(wù)器的討論論壇！
這個(gè)論壇將主要關(guān)注無縫服務(wù)器的架構(gòu)設(shè)計(jì)。我們知道，與傳統(tǒng)的分區(qū)服務(wù)器相比，無縫的世界可以帶給玩家更宏大，真實(shí)的感官體驗(yàn)，擴(kuò)大玩家的互動(dòng)交流，增加游戲樂趣。要知道，網(wǎng)絡(luò)游戲于單機(jī)游戲的根本區(qū)別是，玩家的游戲?qū)ο髲碾娔X轉(zhuǎn)向了與玩家對(duì)等的遠(yuǎn)端世界的玩家。但這也帶來了新的問題。無縫服務(wù)器由于要處理大世界的玩家對(duì)象，原有的基于分區(qū)的服務(wù)器架構(gòu)已不能滿足需求，我們需要處理的玩家交互不是幾千，幾萬，而是十幾萬，甚至上百萬。于是，通訊的壓力急劇增加，業(yè)務(wù)邏輯的復(fù)雜度也成倍上升。如何解決這些問題？想方設(shè)法提高網(wǎng)絡(luò)通訊的性能？減小數(shù)據(jù)流量？增加新的服務(wù)器？顯然，這些想法過于簡單。為了服務(wù)大量玩家，必須設(shè)計(jì)新的服務(wù)器架構(gòu)。?現(xiàn)有的關(guān)于無縫服務(wù)器的構(gòu)架有兩種：基于服務(wù)的架構(gòu)（service-based），基于地圖區(qū)塊的架構(gòu)（area-based)。這兩種架構(gòu)都有各自的優(yōu)缺點(diǎn)，單純想象難以厘清其中的復(fù)雜頭緒。我們期望討論與實(shí)現(xiàn)來發(fā)現(xiàn)設(shè)計(jì)，完善設(shè)計(jì)，達(dá)到我們心中那個(gè)無限廣闊的充滿虛幻的夢想世界。一起加油
吧！
?有一個(gè)開源的無縫服務(wù)器框架會(huì)在以后加入進(jìn)來，歡迎有興趣的朋友貢獻(xiàn)自己的一份力量！
?我有一個(gè)夢想：在朦朦的晨曦里，幾縷金色的光芒透過濃密的樹冠射落下來，其他的隊(duì)員還在熟睡，落葉掉落在他們身上，我必須叫醒他們了，今天的任務(wù)是趕到枯木營地，殺死那個(gè)可惡的枯木法師....
MMORPG無縫服務(wù)器開發(fā)論壇建立，現(xiàn)邀請(qǐng)成員加入！