【正文】 C 的首選技，它允許不同應(yīng)用程序域之間進(jìn)行通信。也就是說(shuō)，使用 .NET Remoting，一個(gè)程序域可以訪 問另外一個(gè)程序域中的對(duì)象，就好像這個(gè)對(duì)象位于自身內(nèi)部，只不過，對(duì)這個(gè)遠(yuǎn)程對(duì)象的調(diào)用，其代碼是在遠(yuǎn)程應(yīng)用程序域中進(jìn)行的，例如在本地應(yīng)用程序域中調(diào)用遠(yuǎn)程對(duì)象上一個(gè)會(huì)彈出對(duì)話框的方法，那么，這個(gè)對(duì)話框，則會(huì)在遠(yuǎn)程應(yīng)用程序域中彈出。格式化程序用于在消息通過通道傳輸之前，對(duì)其進(jìn)行編碼和解碼。在從一個(gè)應(yīng)用程序 域向另一個(gè)應(yīng)用程序域傳輸消息時(shí)，所有的 XML 編碼都使用 SOAP 協(xié)議。 圖 31 .NET Remoting 協(xié)同工作能力 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 10 圖 32 是 .NET Remoting 的體系結(jié)構(gòu)圖： 圖 32 .NET Remoting 通信體系結(jié)構(gòu) .NET Remoting 技術(shù)的主要元素 一般來(lái)說(shuō)， .NET Remoting 包括如下幾點(diǎn)主要元素： 運(yùn)行在 Remoting 服務(wù)器上的對(duì)象。在 .NET Remoting 體系中，要想成為遠(yuǎn)程對(duì)象提供服務(wù)，該對(duì)象的類必須是 MarshByRefObject 的派生對(duì)象。 信道是服務(wù)器和客戶機(jī)進(jìn)行通信用的（這里的服務(wù)器和客戶機(jī)并不一定都是計(jì)算機(jī)，也可能是進(jìn)程）。 客戶機(jī)和服務(wù)器通過消息進(jìn)行信息交換，消息在信道中傳遞。 第 3 章 .NET Remoting 技術(shù) 11 該標(biāo)識(shí)符標(biāo)明了消息是按照什么樣的格式被發(fā)送到信道上的，目前 .NET 提供了兩種格式標(biāo)識(shí)符： SOAP 格式和二進(jìn)制格式。二進(jìn)制格式標(biāo)識(shí)符，則在速度、效率上面更生一籌，但通用性較 SOAP 差。其中， TCP 信道，默認(rèn)使用二進(jìn)制格式傳輸，因?yàn)檫@個(gè)效率更高； Http 信道則默認(rèn)使用 SOAP 格式；不過在系統(tǒng)中，哪種信道具體使用哪種格式，則是可以根據(jù)需要設(shè)置的。在創(chuàng)建信道時(shí)，可以指定所要使用的標(biāo)識(shí)符提供程序，一旦指定了提供程序， 那么消息被發(fā)送到信道上的格式也就確定了下來(lái)。選擇的類型很大程度上取決于連接分布式對(duì)象的網(wǎng)絡(luò)環(huán)境的類型。這種靈活性使基礎(chǔ)設(shè)施能夠支持可能的各種線路格式。顧名思義， BinaryFormatter 將消息對(duì)象序列化為一個(gè)二進(jìn)制格式的流。一些網(wǎng)絡(luò)傳輸系統(tǒng)不允許發(fā)送和接收二進(jìn)制數(shù)據(jù)。在這種情況下（或者要得到最佳協(xié)作能力的時(shí)候）， .NET Remoting 在 名 字 空 間 中 提 供SoapFormatter 類型。 前面也說(shuō)過，客戶端不能直接調(diào)用遠(yuǎn)程對(duì)象，客戶機(jī)只能通過代理對(duì)象來(lái)操作遠(yuǎn)程對(duì)象。在客戶機(jī)看來(lái)，代理對(duì)象和遠(yuǎn)程對(duì)象是一樣的。 圖 33 是客戶機(jī)的方法調(diào)用導(dǎo)致消息在信道間傳遞的一個(gè)體系結(jié)構(gòu)圖： 如上圖所示，消息接受器在服務(wù)器端和客戶端都有，接受真實(shí)代理的調(diào)用，把序列化的消息發(fā)布到信道上。 類 該類用于配置遠(yuǎn)程服務(wù)器和客戶機(jī)的一個(gè)實(shí)用類，它可以用于讀取配置文件或者動(dòng)態(tài)地配置遠(yuǎn)程對(duì)象。如果應(yīng)用程序運(yùn)行在宿主環(huán)境中，例如 Inter 信息服務(wù) (IIS)，則可能已經(jīng)設(shè)置了該值（通常將其設(shè)置為虛擬目錄）。 .NET Remoting 的兩種通道 Remoting 的通道主要有兩種： Tcp 和 Http。 IChannel 接口包括了 TcpChannel 通道類型和 Http通道類型。 第 3 章 .NET Remoting 技術(shù) 13 TcpChannel 類型放在名字空間 中。 TcpChannel 類型默認(rèn)使用二進(jìn)制格式序列化消息對(duì)象，因此它具有更高的傳輸性能。它提供了一種使用 Http 協(xié)議，使其能在 Inter 上穿越防火墻傳輸序列化消息流。通常在局域網(wǎng)內(nèi)，我們更多地使用 TcpChannel；如果要穿越防火墻，則應(yīng)該使用 HttpChannel 比較好。這種客戶端通過通道來(lái)創(chuàng)建遠(yuǎn)程對(duì)象，稱為對(duì)象的激活 。 服務(wù)器端激活，又叫做 WellKnow 方式。然后該服務(wù)器進(jìn)程會(huì)為此類型配置一個(gè) WellKnown 對(duì)象，并根據(jù)指定的端口或地址來(lái)發(fā)布對(duì)象。與 WellKnown 模式不同， Remoting 在激活每個(gè)對(duì)象實(shí)例的時(shí)候，會(huì)給每個(gè)客戶端激活的類型指派一個(gè) URI。 SingleCall 模式和客戶端激活模式是有區(qū)別的：首先，對(duì)象實(shí)例創(chuàng)建的時(shí)間不一樣。其次， SingleCall模式激活的對(duì)象是無(wú)狀態(tài)的，對(duì)象生命期的管理是由 GC 管理的，而客戶端激活的對(duì)象則有狀態(tài)，其生命周期可自定義。尤其是在客戶端， SingleCall 模式是由 GetObject()來(lái)激活，它調(diào)用對(duì)象默認(rèn)的構(gòu)造函數(shù)。 .NET Remoting 的對(duì)象定義 前面講到，客戶端在獲取服務(wù)器端對(duì)象時(shí)，并不是獲得實(shí)際的服務(wù)端對(duì)象，而是獲得它的引用。 由于 Remoting 傳遞的對(duì)象是以引用的方式，因此所傳遞的遠(yuǎn)程對(duì)象類必須繼承MarshalByRefObject。不是從 MarshalByRefObject 繼承的對(duì)象會(huì)以隱式方式按值封送。因?yàn)槟Ｍ褂么矸椒ǘ皇歉北痉椒ㄟM(jìn)行通信，因此需要繼承 MarshallByRefObject。遠(yuǎn)程對(duì)象也可以包含事件，但服務(wù)器端對(duì)于事件的處理比較特殊，我將在本系列之三中介紹。但是，Remoting 要求通道的名字必須不同，因?yàn)樗脕?lái)作為通道的唯一標(biāo)識(shí)符。因此前面所述的創(chuàng)建通道的方法無(wú)法實(shí)現(xiàn)同時(shí)注冊(cè)多個(gè)通道的要求。這里所說(shuō)的替代類就是這個(gè) trick了。而要在客戶端放對(duì)象的副本，不過是因?yàn)榭蛻舳吮仨氄{(diào)用構(gòu)造函數(shù)，而采取的無(wú)奈之舉。至于實(shí)現(xiàn)的細(xì)節(jié)，就不用管了。關(guān)鍵是這個(gè)客戶端類對(duì)象要有這個(gè)方法。方法如是，構(gòu)造函數(shù)也如此。 第 4 章 .NET Remoting 框架的構(gòu)建 15 第 4 章 .NET Remoting 框架的構(gòu)建 對(duì) .NET Remoting 技術(shù)有了一定的了解之后，就可以開始 .NET Remoting 框架的構(gòu)建了。因此在 Remoting 中，對(duì)于遠(yuǎn)程對(duì)象有一些必須的定義規(guī)范要遵循。 MarshalByRefObject 是那些通過使用代理交換消息來(lái)跨越應(yīng)用程序域邊界進(jìn)行通信的對(duì)象的基類。當(dāng)遠(yuǎn)程應(yīng)用程序引用一個(gè)按值封送的對(duì)象時(shí)，將跨越遠(yuǎn)程處理邊界傳遞該對(duì)象的副本。 public delegate void MyDelegate(string msg)。//在客戶端觸發(fā) ,在服務(wù)器訂閱的事件 public event MyDelegate SubscribeAtClient。 } //服務(wù)器觸發(fā)事件 public void TriggerAtClient(string msg) { if (SubscribeAtServer != null) SubscribeAtServer(msg)。 } //獲取委托列表 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 16 public Delegate[] GetServerEventList() { return ()。對(duì)于每個(gè)信道，都有一些可以配置的信息。 //信道端口 IDictionary idic = new Dictionarystring, int()。 //注冊(cè)信道 TcpChannel tcpchannel = new TcpChannel(idic, clientProvider, serverProvider)。 注冊(cè)遠(yuǎn)程對(duì)象 服務(wù)器端打算發(fā)布一個(gè)可以被客戶端調(diào)用的遠(yuǎn)程對(duì)象，那它必須以某種方式“告訴”系統(tǒng)：我這里有一個(gè)這樣的服務(wù)可供你使用。 CityObject marshal_city_obj。 //服務(wù)器獲取遠(yuǎn)程對(duì)象 marshal_obj = new NetRmtObject()。 marshal_city_obj = new CityObject()。 注銷信道 在程序關(guān)閉時(shí)，或者清理資源時(shí)，要關(guān)閉調(diào)已經(jīng) 注冊(cè)的信道，這樣好讓出服務(wù)所使用的計(jì)算機(jī)端口，方法就是調(diào)用 即可實(shí)現(xiàn)。 在創(chuàng)建了信道后，也是使用 ChannelServices 類的 RegisterChannel 方法來(lái)完成信道的注冊(cè)。 idic[port] = 0。 (tcpchannel, false)。 發(fā)現(xiàn) URL 客戶端要激活服務(wù)器上的遠(yuǎn)程對(duì)象，也就是說(shuō)要獲得一個(gè)遠(yuǎn)程對(duì)象的本地代理，則必須首先獲得遠(yuǎn)程對(duì)象的 URL。不過，由于 IPC 機(jī)制只能 使用在單個(gè)機(jī)器上，因此，不需要使用服務(wù)器地址。 在客戶端創(chuàng)建遠(yuǎn)程對(duì)象，有兩種方法，一種是使用 new 方法來(lái)創(chuàng)建，另外一種方法則是使用激活類的 Activator 的創(chuàng)建方法。 city_obj = (CityObject)(typeof(CityObject), + + :8080/url1)。 return。 } 注銷信道 客戶端的信道注銷和服務(wù)器端是一樣的，這里就不再做過多說(shuō)明。因?yàn)椋蛻舳嗽谡{(diào)用服務(wù)器上的遠(yuǎn)程對(duì)象時(shí)，代 碼都在服務(wù)器上執(zhí)行，服務(wù)器很容易截獲這一事件，從而進(jìn)行自己的處理。 //服務(wù)器綁定客戶端觸發(fā)的事件 += new MyDelegate(marshal_obj_SubscribeAtServer)。 剛開始的時(shí)候，以為和服務(wù)器注冊(cè)客戶端事件是 一樣的，但是實(shí)踐的時(shí)候發(fā)生錯(cuò)誤，再仔細(xì)思考一下，發(fā)現(xiàn)客戶端注冊(cè)服務(wù)器事件和服務(wù)器端注冊(cè)客戶端事件是完全不同的。 在激活遠(yuǎn)程對(duì)象前，服務(wù)所做必須做的是“注冊(cè)”該遠(yuǎn)程對(duì)象類以給客戶端提供服務(wù)，然后由客戶端決定何時(shí)來(lái)創(chuàng)建一個(gè)遠(yuǎn)程對(duì)象，也就是說(shuō)，服務(wù)器端沒有顯式的創(chuàng)建過遠(yuǎn)程對(duì)象，這樣，既然服務(wù)器端沒有顯式的對(duì)象，那么又如何來(lái)顯式的操作之以傳遞消息呢？ 客戶端的使用的遠(yuǎn)程對(duì)象只是一個(gè)代理，和服務(wù)器 上的遠(yuǎn)程對(duì)象處于完全不同的應(yīng)用程序域，或者說(shuō)，服務(wù)器上的對(duì)象和客戶端的對(duì)象是具有相似性但完全不同的兩個(gè)“物體”，因此，在服務(wù)器端，或者是在客戶端對(duì)各自對(duì)象所做的操作，是不會(huì)互相影響的。 第 4 章 .NET Remoting 框架的構(gòu)建 19 客戶端要訂閱服務(wù)器事件，那么事件處理程序向?qū)ο蟮淖?cè)動(dòng)作，也就應(yīng)該在客戶端完成，而服務(wù)器端還需逐個(gè)調(diào)用各個(gè)客戶端注冊(cè)的處理程序，這就要求客戶端和服務(wù)器端所操作的對(duì)象是“同一個(gè)”。也就是說(shuō)：客戶端獲取的那個(gè)代理對(duì)象，用它來(lái)訂閱服務(wù)器的事件是訂閱不到的。 查閱資料 ,這就需要換一種方式注冊(cè)信道 ,在注冊(cè)信道的時(shí)候強(qiáng)制設(shè)置可序列化級(jí)別為 所有類型 ，這樣就可以將事件序列化。 BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider()。//支持所有類型的反序列化，級(jí)別很高 同時(shí)創(chuàng)建新的 SwapObject 類，部分代碼如下所示： public class SwapObject : MarshalByRefObject { public event MyDelegate SwapSubscribeAtClient。 } //無(wú)限生命周期 public override object InitializeLifetimeService() { return null。 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 20 += new MyDelegate()。 小結(jié) 這一章是對(duì) .NET Remoting技術(shù)框架構(gòu)建中各個(gè)重點(diǎn)模塊的描述。 第 5 章 解決實(shí)際問題 21 第 5 章 解決實(shí)際問題 ．旅行商問題簡(jiǎn)介 “旅行商問題”常被稱為“ 旅行推銷員問題 ”，是指一名推銷員要拜訪多個(gè)地點(diǎn)時(shí)，如何找到在拜訪每個(gè)地點(diǎn)一次后再回到起點(diǎn)的最短路徑。以 42 個(gè)地點(diǎn)為例，如果要列舉所有路徑后再確定最佳行程，那么總路徑數(shù)量之大，幾乎難以計(jì)算出來(lái)。如何確定最短路線。它的解是多維的、多局部極值的、趨于無(wú)窮大的復(fù)雜解的空間，搜索空間是 n個(gè)點(diǎn)的所有排列的集合，大小為（ n1）！。求解 TSP，則是在此不能窮盡的丘陵地帶中攀登以達(dá)到山頂或谷底的過程。 TSP 的歷史很久，最早的描述是 1759 年歐拉研究的騎士周游問題，即對(duì)于 國(guó)際象棋棋盤中的 64 個(gè)方格 ，走訪 64個(gè)方格一次且僅一次，并且最終返回到起始點(diǎn)。 ．旅行商問題問題分析 旅行商問題要從圖 G的所有周游路線中求取最小成本的周游路線，而從初始點(diǎn)出發(fā)的周游路線一共有 (n1)!條，即等于除初始結(jié)點(diǎn)外的 n1 個(gè)結(jié)點(diǎn)的排列數(shù)，因此旅行商問題是一個(gè) 排列 問題。通過枚舉 (n1)!條周游路線，從中找出一條具有最小成本的周游路線的 算法 ，其計(jì)算時(shí)間顯然為 O(n!)。 如前所 述， 分支 限界法是在生成當(dāng)前 E結(jié)點(diǎn)全部?jī)鹤又笤偕善渌罱Y(jié)點(diǎn)的兒子，且用限界函數(shù)幫助避免生成不包含答案結(jié)點(diǎn)子樹的 狀態(tài)空間 的檢索方法。在求解旅行商 問題時(shí)，程序中采用 FIFO 檢索（ First In First Out），它的活結(jié)點(diǎn)表采用一張先進(jìn)先出表（即隊(duì)列）。 分支限界法常以廣度優(yōu)先或以最 小耗費(fèi)（最大效益）優(yōu)先的方式搜索問題的解空間樹?；罱Y(jié)點(diǎn)一旦成為擴(kuò)展結(jié)點(diǎn)，就一次性產(chǎn)生其所有兒子結(jié)點(diǎn)。 此后，從活結(jié)點(diǎn)表中取下一結(jié)點(diǎn)成為當(dāng)前擴(kuò)展結(jié)點(diǎn)，并重復(fù)上述結(jié)點(diǎn)