韌館-LearnHouse

[PHP]linux下使用jpgraph顯示中文字型

這個問題讓我花了快一個禮拜的時間,本來一度想放棄使用jpgraph改用圖片的放式來顯示圖表

但今天早上一醒來,覺得想想,我花了那麼多時間蒐集資料與測試

竟然在這一刻要我從找另一個方法,真的很不甘心

因此我又從新試了一次,把可能會導致無法顯示中文或是中文亂碼的可能原因,重新的排列組合

一個一個去修改核心程式碼,最後終於讓我歸類出幾個需要改的項目

由於改很多,有些已經忘記是我改的還是原本的了,所以以下方法是我覺得可能影響的幾個要改的項目 

1.修改src/jpgraph.php

require_once('jpg-config.inc.php');
require_once('jpgraph_gradient.php');
require_once('jpgraph_errhandler.inc.php');
require_once('jpgraph_ttf.inc.php');

// Version info
DEFINE('JPG_VERSION','2.3');

// Minimum required PHP version
DEFINE('MIN_PHPVERSION','5.1.0');

// Should the image be a truecolor image?
DEFINE('USE_TRUECOLOR',true);

//------------------------------------------------------------------------
// Automatic settings of path for cache and font directory
// if they have not been previously specified
//------------------------------------------------------------------------
if(USE_CACHE) {
    if (!defined('CACHE_DIR')) {
    if ( strstr( PHP_OS, 'WIN') ) {
        if( empty($_SERVER['TEMP']) ) {
        $t = new ErrMsgText();
        $msg = $t->Get(11,$file,$lineno);
        die($msg);
        }
        else {
        DEFINE('CACHE_DIR', $_SERVER['TEMP'] . '/');
        }
    } else {
        DEFINE('CACHE_DIR','/tmp/jpgraph_cache/');
    }
    }
}
elseif( !defined('CACHE_DIR') ) {
    DEFINE('CACHE_DIR', '');
}

if (!defined('TTF_DIR')) {
    if (strstr( PHP_OS, 'WIN') ) {
    $sroot = getenv('SystemRoot');
        if( empty($sroot) ) {
        $t = new ErrMsgText();
        $msg = $t->Get(12,$file,$lineno);
        die($msg);
        }
    else {
      DEFINE('TTF_DIR', $sroot.'/fonts/');
        }
    } else {
//    DEFINE('TTF_DIR','/usr/X11R6/lib/X11/fonts/truetype/');//修改成下面的路徑
    DEFINE('TTF_DIR','/usr/share/fonts/zh_TW/TrueType/');
    }
}

Tips: 要注意/usr/share/fonts/zh_TW/TrueType/下是否有.ttf或.ttc的字型,若沒有可從Windows系統的fonts去複製

 

2.修改src/jpg-config.inc.php

DEFINE('CHINESE_TTF_FONT','bkai00mp.ttf');

修改成DEFINE('CHINESE_TTF_FONT','mingliu.ttc');

Tips: 紅色的部份可依自己的喜好的字型修改,而字型的檔案要在上述的路徑裡面,這裡以新細明體mingliu.ttc為例

 

3.修改src/jpgraph_ttf.inc.php

        FF_CHINESE     =>   array(FS_NORMAL    =>CHINESE_TTF_FONT,
                  FS_BOLD    =>'',
                  FS_ITALIC    =>'',
                  FS_BOLDITALIC    =>'' ),
修改成

         FF_CHINESE     =>   array(FS_NORMAL    =>'mingliu.ttc',
                  FS_BOLD    =>'mingliu.ttc',
                  FS_ITALIC    =>'mingliu.ttc',
                  FS_BOLDITALIC    =>'mingliu.ttc' ),

 

4.再來就是呈現繪圖資訊的檔案了,可從Example的資料夾選擇想要的範例修改

$graph->title->Set("這裡這樣設定就可以直接顯示中文");
$graph->title->SetFont(FF_BIG5, FS_NORMAL);

Tips1:不過若是從資料庫取得utf-8的字串,要先轉成big5的編碼格式

