飯中淹的避難所~~~~~

贊。

感覺過于強調實體，反而讓概念顯得不清楚了，屬于過度抽象。
從現實來講
頻道和聊天者的概念會比較清晰一點。

注入代碼其實無所謂用什么寫，線程有個LPVOID的參數，把需要的數據全部事先寫入遠程進程，然后把數據地址作為參數傳給遠程線程就可以了。這樣無需訪問全局變量。

。。。。并不是說用XML不好，或者否定UI樹什么的。

我也是用的MARKUP來建立UI控件樹，并綁定代碼。不過，我是用了一個中間的DOM抽象數據層。
這樣，不管外面有什么XML，HTML甚至INI，我只要一個數據抽象層放進UI里面就好了。





@Richard Wei

我覺得有幾個問題
1- UI依賴了XML。因為你如果要改變數據源，你需要改變UI內部的東西。
我做的系統里，用了抽象的DOM數據NODE的概念。XML只是建立數據NODE的一個源而已。

2- UI的創建很多都用不到。比如prototype這種，如果你想讓你的UI從數據上創建，那么你就用一個從數據創建就好了。

我的系統里，UI控件的CREATE都是只有統一的一個參數，IDataNode。這樣接口非常簡單。

文章好，
文字顏色不好。。。。

我用RICHEDIT的WINDOWLESS模式，在codeproject上找到的代碼。
最后事情歸結為實現一個RTF的生成器，下載了最新的RTF文檔之后，我徹底萎了。

感覺就是MVC。

GOOD, 這個可以有控件用到別的軟件里嗎？

epoll看看 關系socket
fork看看 關系啟動服務和多進程
信號處理看看 關系錯誤異常
pthread看看 多線程

很好。收藏。

monodevelop以前裝過，菜單文字正常，界面和設計文字全是亂碼。

很好收藏！

支持，以前從未關注過高性能磁盤IO。

磁性的柯南。。。看著他變小的長大的我們這一代。

配圖。。。

我最近也在想做個類似的工具
我覺得還可以增加一個東西，就是休息事件的提前通知，然后可以設置一個便條，記錄下當前正在進行的工作，以便于休息后繼續工作。
我現在想的是輸入一段話，再進入休息狀態。

good！

@Shannon
142483

GOOD!!!!
鍵盤的，用一個按鍵的狀態表，記錄當前是按下還是抬起。

我能想到的就是細分區域的優化。

@dynas
玩家位置，在userserver上有記錄。
agent上有客戶端和gameserver建立的繪畫映射，不需要再經過userserver中轉
@King
純轉發型網管。順帶有加密和解密的工作。

@LOGOS
我是在架構上支持HTTP，后臺邏輯服務可以方便的利用。
你們的運營方還真是照顧呀，哈哈。

感覺上就是一個給你做好基礎引導和保護模式以及中斷調用等部分，然后讓你用C#寫操作系統邏輯層的一個東西。

應該是《操作系統》課程教學用的吧。

不過不排除以后形成一個完善的操作系統。

你也是做游戲研發的吧，
服務器端需要和官方網站的很多WEB系統對接，
如果沒有一個WEB服務的話，
很多事情都很麻煩。

而且在做頁游的時候，如何將POLICY服務，和頁面服務，以及游戲本身的邏輯服務整合到一起，最終的答案也是所有連接統統使用WEB服務。

我還是支持加入WEB服務的做法。
從HTTP到二進制協議并不難。
考慮到越來越多的WEB整合需求，
TELNET協議無法滿足需求。

@康

你說的是每個方法最初的理論基礎。但并不是最好的方法。

@楊粼波
目前的方式是用單字節來表示一個類型。
類型有 int, uint, float, string

int, uint, float 又有數組類型。

string和array是帶16位的Length字段。

array除了1字節的array類型指定，還帶一個1字節的元素數據類型。


對整體容量的增加，有限。

不過，現在這種方式并不是最好的方式。

我認為的最好的方式，所有類型都提取成一個數據類型對象，也就是類似GOOGLE PROTOCOL BUFFER的用額外的描述生成的一個對結構體的描述。這個方式是跟我的數據對象和映射的整體邏輯架構相關的。目標是實現服務器端，在對所有數據和邏輯的描述上形成的整體架構的統一，同時將類型和表義信息從最終數據存儲中去掉。

不過這種情況下，可能會出現版本問題，由于雙方描述的版本差異，導致兼容性問題。我的解決方法，是把原有的類型信息，更換為FIELDINDEX信息，也就是字段索引。在結構體描述的更改過程中，遵循字段出現增加，就增長其FIELDINDEX的原則。這樣，在有限的版本空間內，FIELDINDEX會精確對應到相應的字段上。如果FIELDINDEX超出值域限制，那只有放到新的結構描述中去了。

我在網絡封包這塊，有著很長的一個摸索過程，大概經歷過以下幾個階段：
1- 結構體直接作為封包發送
2- 結構體序列化（封包內只有數據本身，手動編寫序列化和反序列化的方法）
3- 結構體序列化（封包內帶有類型信息，手動編寫序列化和反序列化的方法）
4- 數據對象和數據映射（封包內帶有字段信息，通過數據映射來序列化和反序列化）

