【正文】 Therefore, the use of .NET Remoting technology to achieve parallel puting and increased puting power has important significance. The system uses .NET Framework Remoting parallel technology to solve the traveling salesman problem. Introduction .NET Framework Remoting technology, interpretation of the concept of parallel puting, given parallel puting basic programming procedures under the mechanism of parallel puting and work environment Messaging. At the same time, through the parison and analysis in puting time and performance between serial puting and parallel puting, try to understand the advantage of parallel puting in improving putational efficiency. Here is the realization of munication between client and server using .NET Remoting technology in VS20xx software, and bined with a plurality of client server, using the branch and bound method of parallel puting to solve the traveling salesman problem. Key words: .NET Remoting。 并行計(jì)算是指同時(shí)利用多種計(jì)算資源來解決計(jì)算問題的方法，是提高計(jì)算機(jī)計(jì)算速度和處理能力的一種十分有效手段。 .NET Remoting 技術(shù)是 .NET Framework 提供的 一種優(yōu)秀的分布式應(yīng)用開發(fā)技術(shù)，具有高效、可擴(kuò)展、易于配置、支持多事務(wù)、可與其它分布式應(yīng)用技術(shù)協(xié)作、能在 Inter上運(yùn)行等特點(diǎn)。在現(xiàn)代計(jì)算機(jī)的體系結(jié)構(gòu)和物理?xiàng)l件下，解決這些問題需要非常長的計(jì)算時(shí)間，計(jì)算效率非常低下，這樣很不合理。為此， Windows 平臺(tái)下的 .NET Framework Remoting 技術(shù)為并行計(jì)算程序的編寫提供了簡單、靈活編程手段，大大降低了編程難 度。 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 2 現(xiàn)在，并行計(jì)算算法的設(shè)計(jì)一般以 MIMD 類為主流，并且需要有可移植性和可擴(kuò)展性。 并行計(jì)算是相對于串行計(jì)算來說的，所謂并行計(jì)算分為時(shí)間上的并行和 空間上的并行。MIMD 類的機(jī)器又可分為以下常見的五類：并行向量處理機(jī)（ PVP）、對稱多處理機(jī)（ SMP）、大規(guī)模并行處理機(jī)（ MPP）、工作站機(jī)群（ COW）、分布式共享存儲(chǔ)處理機(jī)（ DSM）。在 Remoting 中是通過通道（ channel）來實(shí)現(xiàn)兩個(gè)應(yīng)用程序域之間對象的通信的。 在 Remoting 中，對于要傳遞的對象，設(shè)計(jì)者除了需要了解通道的類型和端口號之外，無需再了解數(shù)據(jù)包的格式。 Visual Studio 20xx 集成開發(fā)環(huán)境（ IDE）的界面被重新設(shè)計(jì)和組織 ，變得更加簡單明了。 除了上述功能外還在以下方面進(jìn)行了改進(jìn)：增強(qiáng)和完善了 Visual Studio IDE。改進(jìn)了對 WPF和 Silverlight應(yīng)用程序的開發(fā) 。 MySql 的系統(tǒng)特性有：（ 1)支持 多線程 ，充分利用 CPU 資源；（ 2)優(yōu)化的 SQL 查詢算法，有效地提高查詢速度；（ 3)既能夠作為一個(gè)單獨(dú)的 應(yīng)用程序 應(yīng)用在 客戶端服務(wù)器 網(wǎng)絡(luò)環(huán)境中，也能夠作為一個(gè)庫而嵌入到其他的軟件中；（ 4)提供多語言支持，常見的 編碼 如中文的 GB 231 BIG5，日文的 Shift_JIS等都可以用作數(shù)據(jù)表名和數(shù)據(jù)列名；（（ 5)提供 TCP/IP、ODBC 和 JDBC 等多種 數(shù)據(jù)庫 連接途徑；（ 6)提供用于管理、檢查、優(yōu)化數(shù)據(jù)庫操作的 管理工具 ；（ 7)支持大型的 數(shù)據(jù)庫 。 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 4 第 2 章 并行計(jì)算 5 第 2 章 并行計(jì)算 并行計(jì)算是伴隨并行機(jī)的出現(xiàn)，在近 30年來發(fā)展較迅速的一門交叉學(xué)科，涵蓋的內(nèi)容非常廣泛。 它的基本思想是用多個(gè)處理器來協(xié)同求解同一問題，即將被求解的問題分解成若 干個(gè)部分，各部分均由一個(gè)獨(dú)立的處理機(jī)來并行計(jì)算。 并行計(jì)算是相對于串行計(jì)算來說的，所謂并行計(jì)算分為時(shí)間上的并行和空間上的并行。一般來說，因?yàn)閿?shù)據(jù)并行主要是將一個(gè)大任務(wù)化解成相同的各個(gè)子任務(wù)，比 任務(wù)并行 要容易處理。 并行計(jì)算的主要研究目標(biāo)和研究內(nèi)容 并行計(jì)算的主要研究目標(biāo) 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 6 對于具體的應(yīng)用問題，采用并行計(jì)算技術(shù)的主要目的在于以下 2 個(gè)方面： （ 1）加快求解問題的速度，縮短求解問題所需的時(shí)間。近兩年內(nèi) ，微處理器的峰值性能也不會(huì)超過 100 億次 /秒。 （ 2）并行算法設(shè)計(jì)與分析。需要說明的是，并行計(jì)算不同于分布式計(jì)算。并行算法作為應(yīng)用程序開發(fā)的基礎(chǔ)，在并行計(jì)算機(jī)應(yīng)用中具有舉 足輕重的地位。 在這里，我使用的并行算法也是當(dāng)前并行算法的主流算法，也就是大粒度并行算法。如圖 21 所示： 圖 21 多臺(tái)計(jì)算機(jī)并行計(jì)算連機(jī)交互示意 圖 在網(wǎng)絡(luò)中傳輸數(shù)據(jù)，原本有很多復(fù)雜的步驟，對編程者有著很高的要求，但是微軟的 .NET Remoting 技術(shù)，將消息的傳遞機(jī)制都封裝的很好，大大降低了編程者對 Remoting編程的難度。 單計(jì)算機(jī)的并行計(jì)算 計(jì)算機(jī)信息工程學(xué)院畢業(yè)設(shè)計(jì)論文 8 單計(jì)算機(jī)的并行計(jì)算，一般指同一臺(tái)機(jī)器上的多線程并行計(jì)算。 要注意的是，當(dāng)一個(gè)線程完成計(jì)算任務(wù)之后，并不會(huì)自動(dòng)釋放該實(shí)例，需要在程序中調(diào)用方法釋放內(nèi)存。但是這對計(jì)算機(jī)的硬件要求比較苛刻。 單 CPU 多 核的計(jì)算機(jī)，也可以啟用多個(gè)線程進(jìn)行并行計(jì)算，但是這種計(jì)算是有瓶頸的。 小結(jié) 這一章先講了并行計(jì)算的概念，接著講了并行計(jì)算的研究目標(biāo)和研究內(nèi)容，按照不同的對象將并行算法進(jìn)行分類，最后對分布式并行計(jì)算的幾種方式進(jìn)行了分析，在這里我主要研究的 就是多計(jì)算機(jī)的并行計(jì)算問題。也就是說，使用 .NET Remoting，一個(gè)程序域可以訪 問另外一個(gè)程序域中的對象，就好像這個(gè)對象位于自身內(nèi)部，只不過，對這個(gè)遠(yuǎn)程對象的調(diào)用，其代碼是在遠(yuǎn)程應(yīng)用程序域中進(jìn)行的，例如在本地應(yīng)用程序域中調(diào)用遠(yuǎn)程對象上一個(gè)會(huì)彈出對話框的方法，那么，這個(gè)對話框，則會(huì)在遠(yuǎn)程應(yīng)用程序域中彈出。在從一個(gè)應(yīng)用程序 域向另一個(gè)應(yīng)用程序域傳輸消息時(shí)，所有的 XML 編碼都使用 SOAP 協(xié)議。在 .NET Remoting 體系中，要想成為遠(yuǎn)程對象提供服務(wù)，該對象的類必須是 MarshByRefObject 的派生對象。 客戶機(jī)和服務(wù)器通過消息進(jìn)行信息交換，消息在信道中傳遞。二進(jìn)制格式標(biāo)識符，則在速度、效率上面更生一籌，但通用性較 SOAP 差。在創(chuàng)建信道時(shí)，可以指定所要使用的標(biāo)識符提供程序，一旦指定了提供程序， 那么消息被發(fā)送到信道上的格式也就確定了下來。這種靈活性使基礎(chǔ)設(shè)施能夠支持可能的各種線路格式。一些網(wǎng)絡(luò)傳輸系統(tǒng)不允許發(fā)送和接收二進(jìn)制數(shù)據(jù)。 前面也說過，客戶端不能直接調(diào)用遠(yuǎn)程對象，客戶機(jī)只能通過代理對象來操作遠(yuǎn)程對象。 圖 33 是客戶機(jī)的方法調(diào)用導(dǎo)致消息在信道間傳遞的一個(gè)體系結(jié)構(gòu)圖： 如上圖所示，消息接受器在服務(wù)器端和客戶端都有，接受真實(shí)代理的調(diào)用，把序列化的消息發(fā)布到信道上。如果應(yīng)用程序運(yùn)行在宿主環(huán)境中，例如 Inter 信息服務(wù) (IIS)，則可能已經(jīng)設(shè)置了該值（通常將其設(shè)置為虛擬目錄）。 IChannel 接口包括了 TcpChannel 通道類型和 Http通道類型。 TcpChannel 類型默認(rèn)使用二進(jìn)制格式序列化消息對象，因此它具有更高的傳輸性能。通常在局域網(wǎng)內(nèi)，我們更多地使用 TcpChannel；如果要穿越防火墻，則應(yīng)該使用 HttpChannel 比較好。 服務(wù)器端激活，又叫做 WellKnow 方式。與 WellKnown 模式不同， Remoting 在激活每個(gè)對象實(shí)例的時(shí)候，會(huì)給每個(gè)客戶端激活的類型指派一個(gè) URI。其次， SingleCall模式激活的對象是無狀態(tài)的，對象生命期的管理是由 GC 管理的，而客戶端激活的對象則有狀態(tài)，其生命周期可自定義。 .NET Remoting 的對象定義 前面講到，客戶端在獲取服務(wù)器端對象時(shí)，并不是獲得實(shí)際的服務(wù)端對象，而是獲得它的引用。不是從 MarshalByRefObject 繼承的對象會(huì)以隱式方式按值封送。遠(yuǎn)程對象也可以包含事件，但服務(wù)器端對于事件的處理比較特殊，我將在本系列之三中介紹。因此前面所述的創(chuàng)建通道的方法無法實(shí)現(xiàn)同時(shí)注冊多個(gè)通道的要求。而要在客戶端放對象的副本，不過是因?yàn)榭蛻舳吮仨氄{(diào)用構(gòu)造函數(shù)，而采取的無奈之舉。關(guān)鍵是這個(gè)客戶端類對象要有這個(gè)方法。 第 4 章 .NET Remoting 框架的構(gòu)建 15 第 4 章 .NET Remoting 框架的構(gòu)建 對 .NET Remoting 技術(shù)有了一定的了解之后，就可以開始 .NET Remoting 框架的構(gòu)建了。 MarshalByRefObject 是那些通過使用代理交換消息來跨越應(yīng)用程序域邊界進(jìn)行通信的對象的基類。 public delegate void MyDelegate(string msg)。 } //服務(wù)器觸發(fā)事件 public void TriggerAtClient(string msg) { if (SubscribeAtServer != null) SubscribeAtServer(msg)。對于每個(gè)信道，都有一些可以配置的信息。 //注冊信道 TcpChannel tcpchannel = new TcpChannel(idic, clientProvider, serverProvider)。 CityObject marshal_city_obj。 marshal_city_obj = new CityObject()。 在創(chuàng)建了信道后，也是使用 ChannelServices 類的 RegisterChannel 方法來完成信道的注冊。 (tcpchannel, false)。不過，由于 IPC 機(jī)制只能 使用在單個(gè)機(jī)器上，因此，不需要使用服務(wù)器地址。 city_obj = (CityObject)(typeof(CityObject), + + :8080/url1)。 } 注銷信道 客戶端的信道注銷和服務(wù)器端是一樣的，這里就不再做過多說明。 //服務(wù)器綁定客戶端觸發(fā)的事件 += new MyDelegate(marshal_obj_SubscribeAtServer)。 在激活遠(yuǎn)程對象前，服務(wù)所做必須做的是“注冊”該遠(yuǎn)程對象類以給客戶端提供服務(wù)，然后由客戶端決定何時(shí)來創(chuàng)建一個(gè)遠(yuǎn)程對象，也就是說，服務(wù)器端沒有顯式的創(chuàng)建過遠(yuǎn)程對象，這樣，既然服務(wù)器端沒有顯式的對象，那么又如何來顯式的操作之以傳遞消息呢？ 客戶端的使用的遠(yuǎn)程對象只是一個(gè)代理，和服務(wù)器 上的遠(yuǎn)程對象處于完全不同的應(yīng)用程序域，或者說，服務(wù)器上的對象和客戶端的對象是具有相似性但完全不同的兩個(gè)“物體”，因此，在服務(wù)器端，或者是在客戶端對各自對象所做的操作，是不會(huì)互相影響的。也就是說：客戶端獲取的那個(gè)代理對象，用它來訂閱服務(wù)器的事件是訂閱不到的。 BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider()。 } //無限生命周期 public override object InitializeLifetimeService() { return null。 小結(jié) 這一章是對 .NET Remoting技術(shù)框架構(gòu)建中各個(gè)重點(diǎn)模塊的描述。以 42 個(gè)地點(diǎn)為例，如果要列舉所有路徑后再確定最佳行程，那么總路徑數(shù)量之大，幾乎難以計(jì)算出來。它的解是多維的、多局部極值的、趨于無窮大的復(fù)雜解的空間，搜索空間是 n個(gè)點(diǎn)的所有排列的集合，大小為（ n1）！。 TSP 的歷史很久，最早的描述是 1759 年歐拉研究的騎士周游問題，即對于 國際象棋棋盤中的 64 個(gè)方格 ，走訪 64個(gè)方格一次且僅一次，并且最終返回到起始點(diǎn)。通過枚舉 (n1)!條周游路線，從中找出一條具有最小成本的周游路線的 算法 ，其計(jì)算時(shí)間顯然為 O(n!)。在求解旅行商 問題時(shí)，程序中采用 FIFO 檢索（ First In First Out），它的活結(jié)點(diǎn)表采用一張先進(jìn)先出表（即隊(duì)列）?；罱Y(jié)點(diǎn)一旦成為擴(kuò)展結(jié)點(diǎn)，就一次性產(chǎn)生其所有