下面範例是從資料庫取得utf-8字串後丟入陣列,陣列再轉成big5編碼,我去掉一些在資料庫上做擷取資料判斷的簡略程式片斷

for($i = 0 ; $i <= 10 ; $i++)
{
    $name[$i] = iconv("utf-8","big5",$name[$i]);
}

Tips2:轉換的動作不能寫在呈現繪圖資訊的php檔案中,不然會導致圖表無法顯示

 

最後再來說一個我遇到的問題,就是如何把SetLegends($name3)也能顯示中文

其中$name是從資料庫取得的utf-8轉big5的中文陣列

而要能在SetLegends顯示,就要加入$graph->legend->SetFont(FF_BIG5, FS_NORMAL);

這麼一來就能顯示中文了 

 

 

2008年2 月 posted by admin in 程式&軟體 and have Comment (1)

服務導向架構(Service-Oriented Architecture,SOA) 簡介

資料來源:http://www.cc.ntu.edu.tw

作者: 曾保彰 / 臺灣大學計算機及資訊網路中心資訊網路組


「以客為尊」的核心概念,提供網路服務單位建構一個具彈性、可重複使用的整合性介面,加速達到網路服務提升的目標。

前言
SOA是一種架構模型,由網站服務技術等標準化元件組成,目的是為企業、學校或提供網路服務單位建構一個具彈性、可重複使用的整合性介面,促進內外部如內部應用程式、用戶、與部門(系所)等相關單位完美的溝通,盡速達到網路服務提升的目標。何謂SOA?
我們常聴到 Information Technology (IT)產業的架構演進,由1980年代的主機(mainframe)架構,到1990年代的主從式(client server)架構,到1999年時是network centric架構,而到2004年時已複雜到所謂的 Service-Oriented Architecture架構(SOA,服務導向架構) 。此外也常聴到:如果企業不導入這個架構,企業在未來就會沒有競爭力。因此,本文將針對SOA作淺顯的簡介,也希望透過本文的介紹,對於本校網站服務技術(web services) 未來的架構有所幫助。
首先讓我們釐清一些SOA的迷思。正確來說 [1]:

  1. SOA不是新玩意:多年前即有資訊部門或公司成功地用SOA方式來建構、運行應用程式,且當時XML、web service都尚未提出。

  2. SOA不是種技術:它是種建構、組織的方法,用來建立應用程式的運行環境,以及讓學校的業務程式能以「功能化」方式發展、累積。

  3. 就算購買最新的XML、web services產品(如開發工具、執行平台、軟體元件等),也不表示就可以建構出SOA式的應用程式。

簡單來說,SOA是一種遵循典範,是針對學校或企業內應用程式的設計、開發、佈建、管理所提出的遵循典範。從資訊技術層面而言,一個執行學校或企業業務的 應用程式稱為一個獨立的「邏輯單位」,而對學校或企業營運層面而言則可稱為一項「服務」,在企業的整體運算環境中就存在著多個「獨立邏輯/業務服務」,且 需要對其進行妥善設計、開發、佈建、管理等,也因此需要採行服務導向架構(SOA)。

要 實現SOA,需要學校或企業的程式設計師改採「持續累積服務」的觀念與角度來開發應用程式,即便這麼做在短時間內看不到顯著好處,程式師還是必須跳脫、超 越過往對應用程式的想法,改以「既有服務可否再運用?」或者是「能否沿用其他同仁開發過的服務再建構?」的觀點來面對程式開發。

SOA 主張「程式開發技術」與「程式建構方法」的交替並用,以類似傳訊溝通的作法,將數個所需的「業務服務」進行連結,以此來實現一個新的應用程式,而非「從頭 開發」。透過適當的程式組構及傳訊式的程式連結,可讓學校或企業快速因應學生或用戶的需求與改變,新的應用程式只要透過「傳訊微調」即可實現,而非「重新 撰寫」。

SOA 不單只是程式開發的方法論,也提供行政管理層面的依循。例如它並非是以應用程式個體為角度來進行管理,而是直接將過往程式師開發出的程式視為「服務」來管 理。而對「服務」間的「互動傳訊」進行分析,SOA便可讓程式設計部門的主管瞭解何時該執行哪個業務邏輯,以及為何要執行,如此資訊管理者與分析師便可對 服務程序進行最佳化調適。

