|
|
置頂隨筆
Stool - Easily switch VPN server for Mac 發(fā)布
主要功能:
1.方便管理大量VPN服務(wù)器和賬戶
2.批量檢測VPN服務(wù)器速度
3.方便的切換VPN連接,并自動監(jiān)測VPN連接狀態(tài).
4.支持L2TP和PPTP.
完全免費(fèi),歡迎大家使用.
下一步:計劃加入狀態(tài)欄支持.
截圖:
2014年12月10日
Stool - Easily switch VPN server for Mac 發(fā)布
主要功能:
1.方便管理大量VPN服務(wù)器和賬戶
2.批量檢測VPN服務(wù)器速度
3.方便的切換VPN連接,并自動監(jiān)測VPN連接狀態(tài).
4.支持L2TP和PPTP.
完全免費(fèi),歡迎大家使用.
下一步:計劃加入狀態(tài)欄支持.
截圖:
2011年8月11日
weak table是什么意思,建議不要看中文翻譯的,我以前看了半天還是沒懂啥子意思. lua 手冊原文是這樣解釋的: A weak table is a table whose elements are weak references. A weak reference is ignored by the garbage collector. In other words, if the only references to an object are weak references, then the garbage collector will collect this object. A weak table can have weak keys, weak values, or both. A table with weak keys allows the collection of its keys, but prevents the collection of its values. A table with both weak keys and weak values allows the collection of both keys and values. In any case, if either the key or the value is collected, the whole pair is removed from the table. The weakness of a table is controlled by the __mode field of its metatable. If the __mode field is a string containing the character 'k', the keys in the table are weak. If __mode contains 'v', the values in the table are weak. After you use a table as a metatable, you should not change the value of its __mode field. Otherwise, the weak behavior of the tables controlled by this metatable is undefined. 在lua中,像table,userdata,function這些類型的值都是引用傳遞,通過引用計數(shù)來判斷是否收掉對象,而弱引用(weak reference)會被垃圾回收器忽略.weak table就是它的元素是弱引用的,一個元素(鍵值對)可能鍵是弱引用,也可能值是弱引用的,也可能都是弱引用, 這個特性是通過弱表的metatable的__mode的值來設(shè)置的,特別有意思的是,當(dāng)弱表中一個鍵值對,它的鍵或值關(guān)聯(lián)(引用/指向)的那個對象被垃圾回收器回收的時候,這個鍵值對會從弱表中被自動刪除掉.這是個很重要的特點(diǎn). 那么弱表到底有什么用呢? 在lua的wiki中有一篇使用userdata的例子 ,其中就很巧妙的用到了弱表,原文地址 http://lua-users.org/wiki/CppBindingWithLunar
這篇文章介紹了如何通過userdata綁定c++對象到腳本中 fulluserdata能夠設(shè)置metatable,也就能模擬出對象的效果出來,對一個C++的類的對象實(shí)例來說,push到腳本中,一般是創(chuàng)建了一個userdata,文章中用弱表避免了同一個對象實(shí)例(指針) push到腳本中,多次創(chuàng)建userdata的問題. 換句話來說,如果C++對象的生存周期是靠lua的垃圾回收來控制的話(userdata被回收時,調(diào)用元表的__gc方法,__gc方法中析構(gòu)c++對象),一個C++對象只能有一個唯一的userdata. 在userdata的metatable中創(chuàng)建一個值是弱引用的弱表,用C++對象指針做鍵,每次push c++對象的時候,就去用指針值查弱表,如果有,就push那個userdata,沒有就創(chuàng)建, 同時,當(dāng)userdata是被弱引用的,當(dāng)被垃圾回收掉的時候,弱表中它所在的鍵值對自動被銷毀了.
最近做了個DEMO,飛機(jī)追飛機(jī)的. 利用AOI模塊產(chǎn)生的enterAOI,LeaveAOI事件 觸發(fā)NPC追隨玩家 順便也測試下服務(wù)器實(shí)體的歐拉角計算 先運(yùn)行RegionApp.exe 然后再運(yùn)行ClientDemo WSAD 前后左右 J上K下 客戶端做的很簡單..., 支持多開... 下載DEMO
2011年6月20日
最近在優(yōu)化游戲服務(wù)器的AOI（area of interest)部分，位置有關(guān)的游戲?qū)嶓w一般都有一個視野或關(guān)心的范圍，
當(dāng)其他實(shí)體進(jìn)出某個實(shí)體的這個范圍的時候，就會觸發(fā)leaveAOI或enterAOI事件，并維護(hù)一份AOI 實(shí)體列表。
我們來考慮最簡單的實(shí)現(xiàn)，假設(shè)區(qū)域R中有1000個Entity，當(dāng)某個entity位置發(fā)生變化時，需要計算entity的AOI事件和列表，偽代碼如下：
function onEntityMove(who)
for entity in entities do
if who <> entity then
計算who和entity之間的距離
如果who移動前entity在who的AOI范圍內(nèi)，且現(xiàn)在在范圍外
觸發(fā)who.onLeaveAOI(entity)
如果who移動前entity在who的AOI范圍外，且現(xiàn)在在范圍內(nèi)
觸發(fā)who.onEnterAOI(entity)
如果who移動前在 entity的AOI范圍內(nèi)，且現(xiàn)在在范圍外
觸發(fā)entity.onLeaveAOI(who)
如果who移動前在 entity的AOI范圍外，且現(xiàn)在在 范圍內(nèi)
觸發(fā)entity.onEntityAOI(who)
end
end
end
每次一個實(shí)體移動一次位置就要遍歷1000個實(shí)體來計算，這 樣做顯然不行，效率太低了，
那么就需要引入場景管理，將區(qū)域R分成n個格子，每個格子維護(hù)一個實(shí)體鏈表，entity移動時，只遍歷它所在的格子和周圍的8個格子的實(shí)體鏈表，
再優(yōu)化下，可以加入AOI圓和格子的碰撞檢查，9個格子中再去掉沒有相交的格子。。。等等
也有用四叉樹來進(jìn)行場景管理的。
還有些方案更簡單，直接是畫格子，按以實(shí)體為中心的九個格子進(jìn)行位置廣播， 實(shí)體從一個格子移動到另外的格子時觸發(fā)事體。。好處是計算量簡單，缺點(diǎn)是帶寬占用大
我上面的方案都試過了，效率和帶寬占用都不理想，最近終于弄出一個新的方案，現(xiàn)在的AOI計算量是我們服務(wù)器以前計算量的1/40-1/80，由于涉及到公司的保密制度，不便細(xì)說，上幾個測試的抓圖：
機(jī)器配置：win7 ,T5870 inter雙核2G,2G內(nèi)存
20個entity 隨機(jī)運(yùn)動計算一次所有entity AOI的時間在0.02毫秒左右：
220個實(shí)體，選擇的實(shí)體AOI范圍里有68個實(shí)體：
4000個實(shí)體，選擇的實(shí)體的AOI區(qū)域里有465個實(shí)體
AOIDemo.exe 下載
2010年12月29日
SOA:Service-oriented architecture 最近在做游戲服務(wù)器引擎，查了不少有關(guān)SOA的設(shè)計方面的資料。發(fā)現(xiàn)JAVA世界有相當(dāng)多的技術(shù)標(biāo)準(zhǔn)。 其中比較好的是OSGi （ http://www.osgi.org/About/WhatIsOSGi），OSGi技術(shù)是面向Java的動態(tài)模型系統(tǒng)。OSGi服務(wù)平臺向Java提供服務(wù)，這些服務(wù)使Java成為軟件集成和軟件開發(fā)的首選環(huán)境。Java提供在多個平臺支持產(chǎn)品的可移植性。OSGi技術(shù)提供允許應(yīng)用程序使用精煉、可重用和可協(xié)作的組件構(gòu)建的標(biāo)準(zhǔn)化原語。這些組件能夠組裝進(jìn)一個應(yīng)用和部署中。 參考它的思路，結(jié)合C++語言的特點(diǎn)，我將一個服務(wù)器基礎(chǔ)框架設(shè)計成了這樣一種:  一個服務(wù)器應(yīng)用，由多個組件組成，組件物理上可以是動態(tài)庫，也可以是EXE里一段實(shí)際的代碼，每個組件可以向ApplicationFramework注冊多個服務(wù)（比如日志服務(wù)，網(wǎng)絡(luò)服務(wù)等）。 ApplicationFramework啟動時，通過配置文件，動態(tài)加載和啟動組件，讀取服務(wù)的可配置屬性。Framework觸發(fā)IComponentActivator的OnStart() 和OnStop()事件，在Start事件中，可以注冊組件自己的服務(wù)，也可以加入一個服務(wù)監(jiān)聽器來監(jiān)聽關(guān)心的服務(wù)的注冊，注銷等事件。 我隨便畫了幾個大概的接口： 
2010年10月15日
替換^M字符
在Linux下使用vi來查看一些在Windows下創(chuàng)建的文本文件，有時會發(fā)現(xiàn)在行尾有一些“^M”。有幾種方法可以處理。
1.使用dos2unix命令。一般的分發(fā)版本中都帶有這個小工具（如果沒有可以根據(jù)下面的連接去下載），使用起來很方便:
$ dos2unix myfile.txt
上面的命令會去掉行尾的^M。
2.使用vi的替換功能。啟動vi，進(jìn)入命令模式，輸入以下命令:
:%s/^M$//g # 去掉行尾的^M。
:%s/^M//g # 去掉所有的^M。
:%s/^M/[ctrl-v]+[enter]/g # 將^M替換成回車。
:%s/^M/\r/g # 將^M替換成回車。
3.使用sed命令。和vi的用法相似：
$ sed -e ‘s/^M/\n/g’ myfile.txt
注意：這里的“^M”要使用“CTRL-V CTRL-M”生成，而不是直接鍵入“^M”。
轉(zhuǎn)自：http://hi.baidu.com/mofeis/blog/item/23c7b2fb92dc97234e4aea6d.html
2010年8月30日
2010年7月29日
編輯~/.vimrc 加入以下代碼
1 autocmd BufNewFile *.[ch],*.hpp,*.cpp exec ":call SetTitle()"
2
3 "加入注釋
4 func SetComment()
5 call setline(1,"/*===============================================================")
6 call append(line("."), "* Copyright (C) ".strftime("%Y")." All rights reserved.")
7 call append(line(".")+1, "* ")
8 call append(line(".")+2, "* 文件名稱：".expand("%:t"))
9 call append(line(".")+3, "* 創(chuàng) 建 者：蔣浩")
10 call append(line(".")+4, "* 創(chuàng)建日期：".strftime("%Y年%m月%d日"))
11 call append(line(".")+5, "* 描 述：")
12 call append(line(".")+6, "*")
13 call append(line(".")+7, "* 更新日志：")
14 call append(line(".")+8, "*")
15 call append(line(".")+9, "================================================================*/")
16 endfunc
17
18 "定義函數(shù)SetTitle，自動插入文件頭
19 func SetTitle()
20 call SetComment()
21 if expand("%:e") == 'hpp'
22 call append(line(".")+10, "#ifndef _".toupper(expand("%:t:r"))."_H")
23 call append(line(".")+11, "#define _".toupper(expand("%:t:r"))."_H")
24 call append(line(".")+12, "#ifdef __cplusplus")
25 call append(line(".")+13, "extern \"C\"")
26 call append(line(".")+14, "{")
27 call append(line(".")+15, "#endif")
28 call append(line(".")+16, "")
29 call append(line(".")+17, "#ifdef __cplusplus")
30 call append(line(".")+18, "}")
31 call append(line(".")+19, "#endif")
32 call append(line(".")+20, "#endif //".toupper(expand("%:t:r"))."_H")
33 elseif expand("%:e") == 'h'
34 call append(line(".")+10, "#pragma once")
35 elseif &filetype == 'c'
36 call append(line(".")+10,"#include \"".expand("%:t:r").".h\"")
37 elseif &filetype == 'cpp'
38 call append(line(".")+10, "#include \"".expand("%:t:r").".h\"")
39 endif
40 endfunc
41
2010年7月6日
一個典型的游戲服務(wù)器設(shè)計中，一般都是用的多線程，服務(wù)器中一般運(yùn)行兩類線程，N個SOCKET IO線程，1個邏輯線程，
IO線程接受客戶端發(fā)來的信息，通過消息隊(duì)列發(fā)送給邏輯線程處理后，再發(fā)送消息給客戶端，發(fā)送消息這里一般是IO線程處理實(shí)際發(fā)送。
其實(shí)我認(rèn)為，如果邏輯線程都是消耗的CPU運(yùn)算資源的話，服務(wù)器完全采用單線程的方式來做。
首先，我們看IO處理，基本就是數(shù)據(jù)入隊(duì)、出隊(duì)，send、recv操作，作為服務(wù)器的SOCKET處理一般都是異步SOCKET，也就是說，send、recv操作只是將信息copy到socket底層的發(fā)送接收緩沖區(qū)去了，不存在IO堵塞的問題。
然后，我們再來看邏輯處理，前面已經(jīng)說了，采用單線程的前提是邏輯處理只是消耗CPU運(yùn)算資源，那么，不管你開幾個線程，對單核的CPU來說，它的處理速度就是這么多，并不會因?yàn)槟憔€程開的越多，就處理的越快。
因此我們可不可以這樣說呢，在單核機(jī)器上，只消耗CPU運(yùn)算的服務(wù)，多線程并不比單線程能提高多少效率。
接下來，我們再討論下多核的情況，你肯定要想，我這臺服務(wù)器是4個雙核CPU，就只跑一個單線程的服務(wù)器不是虧死了，多線程多好，我開8個線程，就能很好的利用我的機(jī)器啦。是啊，我也覺得這樣很好，不過在LINUX、UNIX下，對線程的支持并不像WINDOWS下那么好，LINUX、UNIX下一般都是用LWP（輕量級進(jìn)程）的方式來支持多線程程序的，Linux內(nèi)核只提供了輕量進(jìn)程的支持，限制了更高效的線程模型的實(shí)現(xiàn)，但Linux著重優(yōu)化了進(jìn)程的調(diào)度開銷，一定程度上也彌補(bǔ)了這一缺陷。同時，濫用多線程也會造成不必要的上下文切換，不必要的同步機(jī)制的引入（如pthread_mutex），讓程序頻繁的在內(nèi)核和用戶間頻繁切換。另外，從開發(fā)角度來看，單線程開發(fā)比多線程環(huán)境開發(fā)更不容易出錯和更加健壯。
在游戲服務(wù)器架構(gòu)中，為了提高玩家在線人數(shù)，實(shí)現(xiàn)負(fù)載均衡，現(xiàn)在一般都是采用分布式的多進(jìn)程服務(wù)器集群的方式，我們來看看服務(wù)器集群中，每個服務(wù)進(jìn)程是采用多線程的方式還是單線程的方式好呢？我覺得，對于有慢速IO訪問的需求的應(yīng)用進(jìn)程，多線程肯定比單線程好，最典型的情況就是數(shù)據(jù)庫訪問這塊，完全可以采用N個DB線程，一個邏輯線程的架構(gòu)，而對只是消耗CPU運(yùn)算資源的應(yīng)用進(jìn)程，盡量單線程就行了，如果覺得單線程負(fù)載不行的話，完全可以分成多個進(jìn)程來跑。。
以上只是我自己的一些看法，表達(dá)有限，歡迎指正。。。
2010年7月5日
boost里的program_options提供程序員一種方便的命令行和配置文件進(jìn)行程序選項(xiàng)設(shè)置的方法。 其文檔例子中有如下代碼：
1 using namespace boost::program_options;
2 //聲明需要的選項(xiàng)
3 options_description desc("Allowed options");
4 desc.add_options()
5 ("help,h", "produce help message")
6 ("person,p", value<string>()->default_value("world"), "who");
看第4到6行，是不是感覺很怪？這種方式體現(xiàn)了函數(shù)式編程中最大的特點(diǎn)：函數(shù)是一類值，引用資料來說, 所謂“函數(shù)是一類值（First Class Value）”指的是函數(shù)和值是同等的概念，一個函數(shù)可以作為另外一個函數(shù)的參數(shù)，也可以作為值使用。如果函數(shù)可以作為一類值使用，那么我們就可以寫出一些函數(shù)，使得這些函數(shù)接受其它函數(shù)作為參數(shù)并返回另外一個函數(shù)。比如定義了f和g兩個函數(shù)，用compose(f,g)的風(fēng)格就可以生成另外一個函數(shù)，使得這個函數(shù)執(zhí)行f(g(x))的操作，則可稱compose為高階函數(shù)（Higher-order Function）。
program_options里的這種方式是怎么實(shí)現(xiàn)的呢？通過分析boost的源代碼，我們自己來寫個類似的實(shí)現(xiàn)看看： test.h
1 #pragma once
2
3 #include <iostream>
4 using namespace std;
5
6 class Test;
7
8 class Test_easy_init
9 {
10 public:
11 Test_easy_init(Test* owner):m_owner(owner){}
12
13 Test_easy_init & operator () (const char* name);
14 Test_easy_init & operator () (const char* name,int id);
15 private:
16 Test* m_owner;
17 };
18
19
20 class Test
21 {
22 public:
23 void add(const char* name);
24 void add(const char* name,int id);
25
26 Test_easy_init add_some();
27
28 };
test.cpp
1 #include "test.h"
2
3 Test_easy_init & Test_easy_init::operator () (const char* name,int id)
4 {
5
6 m_owner->add(name,id);
7 return *this;
8 }
9
10
11 Test_easy_init & Test_easy_init::operator () (const char* name)
12 {
13
14 m_owner->add(name);
15 return *this;
16 }
17
18 Test_easy_init Test::add_some()
19 {
20 return Test_easy_init(this);
21 }
22
23
24 void Test::add(const char* name)
25 {
26 cout<<"add:"<<name<<endl;
27 }
28
29 void Test::add(const char* name,int id)
30 {
31 cout<<"add:"<<name<<"-"<<id<<endl;
32 }
使用方式：
1 Test t1;
2
3 t1.add_some()
4 ("hello",1)
5 ("no id")
6 ("hello2",2);
是不是很有意思。add_some()方法返回一個Test_easy_init類的對象，Test_easy_init類重載了操作符()，操作符()方法返回Test_easy_init類對象自身的引用。。
|