這樣做有個好處是不需要定型的struct，處理過程只要傳入一個復合類型value的數組即可，對于統一整體架構，減少代碼工作量很有幫助。

我使用的是類型加數值的序列化和反序列化，封包不僅用于網絡，還用于db，內部消息等地方。

@康
我這里也是這種方法，不過，這里是在解決另外的問題：

當一個角色有多個可見區域的時候，
可見區域重疊，帶來的廣播消息的重復。

@戰魂小筑
我覺得異常在新一代的語言里是用來進行錯誤處理的。
所以異常在我這個體系里是作為一種像是錯誤編號一樣的數據對象存在，
能夠被捕捉到，并由映射進行處理。

@Kevin Lynx
數據也腳本化，我感覺不合適。

我是要提供可視化編輯工具給策劃，讓他們自己去設計數據對象。

腳本這些粗活，就是服務器程序來做。

所有工具都做成各種PAD可部署的，這樣就不用限制辦公地點和時間了。

隨時隨地做事。

有個好的點子可以立即應用到實際的游戲服務中去。

@Kevin Lynx
配置+腳本共同的
每個都可以實時修改
這樣該錯誤，更新什么的，根本不用重啟了

服務器本身的程序就是一堆底層的庫在那里

然后就是支持這些數據對象和映射。

數據對象雖然看起來很復雜，實際上是個簡單功能的容器類，和封包的結構很像。

大部分的事情都是在映射里做的。而這些映射都是腳本的。


腳本我準備用quartz composer那種卡片式的，這樣可以用IPAD，GPAD，樂PAD等各種PAD，用3G卡在某個公園的角落里摸幾下就把服務器BUG給修改好了。

接著我在那邊跟你說的，我是不允許代碼和腳本碰數據對象的屬性的。

屬性必須由對象設計器生成。這個對象設計器是在線的，也就是運行時創建，更改的。

映射也是，映射說起來就是一種腳本，用來關聯對象之間的屬性的東西。

你那個獨立博客在CHROME上會標紅標骷髏頭。

多重繼承真的是個很大的坑。
要小心翼翼的通過。
我以前也是和你一樣的用VOID*的時候出了這個問題。

@臥槽
是的，我確實是個菜鳥。

@megax
Vb的數據庫部分沒用過，不清楚
不過c++里面數據庫的orm不是很好實現，也沒有很多好的庫。
另外是效率和異步考慮，數據庫操作必須可控
還有必要的靈活性
所以使用了存儲過程和連接線程池

不過，我找到一個新的方法來降低邏輯層的數據庫相關復雜度。也是類似對象關系映射，我的方法是根據對象生成一個字段模型（字段偏移和類型表），這個作為映射中心，網絡封包、數據庫表作為映射源和目標。字段模型可外部編輯并從模型生成實體。

然后底層還是這種連接池。

我沒看過《beautiful code》，我不全相信書
我只說自己的想法，我不引經據典
我的回復就是表達我的態度，
我不逃避
我為我每條回復負責
我不想打嘴仗
我認為自己很淺薄
我就是飯中淹。

我也想說句“臥槽”。

耗時很少，這個描述不是很精確。

首先確定你的負載到底是什么，CPU，內存，還是網絡IO。
然后量化并監控你的負載情況，并集中進行管理。
最后，根據你集中管理的量化的負載情況，分配新到來的用戶的接入點。

這個GUI框架挺好的
我是保留WPARAM和LPARAM
不過一些常用的消息，做進了內部邏輯了。比如onpaint這種，在這個內部邏輯里，PARAM就被轉換成真實的變量了，比如HDC這樣的。

另外，我直接用VS的DIALOG編輯器，編輯成無窗口模式，然后用一個FORM套住這個無窗口模式的DIALOG，就間接實現了界面的所見即所得編輯。

用法，無所謂。可用就行。

不錯，深有同感。
不過自己做庫，也有個很嚴重的問題，要想突破自己，也是比較困難的。
我自己維護了一個類似STL的庫，一個網絡庫，還有很多雜七雜八的東西。很多次重構之后，很多架構依然還存在著，只是不斷的修修補補。有時候想推翻重來，卻總是因為各種原因而放棄或者失敗了。
可能做項目的時候，不適合去做庫的推翻重來。
不過有時候做項目時，偶爾會來一些靈感，突然獲得一個能夠推翻之前庫里的東西的想法，但是卻遲遲無法更新到庫里面。因為心里在害怕，沒有大量測試的代碼，會導致庫的不穩定。

為什么不把pointer和counter放在一個結構里，new這個結構？
我做這個東西的時候，就是做這樣一個core_struct，然后加一個core_struct池來維護內存。所有的Ptr傳遞和保存的就是這個core_struct的指針。

頂
另外,文件分配表的位置最好放在包末尾，這樣就沒有數量限制了，也不用預留empty_tags。

微軟的操作系統有開源。可以去找來看。

@Θ§奏之章℡
參閱和真正需求到的，完全不一樣。