SOA如何運作?
SOA服務導向架構是一種新興的系統架構模型,主要概念是針對學校或企業需求組合而成的一組軟體元件。組合的元素通常包括:軟體元件、服務及流程三個部 份。當學校或企業面對外部要求時,流程負責定義外部要求的處理步驟;服務包括特定步驟的所有程式元件,而軟體元件則負責執行工作的程式。SOA 已成為現今軟體發展的重要技術,透過 SOA 讓異質系統整合變得容易,程式再使用度也提高。不必自行開發或擁有所有程式元件,發展者可以視其需要組合網路上最好的服務。不受限於特定廠商的產品功能或 是平台,達到真正的開放性(Openness)。從分散式元件架構到 SOA概念上,SOA 如同物件導向、軟體元件等軟體技術一般,運用小的零組件組合成應用系統。但 SOA 強調的是如何將彼此關係鬆散的應用系統功能元件在網路上發行、組合及使用。SOA 具有下列技術特性[2]:

  1. 分散式架構 (distributed)-SOA 的組成元件是由許多分散在網路上的系統組合而來,可能是區域網路,也可能是來自廣域網路。例如網站服務技術 (web services) 就是運作 HTTP來相互連結的 SOA。如此的作法,也使得網站服務技術很快的就成為所有支援網際網路的系統平台均能使用的技術。

  2. 關 係鬆散的界面 (loosely coupled)-傳統的系統主要是將應用系統功能需求切割成相互關聯的小零組件:模組、物件或元件,發展者要花費極大的心力了解零組件是如何設計及使 用,以確保不會違反零組件連接關係限制。如此一來,若要以不同零組件替換原始設計,就成為一件困難的事。SOA 的作法是以界面標準來組合系統,只要符合界面要求,零組件可以任意替換,大幅提高系統變更的彈性度。

  3. 依據開放的標準 (Open standard)-使用開放標準是 SOA 的核心特色,過去的軟體元件平台如 CORBA、DCOM、RMI、J2EE 採用專屬協定作為元件連結的規範,使得不同平台的元件無法相通。SOA 則著重於標準與互動性,將可避免不同平台 (.NET web services 與 Java web services) 開發程式間相互整合的困擾。

  4. 以流程角度出發 (process centric)-在建構系統時,首先了解特定工作的流程要求,並將其切割成服務界面(包括輸入與輸出資料格式),如此其他的發展者就可以依據服務界面開發 (或選擇) 合適的元件來完成工作。

最 後舉一個學校常用的例子來說明SOA在實際應用上帶來的可能性。假設我們要建立一個線上投稿的網站,網站提供的服務包括了線上投稿作業、論文分派作業、論 文審查作業、線上註冊及報名作業等。傳統的方式我們會儘快找一個類似的網站,再儘快將其他類似網站的原始碼(source code)拿來修改,但其他類似網站的原始碼所執行的平台有可能不是架站者所熟悉的作業系統。若要讓架站者作一個客製化,並符合自己投稿主題的線上投稿的 網站,可能要熟悉這個平台並修改網頁及測試,再加上別人的網站可能有一些bug,如果要做到毫無問題,除錯時間可能要花上三個月的時間。但是,如果我們導 入SOA的架構的話,可能將來只要花費心力將作業服務模組化、物件化或元件化,然後將它們整合到網站中即可,不需要再花費時間和資源自己去維護一個線上投 稿的網站,也不需要再自行建立和資料庫連結、報名付款機制等。這個網站就像是建立在SOA上,整合了這些web services元件的一個應用程式系統。更重要的是,透過如http、XML、SOAP 等產業標準開放式協定,不必擔心這些服務使用甚麼平台、甚麼技術來建立,而將來如果有更好的服務或服務提供者時,也可以輕易的將服務更換或更新。對系統開 發者來講,可以快速輕鬆的將系統建構完成,將心思專注在規劃更好、更完善的系統上;對服務提供者而言,只要能設計出一個好的服務,它的潛在使用者市場將不 再受到使用者平台的限制而有無限的可能。單就這類應用所呈現的美好遠景,應該可以解釋為什麼會到處聽到有人在談論SOA了。

