隨筆檔案

     摘要: 基于Lua 5.1實現的遠程調試器，腳本運行在服務端，客戶端登錄后可以遠程管理腳本，可以調試腳本，單步跟進、變量查看。
界面基于wxWidgets實現，網絡通訊接口采用CORBA/TAO。  閱讀全文      摘要: 在C++中要進行并發處理，不可避免要使用多線程，在傳統的教科書中，大家都是采用最原始的多線程技術，應用邏輯和線程并發策略緊密綁定。
在一個典型的服務器程序中，客戶端的請求往往包含了很多不同的邏輯命令，如在一個線程處理函數中，需要根據客戶端的命令代碼處理不同的業務邏輯：

int thrad_main(int cmd_id,char *data){
switch(cmd_id)
{
case 1:
...
break;
case 2:
...
break;
}
}

如此這般，業務處理邏輯和線程邏輯緊密耦合，這是一種很“丑陋”的代碼。
如何通過一種優雅的方法，分離并發邏輯和業務邏輯，通過通用的并發框架，業務邏輯設計者只需要關心自己的邏輯代碼，交給“線程池”去處理即可，而不需要去關心如何創建線程，等待線程結果這些瑣碎的“小事”？  閱讀全文      摘要: 　　平臺服務和腳本服務接口對后端PostgreSQL數據庫的使用目前采用短暫連接方式，造成多次調用服務時頻繁連接和斷開數據庫，效率很低。

　　如果共享數據庫連接，則會造成多線程訪問數據庫時的事務沖突，故必須采用連接池來管理對數據庫的并發訪問，某一線程連接到數據庫使用完畢后，不斷開數據庫連接，而是把連接歸還給連接池。

　　另一線程訪問數據庫時會首先向連接池申請已經存在的連接，如果連接池中沒有空閑連接，或者申請到得連接已經超時失效，再建立新的連接，使用完畢后同樣歸還到連接池。

　　這樣連接池中的連接數會隨著線程壓力的增加逐漸增長，直到所有的線程同時工作，達到最多連接數。

　　由于一個線程可能同時申請多個連接，故連接數可能會大于線程數。連接池在程序結束時銷毀全部連接，或者線程在申請到的某一連接失效時銷毀該連接。
  閱讀全文

     摘要: 　　在C/S結構的C++網絡程序中，直接采用Socket API進行開發效率是很低的，所以大家發明了各種各樣的網絡框架，如Boost.Aiso和ACE，簡化了網絡通信開發的難度。
　　但是這種基于數據包收發的模式還是不太方便，于是又出現了RPC、DCOM、CORBA等遠程接口調用的標準。客戶端只需要像調用本地函數一樣調用遠程接口，框架會自動處理數據包收發，請求和應答等底層細節。
　　雖然現在Web技術的發展如火如荼，大有取代C/S架構應用之勢，但是，直接運行于操作系統平臺上的C++原生應用還是有它存在的意義，最主要的方面就是接近系統底層，對操作系統資源和底層設備的控制等，其他任何虛擬機上的中間語言是無法望其項背的。

　　CORBA是一個為簡化跨平臺應用而提出的規范，它獨立于網絡協議、編程語言和軟硬件平臺，支持異構的分布式計算環境和不同編程語言間的對象重用。
  閱讀全文

     摘要: 最近開發了一個基于ACE實現的C++ Service框架，每一個服務實現為一個插件，
客戶端通過遠程調用接口即可訪問服務對象提供的服務，客戶端接口的包裝如下所示：

。。。

一個網絡應用一般包括兩部分，位于服務端的“服務對象”和位于客戶端的“調用代理”，上面這個類屬于客戶端代理對象。
兩端之間遵從的協議就是請求“LoginRequest”和響應“LoginResult ”。
  閱讀全文 不知不覺，已經工作了2年了，雖然只是一個普普通通的C++程序員，但這兩年也經歷了許多喜怒哀樂愁。

IT圈的發展日新月異，新語言新技術層出不窮，當大家都熱衷于.NET、Java、Web，追趕著開發潮流，我卻依然在擺弄著C++，很明顯C++不適合做應用系統的開發，尤其是報表和用戶界面上，做的非常累人，很不想做下去了。

所以我一直在研究C++在服務器系統的開發，這方面應該是比較有潛力的，最近研究了一些boost，這些c++中的新鮮血液讓我感覺很震撼，雖然一些技術在別的新型語言中并不算什么，但是對于c++來說仍然是劃時代的進步。