【正文】 der, serverProvider)。 客戶端的端口號不能與服務(wù)器一致，否則將出現(xiàn)通常每個套接字地址(協(xié)議/網(wǎng)絡(luò)地址/端口)只允許使用一次的異常，將其設(shè)置為0，則客戶端自動選擇可用的端口。該URL和Web瀏覽器的URL具有一樣的含義，具有如下的格式：Protocol://server:port/URI這里的協(xié)議，也就是信道的格式，如tcp、ipc。 創(chuàng)建對象與獲取遠程對象代理創(chuàng)建對象，也就是在客戶端激活服務(wù)器上的對象，并獲得這個遠程對象的一個本地代理（透明代理）。//獲取代理try { obj = (NetRmtObject)(typeof(NetRmtObject), tcp:// + + :8080/url)。 if (obj == null || city_obj == null) { (連接失敗!!)。 } } catch (Exception ex) { ()。 事件調(diào)用 服務(wù)器注冊客戶端事件服務(wù)器注冊客戶端事件，相對客戶端注冊服務(wù)器事件來說，是比較簡單的。具體的實現(xiàn)思路是，在遠程對象中定義一個事件，然后在某方法內(nèi)部，調(diào)用該事件的處理函數(shù)，這樣，在客戶端調(diào)用該方法時，就觸發(fā)了事件。 客戶端注冊服務(wù)器事件客戶端注冊服務(wù)器上的事件，是個畢竟復(fù)雜的過程。在服務(wù)器注冊客戶端事件時，只要客戶端激活了遠程對象，就可以發(fā)送消息，而只要服務(wù)器訂閱了此事件，就可以處理客戶端的消息了。這同樣也說明了在服務(wù)器端注冊對象后顯式創(chuàng)建一個對象的思路也并不可行。這樣，為了實現(xiàn)客戶端注冊客戶端事件，必須讓遠程對象具有的特征也就很明顯了：客戶端得到的遠程對象實際上是服務(wù)器上對象的代理。服務(wù)器端觸發(fā)事件是遠程對象里的事件，遠程對象想要被客戶端訪問就必須被序列化，原因就在于事件是基于委托的。如下所示：//設(shè)置反序列化級別BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider()。 = 。//在服務(wù)器觸發(fā),在客戶端訂閱的事件 //服務(wù)器觸發(fā)事件 public void TriggerAtServerSwapEvent(string msg) { if (SwapSubscribeAtClient != null) SwapSubscribeAtClient(msg)。 } }}客戶端在注冊服務(wù)器事件的時候，//訂閱服務(wù)器事件SwapObject swap = new SwapObject()。 += new MyDelegate(obj_SubscribeAtClient)。對需要創(chuàng)建的對象、事件，遠程對象類進行了說明，同時還給出了服務(wù)器端、客戶端信道從創(chuàng)建到注銷的流程介紹，并使用部分示例代碼來進行說明。規(guī)則雖然簡單，但在地點數(shù)目增多后求解卻極為復(fù)雜。多年來全球數(shù)學(xué)家絞盡腦汁，試圖找到一個高效的算法TSP問題在物流中的描述是對應(yīng)一個物流配送公司，欲將n個客戶的訂貨沿最短路線全部送到。TSP問題最簡單的求解方法是枚舉法?？梢孕蜗蟮匕呀饪臻g看成是一個無窮大的丘陵地帶，各山峰或山谷的高度即是問題的極值。．旅行商問題研究歷史旅行商問題字面上的理解是：有一個推銷員，要到n個城市推銷商品，他要找出一個包含所有n個城市的具有最短路程的環(huán)路。TSP由美國RAND公司于1948年引入，該公司的聲譽以及線性規(guī)劃這一新方法的出現(xiàn)使得TSP成為一個知名且流行的問題。排列問題比子集合的選擇問題通常要難于求解得多，這是因為n個物體有n!種排列，只有n個子集合(n!O( ))。本系統(tǒng)采用FIFO分支限界法。在總的原則下，根據(jù)對狀態(tài)空間樹中結(jié)點檢索的次序的不同又將分支限界設(shè)計策路分為數(shù)種不同的檢索方法?？梢钥闯?，分支限界法在兩個方面加速了算法的搜索速度，一是選擇要擴展的節(jié)點時，總是選擇選擇一個最小成本的結(jié)點，盡可能早的進入最有可能成為最優(yōu)解的分支；二是擴展節(jié)點的過程中，舍棄導(dǎo)致不可行解或?qū)е路亲顑?yōu)解的子結(jié)點。在分支限界法中，每一個活結(jié)點只有一次機會成為擴展結(jié)點。在這些兒子結(jié)點中，導(dǎo)致不可行解或?qū)е路亲顑?yōu)解的兒子結(jié)點被舍棄，其余兒子結(jié)點被加入活結(jié)點表中。這個過程一直持續(xù)到找到所需的解或活結(jié)點表為空時為止。（2）優(yōu)先隊列式分支限界法按照優(yōu)先隊列中規(guī)定的優(yōu)先級選取優(yōu)先級最高的節(jié)點成為當前擴展節(jié)點。在使用分支限界搜索問題的解空間樹時，先根據(jù)限界函數(shù)估算目標函數(shù)的界[down, up]，然后從根結(jié)點出發(fā)，擴展根結(jié)點的r1個孩子結(jié)點，從而構(gòu)成分量x1的r1種可能的取值方式。再取PT表中目標函數(shù)極大值結(jié)點作為擴展的根結(jié)點，重復(fù)上述。public TreeNode TraProSolving() {TreeNode minNode = new TreeNode()。int isFirstAnswer = 1。my_dt = (DataTable)。 minNode = null。//城市總數(shù) TreeNode rootStart = new TreeNode()。//節(jié)點編號 = 0。//結(jié)尾節(jié)點 rootEnd = rootStart。//隊列 (rootStart)。//當前節(jié)點的孩子節(jié)點數(shù)目 while ( != 0) { //取出隊列里的第一個節(jié)點作為新的活節(jié)點（根節(jié)點） TreeNode root = new TreeNode()。//從隊列中取出第一個元素作為新的根節(jié)點，出隊列 childAmount = cityCount 1 。//定義孩子節(jié)點 //初始化節(jié)點的孩子節(jié)點 int i = 0。//存在結(jié)果變量，1表示已存在，0表示還不存在 for (int j = 0 。j++) { TreeNode rootParent = new TreeNode()。 while (rootParent != null) {//父節(jié)點中是否存在 if ( == [j][0].ToString()) { result = 1。 } rootParent = 。//存在 break。 for (x = 0 。x++) { if ( == [x][0].ToString()) { break。//父親節(jié)點城市 = (int)[x][0]。 = (int)[x][2]。//目標城市 = (int)[j][0]。 = (int)[j][2]。 node[i].Name = ()。 (node[i])。 } result = 0。m 。 break。 } } } else {//結(jié)尾節(jié)點 int x。x cityCount 。 } } TreeNode node = new TreeNode()。//設(shè)置結(jié)尾節(jié)點 = (() + (cityA)).ToString()。 if (isFirstAnswer == 1) { minDistance = ()。 isFirstAnswer = 0。 minNode = node。} 程序的運行和正確性 程序的運行開啟客戶端，輸入服務(wù)器的IP地址，這里輸入的是localhost，也就是本地。同時，服務(wù)器會給客戶端一個編號，方便以后消息的發(fā)送和計算等。服務(wù)器界面如圖52所示：圖52 服務(wù)器端上有成功連接的客戶端可以開啟任意數(shù)量的客戶端，服務(wù)器都會一一記錄下這些客戶端信息。點擊生成數(shù)據(jù)按鈕，會隨機生成一組數(shù)據(jù)，點擊發(fā)送數(shù)據(jù)，就可以像服務(wù)器端發(fā)送數(shù)據(jù)，服務(wù)器收到數(shù)據(jù)之后，會將數(shù)據(jù)廣播發(fā)送給各個客戶端，包括發(fā)起并行計算請求的客戶端。客戶端和服務(wù)器之間具體的信號傳遞如圖56所示：圖56 客戶端和服務(wù)器之間信號傳遞過程每發(fā)送一個子節(jié)點數(shù)據(jù)之后，收到數(shù)據(jù)的客戶端會向服務(wù)器回應(yīng)一個“已收到數(shù)據(jù)”的信號，服務(wù)器在收到此信號之后才開始發(fā)送第二個子節(jié)點數(shù)據(jù)。為了防止這種情況的出現(xiàn)，需要確保數(shù)據(jù)成功發(fā)送之后再開始第二個數(shù)據(jù)的發(fā)送。服務(wù)器發(fā)送完所有的第一級子節(jié)點數(shù)據(jù)之后，就向各個客戶端廣播發(fā)送“開始計算”信號，客戶端收到信號后就開始利用分支限界法對服務(wù)器發(fā)送來的數(shù)據(jù)進行計算?？蛻舳耸盏阶罱K結(jié)果之后，停止計時，顯示服務(wù)器給出的最終結(jié)果和客戶端自身的計時結(jié)果。由于當城市過多時，手動計算十分困難，所以就不再做過多的計算。通過上面的測試，可以基本認為系統(tǒng)計算的結(jié)果是正確的，系統(tǒng)的正確性是可以相信的。因此，需要用不同的數(shù)據(jù)進行測試。結(jié)果分析：（1）由表中可以很顯然的看出，串行計算的耗時隨城市數(shù)量的增加而呈指數(shù)增長趨勢，這是因為單個節(jié)點下的計算任務(wù)也成倍的增長了，這是合理的現(xiàn)象。參與并行計算的客戶端數(shù)量相同（這里的測試使用4個客戶端），旅行商問題中城市數(shù)量不同時，運行計算的結(jié)果如下表52所示，其中，當城市數(shù)量到達11個的時候，計算耗時就非常久了，這里沒能記錄下4個客戶端，11個城市時的計算耗時。結(jié)果分析：（1）從表中可以很直觀的發(fā)現(xiàn)，并行計算耗時隨城市數(shù)量的增加而增加，切呈指數(shù)增長趨勢；（2）單個客戶端最多節(jié)點數(shù)目的多少對計算耗時影響不大，影響大的還是城市數(shù)量；（3）和表51對比可以發(fā)現(xiàn)，當城市數(shù)量小于等于6時，串行計算耗時小于并行計算耗時；當城市數(shù)量大于等于7時，串行計算耗時大于并行計算耗時。旅行商問題中的城市數(shù)量比較多（10個城市）且城市數(shù)量相同，參與并行計算的客戶端的數(shù)量不同時，進行多次測試，測試以及結(jié)果的記錄如下頁表53所示?？赡軙斐山Y(jié)果不準確的因素：由于計算機進行了長時間的復(fù)雜計算，CPU的使用率長時間保持很高的水平，加上天氣溫度略高，計算機進行測算時，溫度逐漸升高，計算機的計算速度會隨之下降，這可能會對結(jié)果的準確性產(chǎn)生影響。結(jié)論：（1）城市數(shù)量較多事，多個客戶端參與計算比單個客戶端計算耗時更短，計算相同問題的耗時更短，即并行計算比串行計算的計算效率更高；（2）單個客戶端需要計算的最多節(jié)點數(shù)相同時，計算耗時隨參與并行計算的客戶端數(shù)量的增加會有少幅的增長；（3）單個客戶端需要計算的最多節(jié)點數(shù)的遞減時，計算耗時也隨之遞減；（4）隨著參與并行計算的客戶端數(shù)量的增長，計算單位數(shù)量節(jié)點的耗時會逐漸遞增；旅行商問題中的城市數(shù)量比較少（6個城市）且城市數(shù)量相同，參與并行計算的客戶端的數(shù)量不同時，進行多次測試，測試以及結(jié)果的記錄如下表54所示：表54 城市數(shù)量較少（6個）不同數(shù)量客戶端并行計算耗時客戶端數(shù)量12345單個客戶端最多節(jié)點數(shù)53221第一次/ms114152161214271第二次/ms102147230198377第三次/ms146120178226303第四次/ms116145174226328第五次/ms124136183222289平均/ms1201401852173141個節(jié)點耗時/ms244793109314表54中記錄了6個城市，不同客戶端數(shù)量對并行計算耗時的影響，這和多個城市（如（2）中的10個城市）相比，明顯是有區(qū)別的。所以在上面的測試中，每種情況進行了5次測試，再求平均值，以減小測試誤差。結(jié)論：(1)城市數(shù)量較少時，并行計算耗時隨客戶端數(shù)量的增加而增加；(2)城市數(shù)量較多時，并行計算的計算效率更高；城市數(shù)量較少時，串行計算的計算效率更高。 小結(jié)這一章以旅行商問題為例，利用并行計算解決這個實際問題。最后做了一系列的測試，結(jié)果的記錄和分析，最后得出結(jié)論。 Framework Remoting技術(shù)為并行計算程序的編寫提供了簡單、靈活編程手段，大大降