因此 SOA 的實作,就是將所有程式邏輯及服務內容全部包裹在服務內部,並實作一個標準的介面與外部作溝通,這種做法跟傳統的元件導向做法非常類似,唯一的差別是介面定義的方式、資料格式、與溝通管道必須是產業標準 (http、XML、SOAP 等)。 也就是說只要能實作出這樣的介面,不論介面後面是什麼,都可使成為 SOA。
 

結論
綜合以上的介紹,SOA能帶來的幫助,有以下好處:
1.增加企業盈收,或提升學校的服務品質。
2.提供可變動的網路服務型態。
3.降低學校或企業的成本。
4.降低開發服務的時間。
5.整合學校或企業的網路服務技術資源。
6.降低整體風險及意外。
 

參考文獻
[1] http://dev2dev.bea.com.tw/techdoc/07soa/07soa_040812_01.htm
[2] http://www.microsoft.com/taiwan/msdn/columns/soa/SOA_overview_2004112901.htm

2008年1 月 posted by admin in 程式&軟體 and have No Comments

[Java]撰寫時的良好的習慣

標準的命名規則

  1. Package (套件)
    英文單字全部小寫,例如zoo.cute, java.lang
  2. Class (類別)
    每一個英文單字的第一個字母大寫,例如Animal, NationalChungChengUniversity
  3. Interface (介面)
    每一個英文單字的第一個字母大寫,規則和類別一樣
  4. Attribute (屬性)
    第一個英文單字的第一個字母小寫,其它單字的第一個英文字母大寫,例如legs, numberOfLegs
  5. Method (方法)
    規則和屬性一樣,不過要在後面加上小括號,例如eat(), eatMeat()
  6. Constant (常數)
    英文單字全部大寫,且兩兩單字之間用底線隔開,例如COUNT, MAX_COUNT

待續..........

 

參考資料

吉米兔的學習園地

2008年1 月 posted by admin in 程式&軟體 and have Comments (4)

分散式雜湊表(Distributed Hash Table,DHT)應用 - Kademlia

分散式雜湊表(英語:Distributed Hash Table,簡稱DHT)是分散式計算系統中的一類,用來將一個關鍵值(key)的集合分散到所有在分散式系統中的節點,並且可以有效地將訊息轉送到唯一一個擁有查詢者提供的關鍵值的節點(Peers)。這裡的節點類似雜湊表中的儲存位置。分散式雜湊表通常是為了擁有極大節點數量的系統,而且在系統的節點常常會加入或離開(例如網路斷線)而設計的。在一個結構性的延展網路overlay network)中,參加的節點需要與系統中一小部份的節點溝通,這也需要使用分散式雜湊表。分散式雜湊表可以用以建立更複雜的服務,例如分散式檔案系統、點對點技術檔案分享系統、合作的網頁快取、多點傳輸、任意點傳輸anycast)、網域名稱系統以及即時通訊等。

 

發展背景

研究分散式雜湊表的主要動機是為了開發點對點系統,像是Napster、GnutellaFreenet。這些系統得益於使用分散在網際網路上的各項資源以提供實用的應用,特別在頻寬及硬碟儲存空間上,他們所提供的檔案分享功能因此得到最大的好處。

這些系統使用不同的方法來解決如何找到擁有某資料的節點的問題。Napster 使用中央的索引伺服器:每個節點加入網路的同時,會將他們所擁有的檔案列表傳送給伺服器,這使得伺服器可以進行搜尋並將結果回傳給進行查詢的節點。但中央 索引伺服器讓整個系統易受攻擊,且可能造成法律問題。於是,Gnutella 和相似的網路改用大量查詢模式(flooding query model):每次搜尋都會把查詢訊息廣播給網路上的所有節點。雖然這個方式能夠防止單點故障single point of failure),但比起 Napster 來說卻極沒效率。

