【正文】 這個(gè)過程一直持續(xù)到找到所需的解或活結(jié)點(diǎn)表為空時(shí)為止。在這些兒子結(jié)點(diǎn)中，導(dǎo)致不可行解或?qū)е路亲顑?yōu)解的兒子結(jié)點(diǎn)被舍棄，其余兒子結(jié)點(diǎn)被加入活結(jié)點(diǎn)表中。 在分支限界法中，每一個(gè)活結(jié)點(diǎn)只有一次機(jī)會(huì)成為擴(kuò)展結(jié)點(diǎn)?？梢钥闯?， 分支限界法 在兩個(gè)方面加速了算法的搜索速度，一是選擇要擴(kuò)展的節(jié)點(diǎn)時(shí)，總是選擇選擇一個(gè)最小成本的結(jié)點(diǎn)，盡可能早的進(jìn)入最計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 22 有可能成為最優(yōu)解的分支；二是擴(kuò)展節(jié)點(diǎn)的過程中，舍棄導(dǎo)致不可行解或?qū)е路亲顑?yōu)解的子結(jié)點(diǎn)。在總的原則下，根據(jù)對(duì)狀態(tài)空間樹中結(jié)點(diǎn)檢索的次序的不同又將分支限界設(shè)計(jì)策路分為數(shù)種不同的檢索方法。 本系統(tǒng)采用 FIFO 分支限界法。排列問題比子集合的選擇問題通常要難于求解得多，這是因?yàn)?n 個(gè)物體有 n!種排列，只有 n個(gè)子集合 (n!O( ))。 TSP 由 美國 RAND 公司于 1948 年引入，該公司的聲譽(yù)以及線性規(guī)劃這一新方法的出現(xiàn)使得 TSP 成為一個(gè)知名且流行的問題。 ．旅行商問題研究歷史 旅行商問題字面上的理解是：有一個(gè)推銷員，要到 n個(gè)城市推銷商品，他要找出一個(gè)包含所有 n 個(gè)城市的具有最短路程的環(huán)路?？梢孕蜗蟮匕呀饪臻g 看成是一個(gè)無窮大的丘陵地帶，各山峰或山谷的高度即是問題的極值。 TSP 問題最簡單的求解方法是 枚舉法 。多年來全球數(shù)學(xué)家絞盡腦汁，試圖找到一個(gè)高效的算法 TSP 問題在物流中 的描述是對(duì)應(yīng)一個(gè)物流配送公司，欲將 n個(gè)客戶的訂貨沿最短路線全部送到。規(guī)則雖然簡單，但在地點(diǎn)數(shù)目增多后求解卻極為復(fù)雜。對(duì)需要?jiǎng)?chuàng)建的對(duì)象、事件，遠(yuǎn)程對(duì)象類進(jìn)行了說明，同時(shí)還給出了服務(wù)器端、客戶端信道從創(chuàng)建到注銷的流程介紹，并使用部分示例代碼來進(jìn)行說明。 += new MyDelegate(obj_SubscribeAtClient)。 } } } 客戶端在注冊(cè)服務(wù)器事件的時(shí)候， //訂閱服務(wù)器事件 SwapObject swap = new SwapObject()。//在服務(wù)器觸發(fā) ,在客戶端訂閱的事件 //服務(wù)器觸發(fā)事件 public void TriggerAtServerSwapEvent(string msg) { if (SwapSubscribeAtClient != null) SwapSubscribeAtClient(msg)。 = 。如下所示： //設(shè)置反序列化級(jí)別 BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider()。服務(wù)器端觸發(fā)事件是遠(yuǎn)程對(duì)象里的事件，遠(yuǎn)程對(duì)象想要被客戶端訪問就必須被序列化，原因就在于事件是基于委托的，而 . 的委托一般是不能被序列化的。 這樣，為了實(shí)現(xiàn)客戶端注冊(cè)客戶端事件，必須讓遠(yuǎn)程對(duì)象具有的特征也就很明顯了：客戶 端得到的遠(yuǎn)程對(duì)象實(shí)際上是服務(wù)器上對(duì)象的代理。這同樣也說明了在服務(wù)器端注冊(cè)對(duì)象后顯式創(chuàng)建一個(gè)對(duì)象的思路也并不可行。 在服務(wù)器注冊(cè)客戶端事件時(shí)，只要客戶端激活了遠(yuǎn)程對(duì)象，就可以發(fā)送消息，而只要服務(wù)器訂閱了此事件，就可以處理客戶端的消息了。 客戶端注冊(cè)服務(wù)器事件 客戶端注冊(cè)服務(wù)器上的事件，是個(gè)畢竟復(fù)雜的過程。 具體的實(shí)現(xiàn)思路是，在遠(yuǎn)程對(duì)象中定義一個(gè)事件，然后在某方法內(nèi)部，調(diào)用該事件的處理函數(shù)，這樣，在客戶端調(diào)用該方法時(shí)，就觸發(fā)了事件。 事件調(diào)用 服務(wù)器注冊(cè)客戶端事件 服務(wù)器注冊(cè)客戶端事件，相對(duì)客戶端注冊(cè)服務(wù)器事件來說，是比較簡單的。 } } catch (Exception ex) { ()。 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 18 if (obj == null || city_obj == null) { (連接失敗 !!)。 //獲取代理 try { obj = (NetRmtObject)(typeof(NetRmtObject), t + + :8080/url)。 創(chuàng)建對(duì)象與獲取遠(yuǎn)程對(duì)象代理 創(chuàng)建對(duì)象，也就是在客戶端激活服務(wù)器上的對(duì)象，并獲得這個(gè)遠(yuǎn)程對(duì)象的一個(gè)本地代理（透明代理）。該 URL 和 Web 瀏覽器的 URL 具有一樣的含義，具有如下的格式： 這里的協(xié)議，也就是信道的格式，如 tcp、 、 ipc。 客戶端的端口號(hào)不能與服務(wù)器一致，否則將出現(xiàn) 通常每個(gè)套接字地址 (協(xié)議 /網(wǎng)絡(luò)地址 /端口 )只允許使用一次 的異常，將其設(shè)置為 0，則客戶端自動(dòng)選擇可用的端口。 //注冊(cè)信道 TcpChannel tcpchannel = new TcpChannel(idic, clientProvider, serverProvider)。 //信道端口 IDictionary idic = new Dictionarystring, int()。 客戶端 第 4 章 .NET Remoting 框架的構(gòu)建 17 創(chuàng)建、注冊(cè)信道 客戶端的信道注冊(cè)，跟服務(wù)器端的注冊(cè)基本相同，差別在于它不必指定端口，和服務(wù)器端對(duì)應(yīng)的，則使用 TcpClientChannel、 HttpClientChannel 類等，當(dāng)然也可以使用TcpChannel、 HttpChannel 類來注冊(cè)。//傳輸 DataTable 類型變量的對(duì)象 ObjRef cityObjRef = (marshal_city_obj, url1)。//傳輸 string 類型變量的對(duì)象 ObjRef objRef = (marshal_obj, url)。 NetRmtObject marshal_obj。這里的“告訴”的過程，就是注冊(cè)遠(yuǎn)程對(duì)象。 (tcpchannel, false)。 idic[port] = 8080。 注冊(cè)信道 注冊(cè)信道就是把已經(jīng)創(chuàng)建的信道，使用 ChannelServices 類的 RegisterChannel方法來“向信道服務(wù)注冊(cè)信道”。 } } 服務(wù)器端 確定使用的信道 .NET Remoting 提供了三種預(yù)定義的信道： TCP、 HTTP、 IPC，他們各有自己的特點(diǎn)，根據(jù)自己需要進(jìn)行選擇。 } //客戶端觸發(fā)事件 public void TriggerAtServer(string msg) { if (SubscribeAtClient != null) SubscribeAtClient(msg)。//在服務(wù)器觸發(fā) ,在客戶端訂閱的事件 //無限生命 周期 public override object InitializeLifetimeService() { return null。 public class NetRmtObject : MarshalByRefObject { public event MyDelegate SubscribeAtServer。這里我需要使用代理方法而不是副本方法進(jìn)行通信，因 此需要繼承MarshallByRefObject。不是從 MarshalByRefObject 繼承的對(duì)象會(huì)以隱式方式按值封送。 由于 Remoting 傳遞的對(duì)象是以引用的方式，因此所傳遞的遠(yuǎn)程對(duì)象類必須繼承MarshalByRefObject。 創(chuàng)建遠(yuǎn)程對(duì)象類 客戶端在獲取服務(wù)器端對(duì)象時(shí)，并不是獲得實(shí)際的服務(wù)端對(duì) 象，而是獲得它的引用。 小結(jié) 本章從 .NET Remoting 技術(shù) 的定義、 .NET Remoting 技術(shù) 的主要元素、通道及激活方式對(duì)這個(gè) .NET Remoting 技術(shù) 進(jìn)行了詳細(xì)的介紹，最后補(bǔ)充說明注冊(cè)信道方法 ，有利于理解這個(gè)技術(shù)，同時(shí)利用 .NET Remoting 技術(shù)構(gòu)建框架，解決實(shí)際的復(fù)雜問題。這個(gè)方法的實(shí)現(xiàn)，其實(shí)和方法的聲明差不多，所以我說是一個(gè) trick。 如果遠(yuǎn)程對(duì)象有方法，服務(wù)器端則提供方法實(shí)現(xiàn)，而客戶端就提供這個(gè)方法就 OK 了，至于里面的實(shí)現(xiàn)，你可以是拋出一個(gè)異常，或者 return 一個(gè) null 值；如果方法返回 void，那么里面可以是空。既然具體的實(shí)現(xiàn)是在服務(wù)器端，又為了能在客戶端實(shí)例化，那么在客戶端就實(shí)現(xiàn)這些好了。既然是提供服務(wù)， Remoting 傳遞的遠(yuǎn)程對(duì)象其實(shí)現(xiàn)的細(xì)節(jié)當(dāng)然是放在服務(wù)器端。 客戶端訂閱服務(wù)器事件 實(shí)際上，我們可以用一個(gè) trick，來欺騙 Remoting。雖然 IChannel有 ChannelName 屬性，但這個(gè)屬性是只讀的。 補(bǔ)充 注 冊(cè)多個(gè)信道 在 Remoting 中，允許同時(shí)創(chuàng)建多個(gè)通道，即根據(jù)不同的端口創(chuàng)建不同的通道。 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 14 在 Remoting 中能夠傳遞的遠(yuǎn)程對(duì)象可以是各種類型，包括復(fù)雜的 DataSet 對(duì)象，只要它能夠被序列化。當(dāng)遠(yuǎn)程應(yīng)用程序引用一個(gè)按值封送的對(duì)象時(shí)，將跨越遠(yuǎn)程處理邊界傳遞該對(duì)象的副本。 MSDN 對(duì) MarshalByRefObject 的說明是： MarshalByRefObject 是那些通過使用代理交換消息 來跨越應(yīng)用程序域邊界進(jìn)行通信的對(duì)象的基類。因此在 Remoting 中，對(duì)于遠(yuǎn)程對(duì)象有一些必須的定義規(guī)范要遵循。而客戶端激活模式，則通過 CreateInstance()來激活，它可以傳遞參數(shù)，所以可以調(diào)用自定義的構(gòu)造函數(shù)來創(chuàng)建實(shí)例。其三，兩種激活模式在服務(wù)器端和客戶端實(shí)現(xiàn)的方法不一樣?？蛻舳思せ罘绞绞强蛻粢坏┌l(fā)出調(diào)用的請(qǐng)求，就實(shí)例化；而SingleCall 則是要等到調(diào)用對(duì)象方法時(shí)再創(chuàng)建?？蛻舳思せ钅Ｊ揭坏┇@得客戶端的請(qǐng)求，將為每一個(gè)客戶端都建立一個(gè)實(shí)例引用。 客戶端激活。服務(wù)器應(yīng)用程序在激活對(duì)象實(shí)例之前會(huì)在一個(gè)眾所周知的統(tǒng)一資源標(biāo)識(shí)符 (URI)上來發(fā)布這個(gè)類型。在 Remoting 中，遠(yuǎn)程對(duì)象的激活分為兩大類：服務(wù)器端激活和客戶端激活。 .NET Remoting 的激活方式 在訪問遠(yuǎn)程類型的一個(gè)對(duì)象實(shí)例之前，必須通過一個(gè)名為 Activation 的進(jìn)程創(chuàng)建它并進(jìn)行初始化。默認(rèn)情況下， HttpChannel 類型使用 Soap 格式序列化消息對(duì)象，因此它具有更好的互操作性。 HttpChannel 類型放在名字空間 中。 Tcp 通道提供了基于 Socket 的傳輸工具，使用 Tcp 協(xié)議來跨越 Remoting 邊界傳輸序列化的消息流。它們分別對(duì)應(yīng) Remoting 通道的這兩種類型。在 .Net 中， .Channels 中定義了 IChannel 接口。如果未設(shè)置應(yīng)用程序名稱，則當(dāng)前屬性將返回空引用 類 該類用于注冊(cè)信道，并把消息分派到信道上。說明一點(diǎn)的是： RemotingConfiguration 類中的大部分屬性、方法都是靜態(tài)的，這就意味著很多屬性，如 應(yīng)用程序名稱，只能通過當(dāng)前屬性或配置文件設(shè)置一次。 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 12 圖 33 消息在信道上的傳遞過程 這涉及到對(duì)象生命期管理，客戶機(jī)使用激活器在服務(wù)器上創(chuàng)建遠(yuǎn)程對(duì)象，或者說是申請(qǐng)一個(gè)遠(yuǎn)程對(duì)象的引用。客戶機(jī)調(diào)用透明代理對(duì)象上的方法，透明代理再調(diào)用真實(shí)代理上的 Invoke 方法，Invoke 方法再使用消息接受器把消息傳遞到信道上。代理對(duì)象，又分為透明代理和真實(shí)代理。 SoapFormatter 使用消息的 SOAP 表示形式將消息序列化為流。這類傳輸迫使應(yīng)用程序在發(fā)送之前將所有的二進(jìn)制數(shù)據(jù)轉(zhuǎn)換成 ASCII 文本表示形式。這是消息對(duì)象在線纜間進(jìn)行傳輸?shù)淖钣行Ф啙嵉谋硎痉绞健? 對(duì)于可以發(fā)送并接收二進(jìn)制數(shù)據(jù)（例如 TCP/IP）的網(wǎng)絡(luò)傳輸協(xié)議，可以使用 名字空間中定義的BinaryFormatter 類型。由于 . NET Remoting 體系結(jié)構(gòu)的可插入特性，可以創(chuàng)建自己的格式程序接收器，并插入到 .NET Remoting 基礎(chǔ)設(shè)施中。 為序列化消息， .NET Remoting 提供了兩類格式程序接收器： BinaryFormatter和 SoapFormatter。 它用于把格式標(biāo)識(shí)符和信道聯(lián)系起來。另外， Remoting 還支持自定義的格式標(biāo)識(shí)符。 SOAP 格式標(biāo)識(shí)符符合 SOAP 標(biāo)準(zhǔn)，比較通用，可以和非 .NET 框架的 Web 服務(wù)通信。這里的消息包括，遠(yuǎn)程對(duì)象的信息，調(diào)用方法名稱，參數(shù)，返回值等。在 .NET Remoting 中，提供了三種信道類型： TCP、 HTTP、 IPC，另外，也可以定制不同的信道以適應(yīng)不同的通信協(xié)議（至于如何定制，我尚未涉及到，因此，不好說）。另外，要說明的是，需要在網(wǎng)絡(luò)上傳遞的對(duì)象，例如“參數(shù)”，則必須是可序列化的?？蛻舳送ㄟ^代理對(duì)象來間接調(diào)用該對(duì)象的服務(wù)，如上圖的“通信體系結(jié)構(gòu)”所示。出于安全性方面的考慮，遠(yuǎn)程處理提供了大量掛鉤，使得在消息流通過通道進(jìn)行傳輸之前，安全接收器能夠訪問消息和序列化流。應(yīng)用程序可以在注重性能的場(chǎng)合使用二進(jìn)制編碼，在需要與其他遠(yuǎn)程處理框架進(jìn)行交互的場(chǎng)合使用 XML 編碼。 .NET Remoting 框架提供了多種服務(wù)，包括激活和生存期支持，以及負(fù)責(zé)與遠(yuǎn)程應(yīng)用程序進(jìn)行消息傳輸?shù)耐ㄓ嵧?