Plurk FaceBook Twitter 收進你的MyShare個人書籤 MyShare
  顯示內嵌語法

旗標電腦文摘 第227期 93.7.8
內容提供：
   旗標出版公司

旗 標 電 腦 文 摘

第227期 2004.7.8
旗標電腦文
已發行電子報





多重開機王
書號：F945
定價：198 元

施威銘研究室 著

我要線上購買


本期文摘：免安裝的作業系統光碟「LiveDVD」

本文摘錄自旗標 F945「多重開機王」一書

一般我們要讓 Windows、Linux 等不同的系統, 同時安裝於電腦上, 必定得經過繁複的硬碟分割、格式化程序, 然後再依照一定的順序, 完成系統安裝, 才能建立切換自如的多重開機架構。對於電腦早已安裝有作業系統的使用者, 操作步驟可能更麻煩, 不但要先進行系統備份, 還得曠日費時搬移檔案資料、騰出空間, 才能在硬碟上再安裝另一套系統。

在此我們將把多重開機的舞台搬到 DVD 光碟片上, 直接在光碟上創建多合 1 的開機架構, 透過光碟選單就能選擇要啟動的作業系統；而且不管在任何電腦上, 都可以直接從光碟上啟動系統, 比在硬碟上建立多重開機還方便喔！

3 合 1 LiveDVD 的秘密與準備工作

要直接從光碟來啟動作業系統, 聽來已經很不可思議了, 還要在光碟上建立多重開機, 究竟是如何辦到的？操作步驟會不會很複雜？

在此我們所要製作的這張多重開機、免安裝的系統光碟, 背後的確蘊含了不少較深入的技術細節, 不過由於有一些工具軟體的輔助, 因此製作方法並不算太困難, 在此我們就簡單說明可多重開機的 3 合 1 LiveDVD 的相關技術與製作前的準備工作。

====NOTE=======================================
近來網路上流傳不少多合 1 系統安裝光碟的製作方法, 不過僅是將多張安裝光碟整合在一起, 並無法直接從光碟上啟動作業系統, 功能和本篇所介紹的 LiveDVD 光碟並不相同。
================================================

如何讓光碟片多重開機？

目前光碟片的開機架構都是遵循 Phoenix Technologies 與 IBM 公司在 1995 年所共同發表的 El Torito 規範, 在光碟片的第 17 個 Sector (磁區) 加入開機紀錄 (Boot Record) , 配合開機目錄 (Boot Catalog) 告知系統開機檔案的正確位置。

多數燒錄軟體都具備燒錄開機光碟的功能, 只要準備好一張軟碟開機片, 或是開機片的映像檔, 燒錄軟體就會依據 El Torito 規範, 在光碟片上的指定位置寫入開機資訊。

不過由於一般燒錄軟體只能製作單一開機的光碟片, 要燒錄多重開機光碟片, 使用者就必須自行在 Boot Catalog 之中, 指定每一個開機檔案的位置。以往的作法是先將要燒錄的資料製作成映像檔後, 再利用 DISKEDIT、UltraEdit 等支援 16 進位的編輯器, 找出映像檔中每一個開機檔案的位置, 然後將這些開機資訊加入到 Boot Catalog 之中。整個操作過程必須十分熟悉光碟架構, 而且要具備一些計算機概論的基礎, 才能讓多重開機光碟正確運作, 除非是電腦高手, 否則很難成功。

為了簡化多重開機光碟繁複的製作過程, 網路上有不少多重開機光碟的製作工具, 不但可以自製開機選單, 而且只要告知開機映像檔的檔名, 就能正確啟動, 可以省去不少麻煩。EBM System 公司所推出的 Easy Boot, 堪稱目前功能最強大的多重開機光碟製作工具, 在此我們將利用它搭配 EBM System 公司另一套應用程式 UltraISO, 製作出功能強大的 3 合 1 多重開機 LiveDVD。

如何製作免安裝的作業系統？

撇開早期功能較簡單的作業系統 (如：MS-DOS) 不談, 目前 Windows、Linux 等功能較完備的作業系統, 都必須經過一定的安裝程序, 才能正常運作。近來有不少玩家開始研究, 如何讓作業系統不需安裝, 直接從光碟片上執行；具體的做法不外乎是從安裝光碟與硬碟的作業系統中, 取出作業系統的核心檔案, 並且修改部份啟動設定。由於製作過程複雜, 除非對系統有非常深入的了解, 否則很難成功。