最後,Freenet 使用了完全分散式的系統,但它建置了一套使用經驗法則的基於關鍵值的轉送方法key based routing)。在這個方法中,每個檔案與一個關鍵值相結合,而擁有相似關鍵值的檔案會傾向被相似的節點構成的集合所保管。於是查詢訊息就可以根據它所提供的關鍵值被轉送到該集合,而不需要經過所有的節點。然而,Freenet 並不保證存在網路上的資料在查詢時一定會被找到。

分散式雜湊表為了達到 Gnutella 與 Freenet 的分散性(decentralization)以及 Napster 的效率與正確結果,使用了較為結構化的基於關鍵值的轉送方法。不過分散式雜湊表也有個 Freenet 有的缺點,就是只能作精確搜尋,而不能只提供部份的關鍵字;但這個功能可以在分散式雜湊表的上層實做。

最初的四項分散式雜湊表技術——內容可定址網路Content addressable network,CAN)、ChordChord project)、PastryPastry (DHT)),以及 Tapestry (DHT)Tapestry (DHT))皆同時於2001年發表。從那時開始,相關的研究便一直十分活躍。在學術領域以外,分散式雜湊表技術已經被應用在BitTorrent及CoralCDNCoral Content Distribution Network)等。

結構

分散式雜湊表的結構可以分成幾個主要的元件。其基礎是一個抽象的關鍵值空間(keyspace),例如說所有160位元長的字元串集合。關鍵值空間分割(keyspace partitioning)將關鍵值空間分割成數個,並指定到在此系統的節點中。而延展網路則連接這些節點,並讓他們能夠藉由在關鍵值空間內的任一值找到擁有該值的節點。

當這些元件都準備好後,一般使用分散式雜湊表來儲存與讀取的方式如下所述。假設關鍵值空間是一個160位元長的字元串集合。為了在分散式雜湊表中儲存一個檔案,名稱為 filename 且內容為 data,我們計算出 filename 的 SHA1 雜湊值——一個160位元的關鍵值 k——並將訊息 put(k,data) 送給分散式雜湊表中的任意參與節點。此訊息在延展網路中被轉送,直到抵達在關鍵值空間分割中被指定負責儲存關鍵值 k 的節點。而 (k,data) 即儲存在該節點。其他的節點只需要重新計算 filename 的雜湊值 k,然後送出訊息 get(k) 給分散式雜湊表中的任意參與節點,以此來找與 k 相關的資料。此訊息也會在延展網路中被轉送到負責儲存 k 的節點。而此節點則會負責傳回儲存的資料 data

以下分別描述關鍵值空間分割及延展網路的基本概念。這些概念在大多數的分散式雜湊表實作中是相同的,但設計的細節部份則大多不同。

關鍵值空間分割

大多數的分散式雜湊表使用某些穩定雜湊consistent hashing)方法來將關鍵值對應到節點。此方法使用了一個函數 δ(k1,k2) 來定義一個抽象的概念:從關鍵值k1k2 的距離。每個節點被指定了一個關鍵值,稱為ID。ID 為 i 的節點擁有根據函數 δ 計算,最接近 i 的所有關鍵值。

例:Chord 分散式雜湊表實作將關鍵值視為一個圓上的點,而 δ(k1,k2) 則是沿著圓順時鐘地從 k1 走到 k2 的距離。結果,圓形的關鍵值空間就被切成連續的圓弧段,而每段的端點都是節點的ID。如果 i1i2 是鄰近的 ID,則 ID 為 i2 的節點擁有落在 i1i2 之間的所有關鍵值。

穩定雜湊擁有一個基本的性質:增加或移除節點只改變鄰近ID的節點所擁有的關鍵值集合,而其他節點的則不會被改變。對比於傳統的雜湊表,若增加或移 除一個位置,則整個關鍵值空間就必須重新對應。由於擁有資料的改變通常會導致資料從分散式雜湊表中的一個節點被搬到另一個節點,而這是非常浪費頻寬的,因 此若要有效率地支援大量密集的節點增加或離開的動作,這種重新配置的行為必須盡量減少。

延展網路

每個節點保有一些到其他節點(它的鄰居)的連結。將這些連結總合起來就形成延展網路。而這些連結是使用一個結構性的方式來挑選的,稱為網路拓樸。

