其他

不是使用每串連一線程的技術，而是使用多工技術。作了一個分配演算法。第一個HTTP

由於在實際工作中使用到了mina，所以一直關注其mail-list。最近mina的mail-list討論的一個問題，就是提供的manual close connector，這個問題可害慘我了。原來的Connector，無論是SocketConnector或者VmPipeConnector，都是沒有提供close方法的，而且不會自動釋放。原來做得一個網路程式用戶端，每次重新建立的時候，都會new

jxta.org上也有一個資源共用的項目，jxta-cm，但是這個項目作的不夠好。我重新設計了傳輸協議，參考了BT的傳輸協議。儲存本地資訊，不像jxta-cm那樣簡單，序列化一個本地磁碟檔案，而是引入了Derby資料庫。我本想用Berkeley DB的，我很喜歡Berkeley DB，但是由於著作權協議的問題，不得不放棄了。當然與jxta-cm還有其他很多地方不同，包括一邊下載一邊上傳等等。今天檔案傳輸測試成功了，隨後將會進行更多的測試，保證穩定。希望4月1日能夠出一個愚人節版本。

今天早上上班前，發表了一篇文章“不要奢望.NET能夠跨平台”，主要觀點是：1、.NET是Windows API的進階版，跨平台是一個笑話。2、.NET很多類庫在設計上存在問題。此文引發眾多評論，回複者以小白居多。其中有一無聊好事者

一般來說，Exchanger都是一個Consumer，一個producer，在適當的時候互相交換，這樣可以避免鎖。我想到Exchanger N parties的一種用法。如下：最初N個都是producer，達到一定條件之後，進行交換。根據交換的結果重新確定角色，決定自己是consumer還是producer。這樣做的結果是，最初所有都是producer，之後一部分轉變成consumer。並且由於consumer以及producer的速度不一樣，而能夠自動適應調整。要注意的是，JDK

一直都是用心用感覺去品茶，沒想過去專門學習什麼理論，偶爾會和朋友交流，但更多的時候在作不同的嘗試尋找更好的感覺。如同岡倉天心所說的，我只是把他當作一種可口的飲料罷了。朋友也是一個好茶之人，推薦了岡倉天心的《說茶》，此書插圖精美，記錄了一些中國、西方、日本的關於茶的故事，在這本書中，我充分感受到了日本人的神秘主義情節，把茶和宗教、藝術以及生活哲學連在一起，《說茶》十分推崇儀式，日本的茶室簡直把喝茶的儀式發展到一個極致的地步，全書以茶道大師利休臨終在茶室舉行喝茶儀式後刨腹自殺的過程終結。很有意思的一

（本文作者溫少，首發於部落格園，轉載請註明）ID產生演算法，其中一種就是使用GUID（又稱UUID），使用128位儲存。UUID的一個問題是太長，可讀性太差，人腦無法記憶。替代方案之一，就是使用關聯式資料庫的自增長欄位，自增長欄位的一個問題是，無法預先建立一個ID，只能夠在儲存的時候才能產生ID，這對於批量關聯插入資料來說，不滿足需求。替代方案之二，就是使用一個記錄ID的表，每次加一，在事務中使用Select FOR UPDATE來讀取然後UPDATE SET FVALUE = FVALUE +

一旦方案想清楚，剩餘部分的工作效率瓶頸就在於你的手速了。最近一直看起點中文網上的《師士傳說》，主角葉重一個強項就是手速。最基本的就是盲打。不會盲打的通常屬於“編碼低能兒”。身邊也有不會盲打的朋友，他們通常都有一個問題，就是眼高手低，說說還行，動手就不行。當然他們能夠在IT研發領域還混得很好，是因為在其他方面擁有優秀的能力。熟練掌握快速鍵是關鍵。鍵盤和滑鼠之間通常有較大的距離，手經常在鍵盤和滑鼠之間移動，會降低效率，也容易導致疲勞，用滑鼠過多，也容易導致齷齪的滑鼠手。解決這個問題的辦法，就是純鍵盤

Herb Sutter的觀點Herb Sutter最近的一篇文章中如是說：“90年代，我們到處跟人叫講，什麼是對象，什麼是虛函數，現在我們到處跟人說，什麼是主動對象，什麼是Future”，他還說，結構編程、物件導向，現在該輪到並發和並行了。記得在去年，Herb Sutter就寫文章預示並發時代的到來，主要是因為CPU的主頻將不再會有以前那樣的增長速度，而將迎來多核時代。程式將是靠並發來提高運行效率。JDK 1.5

這是一個很老的問題了，經常在論壇上看到，很多人也寫了相關的文章。我在這方面擁有較多的經驗，我也談一下我的看法吧。我曾經實現過金蝶EAS BOS的多資料支援引擎，指令碼引擎，也作過O-R Mapping的預研工作，曾經對多個O-R

