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