所有的分散式雜湊表實作拓樸有某些基本的性質:對於任一關鍵值 k,某個節點要不就擁有 k,要不就擁有一個連結能連結到距離較接近 k 的節點。因此使用以下的貪心演算法即可容易地將訊息轉送到擁有關鍵值 k 的節點:在每次執行時,將訊息轉送到 ID 較接近 k 的鄰近節點。若沒有這樣的節點,那我們一定抵達了最接近 k 的節點,也就是擁有 k 的節點。這樣的轉送方法有時被稱為「基於關鍵值的轉送方法」。

除了基本的轉送正確性之外,拓樸中另有兩個關鍵的限制:其一為保證任何的轉送路徑長度必須盡量短,因而請求能快速地被完成;其二為任一節點的鄰近節點數目(又稱最大節點度(Degree (graph theory)))必須盡量少,因此維護的花費不會過多。當然,轉送長度越短,則最大節點度越大。以下列出常見的最大節點度及轉送長度(n 為分散式雜湊表中的節點數)

  • 最大節點度 O(1),轉送長度 O(logn)
  • 最大節點度 O(logn),轉送長度 O(logn / loglogn)
  • 最大節點度 O(logn),轉送長度 O(logn)
  • 最大節點度 O(n1 / 2),轉送長度 O(1)

第三個選擇最為常見。雖然他在最大節點度與轉送長度的取捨中並不是最佳的選擇,但這樣的拓樸允許較為有彈性地選擇鄰近節點。許多分散式雜湊表實作利用這種彈性來選擇延遲較低的鄰近節點。

最大的轉送長度與直徑有關:最遠的兩節點之間的最短距離。無疑地,網路的最大轉送長度至少要與它的直徑一樣長,因而拓樸也被最大節點度與直徑的取捨限制住,而這在圖論中是基本的性質。因為貪婪演算法(Greed Method)可能找不到最短路徑,因此轉送長度可能比直徑長。

 

範例

分散式雜湊表實作與協定

  • Bamboo
  • Bunshin
  • 內容可定址網路 (Content Addressable Network)
  • Chord
  • DKS系統
  • Kademlia
  • Leopard
  • MACE
  • Pastry
  • P-Grid
  • Tapestry

Kademlia 網路的詳細解釋

基本上,Kademlia不是一個網路,是一個很熱門的技術,通稱為DHT (Distributed Hash Table 分散式雜湊表)Kademlia 是個 Petar Maymounkov David Mazières 所設計的點對點 (P2P) 重疊網路, 以達成非集中式的點對點 (P2P) 電腦網路。它規制了網路的結構及規範了節點間的通訊和交換資訊的方式。Kademlia 節點間使用傳輸通訊協定UDP溝通。Kademlia 節點藉以實作分散式雜湊表 (DHT,distributed hash table) 以儲存資料。透過既有的區域網/廣域網( LAN/WAN) (如同網際網路),一個新的虛擬網路或是重疊網路被建立起來。每個網路節點都是以一組數字(「節點 ID」)來識別。這組數字不但做為識別之用,Kademlia 演算法還會用來做其他用途。

一個想要加入網路的節點需要先通過啟動。在這個階段,這個節點需要知道另一個已經在 Kademlia 網路內的節點之 IP 位址 (透過另一個使用者或儲存的清單取得)。如果啟動中的節點還不是網路的一部分,它便會計算一個尚未指定給其他節點的隨機 ID 編號。這個 ID 會一直使用到離開網路為止。

Kademlia 演算法是基於兩節點間的「距離」來計算。這個距離是以兩節點的 ID 進行異或運算,並將結果四捨五入至整數。這個「距離」跟實際的地理環境無關,而是標明 ID 範圍內的距離。因此一個德國的節點和一個澳洲的節點就有可能被稱為「鄰居」或「芳鄰」。

Kademlia 內的資訊都儲存在稱為「數值」的東西內,每個數值都連接著一個「金鑰」。當搜尋某個金鑰時,演算法會透過幾個步驟探整個網路一圈,每個步驟都會更接近要搜尋的金鑰,直到被連線的節點傳回數值,或找不到更近的節點。網路的 大小僅會稍微影響到進行搜尋時接觸到的節點數目:假如目前網路的使用者突然增為兩倍,那使用者節點大概只需要在搜尋時多查詢一個節點,而不是兩倍的節點 量。