最近編碼更流暢了。原因包括：1) 絕大多數時候純鍵盤操作，Eclipse 200多個快速鍵，我熟練使用絕大部分，編碼的過程，如同行雲流水般。2）掌握了更多的解決問題的辦法，有了更廣的知識面，編碼時，信手拈來。最近一年裡，掌握了很多知識，包括並發、網路、作業系統等等方面的知識。3）組織代碼的能力更強了，最近對於大型複雜的程式，組織代碼的能力更強了，組織程式的能力包括，更好的結構，更好的擴充性，可測試性，可管理性等等。  a) 在編碼的過程中，使得更多的模組可以單獨於整個環境獨立測試  b)

在beep4j上作了一些修改，並且在此之上實現了一個基於BEEP協議的伺服器架構。BEEP協議提供了Session、Channel、Greeting、Profile、Frame等概念，這些基礎概念之上，很容易進行更進階的應用程式層協議設計。BEEP協議的特徵和能力長串連對等通訊請求\應答式互動在一個Session中建立多個獨立的傳輸通道（Channel）在一個通道中進行多個非同步請求（滑動視窗）可以使用不同的訊息編碼方式，包括二進位、文本、XML等，類似SMTP的MIME，使得可以在高效的二進位

昨天就開始看這個PPT，看了幾遍，對並發的前景有了更多的理解。http://irbseminars.intel-research.net/HerbSutter.pdf可以從他的網站上下載視頻版本。過去30年，主流軟體開發一直忽略了並發。但是現在，並發時代要來了，因為我們的新電腦是並發的，軟體開發將會迎來巨變。現在買的電腦，是雙核的，明年就會是4核，然後就是8核，16核，32核……，都是之後幾年的事情，一切都不遙遠！很多伺服器程式準備好了（也不完全是吧），而用戶端程式還沒有。演算法的時間複雜度改變

（本文作者溫少，首發於部落格園，轉載請註明）非阻塞演算法的關鍵思想就是CAS，CAS是compare and

Unix體驗中心：http://www.unix-center.net/可以免費註冊使用者。裡面有包括龍芯CPU的幾台linux，還有freebsd、solaris等作業系統，都安裝了JDK 5.0。我今天早上6:00上去註冊了一個使用者，然後跑到安裝了Debian linux的龍芯機器上寫了個java hello程式，龍芯機器的速度有點慢，不過還算好吧，勉強能用。似乎使用儲存伺服器，在一台伺服器上建立的檔案，在另外一台伺服器上也能夠看到，比較有意思。

貼圖的實現方式為：1、把剪下板中的圖片存在本地的SendingImages目錄，存放的格式使用PNG，當然可以其他格式，但是PNG格式更小。2、使用MD5演算法產生一個ImageID。當然可以使用SHA1等其他演算法3、把imageID發送remote peer4、當remote

編寫Jxta程式，通常需要設計自己的Advertisement。以下是我的一些心得：1、關於getID()。getID()可以返回null或者ID.nullID。jxta-cm中的ContentAdvertisement，就是返回null。如果是需要更新的Advertisement，則需要提供ID，否則其他Peer或者Rendezvous

1、使用多工或者非同步I/O模型，這本是伺服器段常用的技術，但在P2P應用，每台機器既是伺服器，又是用戶端，共用了一個十分受歡迎的檔案，可能會有很多希望串連者，或者你下載一個受歡迎檔案時，可能搜尋到數百上千的Peer，此時就很有必要採用多工或者非同步I/O技術，降低應用程式所佔用的資源。2、支援傳統的協議，包括HTTP和FTP，其實這兩種技術能夠和P2P網路整合，其中一種辦法就是，在提供的同時提供一個種子檔案下載，例如伺服器中提供了ABC.rar檔案，同時提供一個ABC.rar.md5檔案允許下

china-pub購書網址：http://www.china-pub.com/computers/common/info.asp?id=340171、總體感受a) 這本書主要介紹的是intel平台下的多核程式設計技術，Windows介紹較多，Linux介紹較少，Java更少。作者是Intel公司的平台架構師，我們知道wintel聯盟，書中的內容如此分布也是正常。b) 此書讓我懂得了很多硬體方面的並行知識。c) 此書介紹Windows API中和並發相關的部分，很詳盡，比Jeffrey

MessageDigest的選擇好多，包括MD2、MD4、MD5、SHA-1、SHA-256、RIPEMD128、RIPEMD160等等。我們如何選擇呢？選擇考慮在兩個方面：安全、速度。MD2很安全，但是速度極慢，一般不用。速度方面，最快的是MD4，MD5比SHA-1快速度排名：MD4 > MD5 > RIPEMD-128 > SHA-1 > REPEMD-160按照《應用密碼學手冊》提供的表格式資料為：MD4 長度 128 相對速度 1MD5 長度 128 相對速度 0