這種不需安裝即可啟動的作業系統稱為 Live 系統, 一般都是以 CD 片備份, 因此也稱為 LiveCD。本篇我們會將 Live 系統燒錄到 DVD 光碟上, 因此改稱為 LiveDVD。 所幸網路上有一些免費工具可以利用, 讓製作過程簡化不少, 部份作業系統由於是 GNU 軟體, 甚至可以直接下載其他人製作完成的光碟映像檔。在此我們將在光碟中放入 3 套免安裝的系統, 分別是 Knoppix 系統、BartPE 系統與功能強大的維修光碟 － Ultimate BootCD, 以下分別簡單說明 3 者的製作與取得方法。

  • Knoppix 系統：Linux 算是最早發展出 LiveCD 的作業系統, 其中功能最完整的就屬 Knoppix Linux。它是由德國人 Klaus Knopper 所釋出的 Live 系統, 除了內容 Linux 的核心程式外, 也具備 Xwindow 視窗介面, 而且整合了許多常用的應用程式, 像是 OpenOffice 辦公室軟體、Mozilla 網頁瀏覽軟體, 使用上和一般 Linux 沒兩樣。

  • BartPE 系統：以 Windows XP 核心程式來啟動的 Live 系統, 提供宛如 XP 介面的作業環境。透過製作工具 － Bart's PE-Builder, 使用者可以輕易製作出個人專屬的 BartPE 系統, 並可以在此 Live 系統中添加常用的應用程式。

    ====機密檔案==============================         《微軟釋出的 Windows PE 套件》

    為了方便電腦零售商打造專屬的 Windows XP 系統, 微軟有釋出 Windows XP 的 Preinstall Environment 套件 (簡稱 Windows PE), 廠商只要以此套件啟動系統後, 就能進入宛如 XP 的作業環境。透過套件內建的各項工具, 可以自由在 XP 安裝光碟中加入廠商資訊或是其他應用軟體。

    這張 Windows PE 和 BartPE 一樣, 都是以 XP 核心程式來運作的, 網路上也有不少人以此套件來打造出 XP 的 Live 系統。不過由於此套件取得不易, 因此我們選擇以 Bart's PE-Builder 來製作 Windows XP 的 Live 系統, 而製作好的成品則稱為 BartPE 系統, 藉此和 Windows PE 做區別。 ===========================================

  • Ultimate BootCD：嚴格說來 Ultimate BootCD 並不算是 Live 系統, 只能說是一套維修系統, 不過由於內建的應用程式不少, 功能並不比 Live 系統遜色。不管是硬碟分割工具、系統備份軟體、硬體檢測工具等, 都可以透過 Ultimate BootCD 的光碟選單來執行, 在您系統掛點需要救援或是新硬碟的分割作業等, 都可以透過它來輕易完成。
製作前的準備工作

