Firefox真是一個(gè)好東西，配上插件后異常強(qiáng)大，上圖便是我所使用的插件。
網(wǎng)絡(luò)層向應(yīng)用層傳輸數(shù)據(jù)，是個(gè)值得關(guān)注的問題
也是整個(gè)程序運(yùn)行效率的關(guān)鍵點(diǎn)之一。
減少內(nèi)存復(fù)制，或許又是關(guān)鍵。
這個(gè)問題可能是今后的熱點(diǎn)，特此做個(gè)印關(guān)注一下。
http://groups.google.com/group/dev4server/browse_thread/thread/7c4417efebc31452/cc2ae1fb90e15f13#cc2ae1fb90e15f13
本命年真是難過。
本命年第一天，硬盤壞了。
今天早上，腳被車門夾了，晚上，肯定是今年最大的不幸了，和tt吵架了，吵很大很大。怪我太小心眼了吧，我是不怎么管事的人，天大的事情也與我無關(guān)，但在她的事情上，我格外“重視”。她說我有神經(jīng)病，我承認(rèn)。
以前問同事一個(gè)在日本待了幾年的同事，中國人在日本是不是受歧視？
同事告訴我，做人要不卑不亢，在哪里都不會受歧視。
是啊，做人要不卑不亢，為什么老覺得自己不如人呢？
挺起胸口做人，傲視人間笑紅塵。
信號量：
簡單點(diǎn)說，就是
1 一個(gè)整數(shù)變量i。
2 一個(gè)等待進(jìn)程鏈表。
3 一對P/V操作函數(shù)。
P將i減1，如果i<0了，就把當(dāng)前正在運(yùn)行的進(jìn)程加入到進(jìn)程鏈表中，并阻塞之。
V將i加1，如果i>=0,則激活鏈表中的1個(gè)或者多個(gè)進(jìn)程。
同時(shí)適用于單處理器和多處理器
自旋鎖：
在多處理器中，如果修改一些內(nèi)核結(jié)構(gòu)所需要的時(shí)間非常短（短于把進(jìn)程插入進(jìn)程鏈表中并掛起它所需要的時(shí)間），則應(yīng)該使用自旋鎖。
80x86體系結(jié)構(gòu)的兩種硬件約束：
1。ISA總線直接存儲器存取（DMA）只能對RAM的前16MB尋址。
2。在大RAM的32位機(jī)中，由于線性地址空間太小的原因，CPU不能直接訪問所有物理存儲器。
所以，Linux把物理存儲器分為三個(gè)管理區(qū)：
ZONE_DMA <= 16MB
16MB < ZONE_NORMAL < 896MB
ZONE_HIGHMEM > 896MB
在64位機(jī)中沒有使用ZONE_HIGHNEN
摘要: 在Linux系統(tǒng)里，/usr/include/linux/if_pppox.h里面有這樣一個(gè)結(jié)構(gòu)：
1struct pppoe_tag {2 __u16 tag_type;3 __u16 tag_len;4 char&n...
閱讀全文
Ghost Cheng “為了暖場”而提出的議題，引發(fā)了大家熱烈討論。
Hi all:
這兩天maillist好像有點(diǎn)冷清了，我來立個(gè)靶子，大家討論一下MMORPG的邏輯層構(gòu)架。
所謂邏輯層構(gòu)架，就是指MMORPG的跑地圖、聊天轉(zhuǎn)發(fā)、好友上線通知、交易事件等，
比如玩家或NPC跑地圖的時(shí)候，以什么樣的方式通知場景周圍的玩家、轉(zhuǎn)發(fā)聊天對話與好友上線通知的時(shí)候，如何才能盡量不去遍歷玩家鏈表。
先說說我的想法，我處理的方式是基于EventEngine的，所謂EventEngine其實(shí)就是一個(gè)獨(dú)立的線程，維護(hù)一個(gè)Event隊(duì)列，
當(dāng)對列中有事件的時(shí)候就處理。這里的事件包括：玩家動作（移動、攻擊）、NPC動作（移動、攻擊）、聊天、上線、下線等。
當(dāng)數(shù)據(jù)包處理線程，收到玩家上線的數(shù)據(jù)包，就提交一個(gè)事件到隊(duì)列，
同樣，玩家發(fā)來攻擊、聊天的數(shù)據(jù)后，也提交一個(gè)事件到隊(duì)列。
NPC的事件觸發(fā)時(shí)間，由另一個(gè)線程計(jì)算，一旦這個(gè)NPC到了需要移動或攻擊的時(shí)候，就提交一個(gè)事件到隊(duì)列。
這樣確保所有的資源，都只有EventEngine一個(gè)線程訪問，比如地圖上的玩家鏈表等。
我遇到的問題：目前主要是聊天、或好友上線，這些事件處理的時(shí)候，需要遍歷整個(gè)玩家鏈表，
這個(gè)鏈表就是網(wǎng)絡(luò)層的session list，訪問的時(shí)候需要鎖定，如果有大量鎖定遍歷的操作，性能感覺會比較底，
不知道大家有什么好的方案？
希望大家踴躍發(fā)言哦！
http://groups.google.com/group/dev4server/browse_thread/thread/de6320c499f6dc3d/becf3963881399c8#becf3963881399c8
今天再次Review了代碼，但思路卻因此而開始混亂。
從名字上解這兩個(gè)對象：
XmlPullParser當(dāng)然是以“拉”的方式從流中獲取信息。
SocketReader單從字面上理解，功能自然是從Socket上獲取字節(jié)流。
“單一職責(zé)原則”，在幾年前就在我腦子里打下了烙印。The Simpler The Easier，既是我做人的原則，也是我做程序的原則。常理上講，我應(yīng)該盡力維護(hù)這個(gè)原則，讓上述兩個(gè)對象都盡可能的簡單。 在wildfire中，也有SocketReader，然而它的SocketReader卻不是那么簡單，功能遠(yuǎn)遠(yuǎn)超出了字面意義。大部分業(yè)務(wù)都要靠這個(gè)來控制，分配。
受它影響（之前我通讀了wildfire的所有源碼），在tim中也給SocketReader的子類ClientSocketReader等加上了重?fù)?dān)。因?yàn)樗莆樟颂嗟男畔ⅲ瑧?yīng)該說大多數(shù)信息都暴露在這個(gè)地方，Session，Socket，SocketConnection，我實(shí)在找不出理由不讓它參與進(jìn)業(yè)務(wù)。也許，這是OO的一種失敗，但我一時(shí)也找不到新對象來管理這一系列的相關(guān)信息。
XmlPullParser則和SocketReader息息相關(guān)，因?yàn)镾ocket中Read出來的東西首先就要經(jīng)過Parser，才能從字符流形成有用的東西。
在原先的設(shè)計(jì)中，XmlPullParser被SocketReader所包含，并提供了get方法暴露給外界。在很多事件分配的地方，都要XmlPullParser提供信息，之前，都是通過SocketReader間接獲取xpp，高層真的需要直接使用xpp嗎？我覺得不然，高層需要的信息完全可以通過SocketReader來提供。
那么該怎么設(shè)計(jì)兩者的關(guān)系呢？是包含，還是父子？我傾向于包含，但懶惰促使我選擇了父子。目前看起來，父子關(guān)系并沒有帶來什么壞的影響，如果有必要，今后再重構(gòu)吧。
現(xiàn)在結(jié)構(gòu)似乎更為清晰了，SocketReader的子類（ClientSocketReader。。。）會負(fù)責(zé)解析流，并根據(jù)解析出的內(nèi)容進(jìn)行第一層處理，如選擇下級處理器或者是直接計(jì)算業(yè)務(wù)，或者是進(jìn)行轉(zhuǎn)發(fā)。。。根據(jù)不同的子類，表現(xiàn)不同的業(yè)務(wù)族（Client，Server，Agent。。。）
按照全局的事件分配機(jī)制，iq包被InputHandler所分配。
Iq包有兩個(gè)小特點(diǎn)：
一是不需要像auth那樣持續(xù)對話，服務(wù)端只收一次包就可以把一個(gè)iq業(yè)務(wù)處理完。
二是Iq包的接收和應(yīng)答是無序的，靠id對應(yīng)起來。
那么iq的處理機(jī)制，該怎么設(shè)計(jì)呢？
2006.03.05
今天晚上Parser崩潰了，這個(gè)臨時(shí)性的東西真不好伺候阿。
2006.03.06
重新寫了一個(gè)“臨時(shí)”的新PullParser，看起來能應(yīng)付應(yīng)付了，不過暫時(shí)還是不想把精力放到這個(gè)上面，今后再說吧，能測試就行了。不知道什么時(shí)候能找到朋友幫幫我啊。