非集中式的結構提供了更大的優勢,並很明顯地增加了對拒絕服務阻斷攻擊的抵抗。即使一整系列的節點被壅塞,也不會對網路可用度造成太多影響,最後網路會透過繞過這些「洞」而自我修復。

在檔案分享網路中的應用

Kademlia 被用來進行檔案分享。透過進行 Kademlia 關鍵字搜尋,任何人可以在檔案分享網路中尋找資料以下載東西。由於沒有任何中央伺服器儲存檔案列表的索引,因此這項工作是平均的由所有的客戶端擔當:擁有要分享的檔案枝節點,會先處理檔案的內容,並從內容計算出一組數字(雜湊), 這組數字將會在檔案分享網路中辨識這個檔案。雜湊與節點 ID 的長度必須相同。接著會搜尋幾個 ID 與雜湊相近、且節點內有儲存著自己 IP 位址的節點。搜尋的客戶端會使用 Kademlia 來搜尋網路上節點ID離自己最近距離的節點來取得檔案雜湊,然後會取得在該節點上的聯絡清單。 當節點聯入和聯出時,這份存儲在網路上的聯絡清單也將保持不變。因為內嵌的冗余存儲演算法,聯繫清單將複製在多個點上。

檔案雜湊通常都是由其它地方的特製網際網路鍵結來取得,或者被包含在來自其它來源中的索引檔中。

對檔案名稱的搜索是基於關鍵字來實現的。檔案名稱被分成幾個組成檔案名稱的單字。 每個關鍵字都會被雜湊, 並和相對的檔案名稱與檔案雜湊利用和檔案雜湊一樣的方式儲存到網路上。一個搜索者會選擇其中的一個關鍵字,聯繫上和關鍵字雜湊最相近的節點ID,然後取得 含有關鍵字的檔案名稱列。既然在檔案名稱列中的每個檔案名稱都附有自己的湊雜,那麼被選的檔案就可以由一般的方式取得。

kad 網絡是一種根本不需要服務器的架構,每個emule客戶端負責處理一小部分searchsource finding的工作。分配工作的原理是基於客戶端的唯一idsearch或者sourcehash之間的匹配來決定。比如說 LordOfRing1.avi這個文件由用戶abc來負責(通過文件的hash決定),則任何用戶共享這個文件的時候都會告訴用戶abc我有這個文件, 其他用戶去下載這個文件的時候也會詢問abcabc告訴他們誰有這個文件,source finding就完成了。search的方法也差不多,每個人負責一個keyword

至於如何找到用戶abc則是通過一種將用戶 id異或的方式,兩個id的二進制異或值決定他們之間的邏輯距離,比如1100距離1101要比距離1001近。當一個喲用戶加入kad後,首先通過一個 已知的用戶找到一批用戶的idip:port。當此用戶A要尋找某特定用戶x時,A先詢問幾個已知的邏輯距離X較近的用戶,如x1,x2,x3x1, x2,x3會告訴A他們知道的更加近的用戶的id,ipport,一次類推,A最終就能找到X。尋找的次數應該在logN數量級,N是總人數。

資料來源

分散式雜湊表 - Wikipedia
Kademlia - Wikipedia 

KAD網絡的一些解釋

 

2008年1 月 posted by admin in 文獻參考 and have Comments (2)

Street Fighter IV 懷舊的街頭快打3D版 on XBOX360

2008年1 月 posted by admin in 影視娛樂 and have No Comments

迎接2008曙光跨年晚會一覽

明晚跨年 大城小鎮都有得High

更新日期:2007/12/30 16:40 地方中心/連線報導

「跨年晚會」已成各地縣市政府必辦活動,有的還與觀賞2008第一道曙光活動串連,歌手們也是北中南趕場演出,明晚,全島鐵定熱鬧滾滾!

Read more...

2007年12 月 posted by admin in 影視娛樂 and have No Comments