為了讓後續 LiveDVD 的製作能順利進行, 請您先參考以下說明備妥相關的條件：
  • 3 GB 左右的硬碟空間：由於 3 套系統的總容量達 1 GB 左右, 加上後續操作 3 套系統的檔案內容將先儲存於硬碟上, 再製作成映像檔, 大約要耗費 3 GB 左右, 請您事先確認硬碟上有足夠空間。

  • 建立 LiveDVD 的工作資料夾與暫存資料夾：在製作 LiveDVD 時, 將會頻繁把檔案存到硬碟上, 為了避免與其他檔案混淆, 建議您另外建立一個儲存 LiveDVD 內容的工作資料夾 (在此為 "H:\LiveDVD\"), 與一個製作過程用來暫存檔案的資料夾 (在此為 "H:\Temp\")。

  • DVD 燒錄機與燒錄空片：本篇所示範的多重開機光碟共包含了 Windows XP、Linux 系統及 DOS 下的維修工具, 由於內容豐富、資料量大, 因此必須以 DVD 片進行燒錄才能容納。

====NOTE========================================
若您手邊只有 CD-R/RW 燒錄機, 可以改製作 BartPE + Ultimate BootCD 的 2 合 1 光碟, 操作步驟大同小異。 =================================================

除了上述 3 點外, 也請您準備好 Windows XP 原版安裝光碟, 並在系統上安裝好 WinZip 壓縮軟體與 Nero 燒錄軟體, 方便後續操作。

　--- 本篇完

　
  • 這本書還有以下內容哦：
    • 建立多重開機環境的應用實例
    • 利用 Partition Magic 替硬碟進行乾坤大挪移
    • 多重開機的移除方法與分割區救援技巧
    • 無風險！用VMware 玩多重作業系統
    • Windows VS Linux 系統資料互通術 
欲知詳情請參考：
　　　F945 多重開機王

　　　　　　　　　我要買這本書
........................................︽ ........................................
　



Java 網路程式設計
書號：F8354
定價：650 元

顏春煌 著

我要線上購買

　


本期文摘：網路群播的設計

本文摘錄自旗標 F8354「Java 網路程式設計」一書

所謂的群播(multicast)是指一對多(one-to-many)的通訊方式, 也就是說通訊程式送出的訊息可以送往指定的一群接收者。IP的群播協定(IP multicast protocol)支援網際網路上的群播, 屬於網路層的協定, 需要作業系統的支援。

群播(multicast)的定義與應用

在端對端(end-to-end)的通訊模式中, 一對一的(one-to-one)通訊也稱為unicast, 前面介紹的TCP與UDP都支援一對一的通訊。當然, 在很多應用中, 一對一的通訊就夠了, 但是對於某些應用來說, 這樣的通訊方式並不合適。我們就以網際網路的視訊服務為例, 若是以unicast的方式來傳送資料, 則每個client都要與video server建立一個連線, 而這些連線上傳送的封包中, payload的資料是一樣的, 只是接收的位址不同而已, 所以比較經濟的做法是只送出一份視訊資料, 指定傳送到多個位址, 這就是所謂的群播。群播的觀念並不難理解, 但是要做到群播必須先解決一些問題：
  • 定址(addressing) : 一個IP位址只能指定一個Internet上的節點, 要指定多個節點勢必要引入群組(group)的概念, 當然我們可以把所有的目的地位址都放到封包裡, 但是這樣顯然不是好辦法。所以必須採用群組辨識(group identifier) , 由網路負責記錄群組的成員, 需要群播時就知道要往那裡送資料。
  • 成員(membership) : 網路層必須處理群組成員的問題, 應用本身與網路層之間要有成員加入(join)與離開(leave)群組的處理程序。網路層知道某個group identifier所對應的成員有那些。
  • 路由(routing) : 廣播的傳送會把封包送給所有的網路節點, 雖然能達到通訊的效果, 但是並不經濟。群播可以看成是一種比較高明的廣播機制, 只有在通往目的地的路由器才需要參與資料的收送作業, 這需要在網路層支援群播路由(multicast routing)的機制。
  • 可靠性(reliability) : TCP協定支援可靠的(reliable)資料傳送, 但這是建立在一種回應確認(acknowledgement)的機制上, 群播時無法完全採用這樣的方式, 所以如何達到可靠的群播, 仍然是需要再研究的問題。當然目前群播協定提供的仍算是不可靠的服務(unreliable service)。
====新知加油站==================================
群播有什麼實際的應用呢 ? Sun Microsystems使用IP multicast來支援Jini技術的服務發掘(service discovery) , 讓所謂的Jini結盟(Jini federation)能在動態的情況下建立起來, 另外像軟體的更新也是群播可能派得上用場的地方。 =================================================

IP群播的基本觀念

目前網際網路的群播協定是在1991年的時候在RFC 966與RFC 988上發布的, 後來成為RFC 1112的主要內容。IETF IP群播協定當然也要面對前面所介紹的問題, 以下就是一些解決的辦法：
  • 使用IPv4 class D的群組定址(group addressing) : 群播主機的群組以class D的IP位址來指定, 範圍是224.0.0.0到239.255.255.255。群組位址一般沒有再做統一的分配, 應用程式本身負責群組位址的分配。
  • 動態的成員(dynamic membership) : 主機可以任意地加入或離開一個群播的群組。群組成員的資格沒有特別的限制。假如有一台主機需要送封包給某一個群組, 則該主機本身並不一定要是此群組的成員, 可以逕行傳送。
  • 多重路由協定 : 原來的IP群播規格專注於群播的支援, 對於路由的部分並沒有說明routers之間要如何溝通。規格上提到的是主機與相鄰router之間的溝通協定, 所以router與router之間的溝通需要額外的協定來規範。
  • 採用不保證遞送的方式(unreliable delivery) : 群播的封包傳送的時候不保證遞送, 跟unicast時的情況一樣。所以群播的結果可能是所有成員都收到、沒有人收到或是部分的成員收到。
IP群播的協定已經存在超過10年了, 但是並不普遍。當然這主要是因為multicast的問題要比unicast的情況複雜多了。IP群播的主要困難可以歸納成以下幾點 :
  • 部署(deployment)的問題 : IP群播是網路層的服務, 可是大多數的網際網路協定提供的是傳輸層或是應用層的服務。網路層的服務要部署到所有的Internet的節點上, 傳輸層或是應用層的服務就沒有這樣的要求。
  • 擴充性(scalability)的問題 : 原來設計的群播路由協定以平坦的網路結構為基礎, 而群播位址的分配是隨機的, 所以群播路由表格會隨著位址數目增加而變大, 產生擴充性的問題。
  • 無法預測的網路流量 : 網際網路的流量是難以預測的, 因為缺乏控制的機制。假如再加上群播, 可能會對網路的效能產生一些不好的影響。一般ISP對於網路的主幹都會小心地維持暢通, 然後限制各access points的頻寬。
====新知加油站==================================
什麼是MBONE呢 ? MBONE(multicast backbone)是IETF所建立的IP群播網路, 使用網際網路的傳送功能建立一個虛擬網路(virtual network)。群播的封包(multicast datagrams)封裝到unicast的封包中, 等於是運用通道化(tunneling)的技術, 讓虛擬網路的端點感覺上好像在進行群播。加入MBONE的多半是教育或是學術研究單位。至於一般的IP群播比較常見於組織內部的用途, 少見跨Internet的群播。 =================================================

IP群播的原理

在0.0.0.0到233.255.255.255這個範圍的IP address可以完全地指定一個網際網路節點的位址, 為了路由上的方便與效率, 這些位址在分配與使用上採用階層式(hierarchical)的架構, IP群播位址的範圍在224.0.0.0到239.255.255.255, 任何網際網路上的節點都能自由地使用, 並沒有做階層式的分配, 因此需要一些配合的機制。

群播的範圍

有些IP群播的應用需要限制群播傳送的範圍(scope), 主要是考慮到安全性、私密性(privacy)、管制網路資源的使用, 以及可能發生的位址衝突。有兩種常見的方法可以用來限制群播傳送的範圍：
  • time-to-live scoping : 利用IP的time-to-live欄位來約束IP群播的範圍, 記錄的單位是路段的數目(number of hops)。每當IP封包轉送一次, TTL(time-to-live)的值就減1, 假如在封包到達目的地以前TTL的值變成0, 則該封包就會被移除。在區域網路中, TTL的值可以設為1, 這樣就可以確定區域網路內的節點收到封包, 路由器則會移除封包。
  • administrative scoping : 利用分配來將群播的IP位址分組, 各組有不同的群播範圍。IETF RFC 2365定義了與administrative scoping相關的資訊。就某些方面來說, administrative scoping跟TTL的方式有點類似, 但是TTL的方式與IP群播協定比較不協調, 所以administrative scoping較常使用。
====思考問題===================================
使用TTL必須了解網路的架構(topology)才能決定適當的TTL的值, 我們可以想像一下當TTL的值增加時, 群播範圍擴大的程度。通常當TTL超過32時, 就會脫離一般組織網路的範圍。 ================================================

群播的路由(multicast routing)

IP群播路由有兩個主要的組成, 一種是由所謂的邊緣主機(edge hosts)向鄰接的路由器請求加入或離開群播群組, 另外一種是處理路由器之間的群播封包。第一種IP群播路由使用標準化的IGMP(Internet Group Management Protocol), 第二種IP群播路由協定可以由網路管理者選用非標準化的協定。IP的主機透過IGMP向鄰接的群播路由器傳送群組成員的資訊, IGMP的資料可以在RFC 1112中找到。支援網際網路群播的主機必須支援IGMP協定, IGMP的訊息以一種特別的格式封裝在IP封包中。

群播的埠號(port number)

IP協定本身並不支援應用層次的定址, 也就是說IP datagrams指定送到某個IP位址, 但到了目的地以後, 並不知道該交給那個應用程式, 因此TCP與UDP使用16位元的通訊埠號碼(port number)來做應用層次的定址, 由於TCP不適合用在群播中, 所以群播一般都使用UDP協定, 但是UDP的群播應用對於port number的使用跟unicast的UDP應用不太一樣, 一般不同的群播應用會指定不同的群播位址, 所以不需要再使用port number來做所收到的封包的轉送依據, 因為從群播位址就知道該送給哪個群播應用。

不過群播應用還是可以用port number來區隔不同性質的資料傳送, 例如使用RTP協定傳送audio stream的群播應用與使用RTP協定傳送video stream的群播應用就可以在相同的群播位址下使用不同的port number, 所以接收audio與video的應用程式就可以不一樣了 !

　--- 本篇完

　
  • 這本書還有以下內容哦：
    • 系統程式設計的觀念
    • 好用的網路工具程式
    • 認識 Web 架構下的 Java 類別
    • Web 伺服端的 Servlet 設計與 JSP
    • 讓 Java 網路應用更安全 
欲知詳情請參考：
　F8354 Java 網路程式設計
 

　　　　　　　　　我要買這本書
........................................︽ ........................................
我想索取前幾期的電子報 　

好書能增進知識、提高學習效率
卓越的品質是旗標的信念與堅持

歡迎光臨旗標網站 - http://www.flag.com.tw


版權所有人：旗標出版股份有限公司     本電子報內容未經授權請勿轉載