第一章緒論

1.1 研究動機

隨著網際網路的蓬勃發展，電腦的使用已不再限於傳統的計算輔助功能；藉由網路的連通，人們已經越來越習慣於藉由網路來互相傳遞訊息、分享資源，電腦也因此變得越來越生活化。

然而，在網路扮演的角色日益重要的今天，網路的品質與頻寬卻似乎永遠趕不上網路人口增加的速度，一直無法達到令人滿意的水準。因此，如何在有限的網路硬體資源上，利用軟體的適當設計，來提升網路的傳輸效率和品質，就成了一個很重要的課題。

1.2 背景說明

為了突破網路硬體傳輸效率上的限制，許多網路上的應用都會設法利用一些特殊的設計來輔助提升網路的運作效率。利用軟體來提升網路傳輸效率的方法很多，通常最常見的方法就是使用代理伺服器（proxy server）。代理伺服器可以利用快取（cache）的機制，有效降低不必要的網路傳送時間，達到提升傳輸效率的目的。

然而，代理伺服器仍然有問題存在，例如會動態改變的資料就無法藉由快取來加速存取，而且目前代理伺服器主要使用在WWW與FTP等特定網路應用上，並無法對於網路上其他方面的存取應用，都提供一個完整的解決方法。

同樣的，在行動計算系統（Mobile Computing System）方面，網路應用程式最重要的就是要能容忍網路傳輸的不穩定度[4][17][18]，尤其是時時要面對斷線、重新連線的問題，有時候甚至必須在各伺服器間切換尋求最快速的服務，這時若能有一個考慮周全的底層系統對應用程式提供完全透明化（transparent）的服務，讓應用程式完全不需對於網路穩定度作特別的處理，將會使應用程式的發展更快速，且更具整合性。

近兩年來，Java的發展速度十分驚人，其跨平台的特性，以及優異的物件導向語法，使得Java非常適合用來發展系統、開發應用程式。Java虛擬機器利用軟體模擬電腦的特色，讓Java不只是一種新的語言而已。廣義的看，Java已經是一種新的作業平台了。Java虛擬機器可以在現有的電腦硬體和許多作業系統上執行，也可在專為Java設計的硬體上執行。

Java把軟體抽象的層次往上推了一層，在虛擬機器之下，什麼都是抽象的。設計之初，考慮的便是與作業系統或CPU無關的環境，不管底層的軟硬體如何替換，上面的Java程式永遠執行得安然無恙。

因此，我們所提供的發展平台，為了能適應各種環境的需求，一律使用Java為主要的發展與執行環境。藉助於Java優良的物件導向語法和跨平台特性，使得系統之發展十分容易架構，也很容易在各平台上執行。

1.3 相關研究

為了解決分散式環境下的運算問題，最簡單的方式就是利用分散式的檔案系統[5]，例如UNIX上面的NFS（Network File System）[1] 以及MS Windows所使用的Server Message Block（SMB）[10]之檔案、印表機分享。這些僅止於檔案系統分散運算的方法，對於真正的分散式的環境需求雖然算是十分的原始，但也是最簡單的解決方法。

然而，網路傳輸效率卻是這些系統面臨的最大瓶頸，例如NFS在大網域上會造成存取效率的降低，分散式的檔案系統，若遇到頻繁的檔案存取要求，無可避免的要付出網路壅塞所造成的效率降低代價。因此，如何提升分散式檔案系統的運作效率，讓對網路傳輸的需求儘量減少，將是下一代的分散式檔案系統最重要的工作之一。

在CMU發展的Andrew File System（AFS）[9]也是一個分散式的檔案系統，最主要是希望改進傳統NFS在大網域上效率的問題，更有效地分享檔案資源。AFS系統的一個重要功能是為檔案的存取動作加上了快取的機制，這使得檔案存取的效率大幅提高，並因此有效減低網路傳輸量。

AFS另外一個不同於NFS的特點是，檔案系統內的檔名（Name space）對全世界的AFS系統而言是唯一的，它在檔案的命名上，加入了機器的位址當作目錄名稱，例如：” / afs / cc.nctu.edu.tw / …. ”，這使得檔案的存取能夠更便捷，從單一台機器就能存取全世界的AFS檔案系統。

在網路狀況比較不穩定的狀況，例如行動計算環境之下，AFS的快取功能仍然不足以應付頻繁的斷線、重新連線、以及長時間的離線狀態。為此，CMU的另一群研究員發展了一套稱為Coda [19][20] 的檔案系統。

Coda系統的目標是「Access information on demand when mobile」，也就是希望讓資訊的存取能不受行動計算環境下特殊網路狀態的影響。Coda希望藉由Server replication與disconnected operation[7][8]兩個機制來有效應付伺服器或網路發生問題時的狀況。

對於離線動作，Coda對應用程式提供一個完全透明化的服務（application transparent）[13]，讓應用程式在離線狀態，仍然能以一般的方法存取檔案，所有快取的更新，以及資料複製一致性（consistency）的維護，都由系統自動幫忙完成。

另外，與Coda相似的另一系統Odyssey [21]，則是採用application-aware的方式，應用程式可以隨時得知網路目前的狀態，並自行依據應用程式的特性，作出適當的反應。Odyssey同樣會幫忙維護資料的一致性，並儘可能讓應用程式得到最多想存取的資料。

1.4 系統簡介

為了解決網路傳輸的不穩定度，同時也為了能廣泛應用在各種網路應用程式中，我們使用一個底層的檔案系統，配合所提供的功能呼叫，來作為所有網路服務的發展平台。而不同於前面所述的AFS、Coda等檔案系統的是，我們的檔案系統主要是網路存取的抽象化，用以將網路存取的動作對網路環境的適應性（adaptation）作特殊考量。利用這一個通用的底層介面環境，我們希望各類網路服務可以很容易在此介面上建立，並同樣享受到底層系統所帶來的快取、容錯、續傳及批次處理等好處。

我們將首先以E-Mail電子郵件之收發信為例，建立完整的功能展示，來證明此一架構之可用性。在底層介面中，我們使用一個通用性的檔案系統，稱之為General File System（GFS），來當作基本的網路應用程式發展平台。接下來，我們也將建立一個簡單的FTP檔案傳輸服務，來進一步說明此發展平台之通用性。

本系統的架構將大致如下圖所示：

圖 1 系統架構圖

除了底層通用性的部份之外，我們將在其上建立E-Mail proxy與FTP proxy，來將特定的網路服務要求轉為對GFS檔案系統之存取，讓E-Mail與FTP兩種網路服務，能同時享受到底層GFS所帶來的各種好處。在Proxy之上，我們也為該項服務之通訊協定，作了適當的修正，讓應用程式更容易能利用到底層系統所提供的種種功能。

利用這種三層式架構，我們把網路的應用適當得作一個分工，最底層的GFS主要負責快取、偵錯以及重傳等網路傳輸功能，而第二層則是屬於網路特定服務之部份，由這一層的Service Proxy負責該項服務的最佳化以及與GFS之溝通等相關事宜。最上層的應用程式，則主要是在使用者端接取各項網路服務，在伺服器端，則是現存於網路上的各項網路服務，由我們的系統，作適當的轉接。

在第二章，我們將針對現有之E-Mail電子郵件系統與FTP檔案傳輸系統作一個簡單的分析與比較。在第三章，我們會對整個系統架構作一個完整的說明。第四章及第五章則是實作的情形以及範例的展示。最後在第六章，我們將對整個系統作個結論。

第二章現有系統之功能回顧

2.1 電子郵件系統（E-Mail）

電子郵件系統的發展已經有十幾年的歷史，從1982年SMTP（Simple Mail Transfer Protocol）[15]正式成為RFC（Request for Comments）之後，UNIX上面的電子郵件系統一直是網際網路上最重要的服務。而隨著網路使用的日益普遍，電子郵件的角色，已從原來的「便利的工具」，升格為「關鍵性應用」了。它是企業資訊蒐集與傳播的骨幹，並且同時肩負著公司內外通訊的重要工作。電子郵件系統歷經了許多演進和改變，然而其基本的架構仍大致維持最初的設計。

在這一節，我們將針對網際網路上之電子郵件系統作一些歸納與分析，探討一般使用者讀取電子郵件的方式，並指出其優缺點以及可以改進的地方。而在下一章，我們將在所設計的架構上，建構一個新的電子郵件子系統，設法解決目前電子郵件系統所存在的問題，並以此來說明整個系統架構之可行性。

2.1.1 信件傳送的方式

目前網路上最普遍的電子郵件傳送協定是SMTP（Simple Mail Transfer Protocol，RFC 821），SMTP是定義網際網路上電子郵件流傳方式的一個通訊協定，它的最主要功能就是負責把電子郵件正確無誤而且有效率的送到目的地。同時，不論底層網路的連線方法為何，SMTP協定都可以用來傳送信件，只要有一個穩定的資料傳輸連線即可。

最常見的SMTP 伺服器就是UNIX上的sendmail，sendmail接受來自信件發送程式（如elm）的呼叫，並利用SMTP協定來將信件經由網際網路送到遠端的SMTP伺服器，遠端的SMTP伺服器再將信件存到檔案系統下使用者的信箱中。最後使用者就可藉由信件讀取程式從檔案系統中讀取信件。

SMTP的架構大致如下所示：

圖 2 SMTP傳輸架構

整個SMTP的架構以Client/Server方式分層運作，使用者可經由User Agent（elm）來發送信件，User Agent會呼叫Transport Agent（sendmail）來幫忙把信件送出去，Transport Agent同時會對信件作適當的relay和 queuing，直到把信件送到收信端的Transport Agent。

現有的SMTP伺服器大多使用TCP port 25，所有命令與回應均是使用一般的ASCII文字，傳送信件時，只要連上TCP port 25，利用幾個SMTP所提供的指令即可送信，一般的信件處理程式都是藉由這種與SMTP 伺服器直接溝通的方法來把信件送出去的。

下面是一個發送信件的簡單例子，假設在ccsun1.CSIE 上的cdsheen想送一封信給Java.CSIE這一台機器上的icwu，我們不經過信件處理程式，而直接使用SMTP把信件送到遠端機器Java.CSIE上面，下面是發送信件的流程：

cdsheen ccsun1 [~]% telnet java.csie.nctu.edu.tw 25

Trying 140.113.214.168 ...

Connected to java.csie.nctu.edu.tw.

Escape character is '^]'.

220 Java.csie.nctu.edu.tw ESMTP Sendmail 8.8.8/8.6.9 ready at Thu, 9 Apr 1998 15:23:25 +0800

MAIL FROM: cdsheen@csie.nctu.edu.tw

250 cdsheen@csie.nctu.edu.tw... Sender ok

RCPT TO: icwu@java.csie.nctu.edu.tw

250 icwu@java.csie.nctu.edu.tw... Recipient ok

DATA

354 Enter mail, end with "." on a line by itself

Subject: Hello!

hello,

It's a test for SMTP.

250 LAA29947 Message accepted for delivery

QUIT

221 Java.csie.nctu.edu.tw closing connection

Connection closed by foreign host.

cdsheen ccsun1 [~] %

在上面用虛線框起來的部份所送的是信件的內容，包含信件檔頭及真正的信件內容。關於信件內容的格式，如標題、時間等詳細的格式定義，在RFC 822（Standard format of ARPA internet text message）[3]中有詳細的說明。SMTP本身僅負責將信件送達目的地，並不知道信件的內容等資訊。

2.1.2 直接在郵件伺服器上讀取信件

在這一節與下一節，我們將探討幾種在使用者端讀信件的方式，並作一個分析與比較。在有網路直接連線、傳輸速度快的環境，大多數的使用者都選擇此種方式 ─ 先用遠端登入程式（如：telnet）進入遠端郵件伺服器系統，然後利用郵件處理程式（如elm）經由直接存取mail spool的方式來讀取並處理信件；而在送信方面，則是由郵件處理程式直接透過SMTP 伺服器來送出信件。

圖 3 在信件伺服器上讀取信件

使用這種方式讀取郵件的優點是，使用者對自己的信箱之處理較有彈性，可以對自己的信箱做各種功能的操作；另外信件之存放也易於集中管理。但是相對的，由於信件處理過程需要長時間的連線，所以缺點是需要較好的網路傳輸品質。同時在UNIX上的信件處理程式大多只是文字模式，除了缺乏較友善的介面外，若要用來讀取多媒體郵件，或其他非文字模式的信件時，也會有困難。

2.1.3 經由POP3/IMAP4協定來讀取遠端信件

在網路速度慢，或經由撥接伺服器甚至經由無線網路連線的環境，如果使用者只是想閱讀信件，則前述這種信件讀取方式似乎並不十分經濟，因為遠端登入與傳輸信件處理時的畫面等，會耗用許多額外的網路頻寬，而且維持信件處理時的連線也將十分昂貴。

因此，這類的使用者比較希望的是能直接在使用者端讀取與操作信件，與遠端郵件伺服器的通訊時間越少越好，這種讀取郵件方式最常用的有兩種，POP3（Post Office Protocol, RFC 1939）[11]與IMAP（Internet Message Access Protocol, RFC 2060）[2]，利用這兩種方式，可以把郵件伺服器上的信件先傳到使用者端，再由使用者慢慢閱讀並做處理。

一般而言，在個人電腦端使用POP3或IMAP的信件處理程式，功能大多比較偏重在應用方面，使用上也比較方便。對於多媒體信件的處理，以及與其他應用程式的整合性，也都是在伺服器上使用文字模式讀信程式所無法比擬的。

圖 4 經POP3/IMAP處理信件

POP3通訊協定十分簡單，但也因此使得功能受到限制。POP3只處理讀取遠端信件伺服器上信件的功能，對於送信的動作並未提供支援，送信還是要靠SMTP協定。

一般使用者使用個人電腦上的電子郵件處理程式（如Microsoft的Internet Mail、Outlook及Netscape Mail等）時，其所採用的讀信方式即是藉助於POP3 協定，而發送信件則是另外經由SMTP通訊協定（RFC 821），因此這些信件處理程式除了需要伺服器上有提供POP3服務外，同時也要能找到一台能幫忙藉由SMTP發送信件的伺服器。

想要POP3通訊協定讀取在郵件伺服器上的信件，首先必須給予伺服器認證所需要的帳號與密碼，之後使用者端即可向郵件伺服器取得一些簡單的信件資訊，像信件數目，及信件大小等，但是對於關於信件的更詳細資訊，例如發信者、標題等，在信件本體下載以前，使用者端的信件處理程式並無法知道。

下面是使用Microsoft的Outlook經由POP3讀取信件的情形：

圖 5 使用Outlook讀取信件

根據POP3 協定，使用者端雖然可以選擇下載第幾封信，但是由於事前無法得知信件詳細資訊，使得一般的信件處理程式都必須把所有的信件下載之後，才能由使用者選擇讀取哪一封。

圖 6 限制可下載信件大小

使用POP3的信件處理程式在信件真正下載前，僅能就下載的信件大小作限制，但是並無法依據信件的內容、來源等作更進一步的限制。

POP3在伺服器端一般跑在TCP port 110，所提供的命令十分簡單，數目約僅十種而已。下面是一個cdsheen經由POP3協定到Java.csie上面取信的例子：

cdsheen ccsun1 [~] % telnet Java.csie.nctu.edu.tw 110

Trying 140.113.214.168 ...

Connected to java.csie.nctu.edu.tw.

Escape character is '^]'.

+OK QPOP (version 2.2) at Java starting. <21897.894789997@Java>

USER cdsheen

+OK please send PASS command

PASS mypass

+OK 12 messages ready for cdsheen in /usr/spool/mail/cdsheen

LIST

+OK 3 messages; msg# and size (in octets) for undeleted messages:

1 943

2 773

3 773

RETR 2

QUIT

+OK Pop server at Java signing off.

cdsheen ccsun1 [~] %

使用者在取信之前，所能得到的資訊就只有上面框起來的部份，也就是只有信件數量與大小的資訊，使用者並不知該封信件的內容，直到把信件下載之後才知道標題與來源等資料。

藉由POP3由遠端收信方式的優點是，使用者可一次下載所有信件，而除了信件傳輸所需連線之外，並不會浪費額外的網路頻寬，同時使用者也不需為了要處理信件，而需要維持長時間而且穩定的連線。

但是這種方式也有一個缺點，就是信件的處理事實上是在 local 端進行，如果使用者經由不同的機器來讀取信件時，就有可能會導致信件處理上的不一致。另外，這種讀取信件方式大部分都是把信件全部下載，如果使用者只想讀取他喜歡的某一封信的話，此 POP3協定並未提供這種「選擇性讀取、下載」的功能。

另外，IMAP4則是一個比較聰明一點的協定，在如何擷取訊息方面，此協定給了你比POP3更多的選擇。你可以預先直接在伺服器端對信件作基本的檢查與剖析而不需要先行下載，接著，你可以選擇你真正需要的，即便只是訊息的一部份，仍然可以將剩餘的部分留在伺服器上；同時 IMAP4 也提供對遠端信件的基本操作（如：刪除、編輯、儲存等）功能。這些特性不只是方便而已，另外可以達到像是便於備份、訊息分享等好處。

雖然POP3和IMAP4在許多系統上同時存在，但是一般認為，IMAP4終將取代POP3（例如：Microsoft和Lotus在他們的訊息傳遞產品中，都已經支援POP3與IMAP4）。

IMAP4可以說解決了 POP3 無法「選擇性下載」的缺點，使用者閱讀信件時可以只傳輸特定的某一些信件（如新的信件），不需像 POP3 一樣必須把整個信箱重傳一次。但是對於快取及整合收發信功能上面，IMAP4並未直接提供支援；除此之外，對於網路不穩定的情形，例如有斷線的情況，IMAP4 也沒有提供一個足夠穩定的環境需求的解決方案。

比IMAP4更好的是ACAP（Application Configuration Access Protocol）[12]，它藉著讓你安裝位址簿、使用者選項以及其他與通用存取相關的資料，來增強IMAP4的功能。然而ACAP的規格仍然未經負責發展Internet標準的組織IETF（Internet Engineering Task Force）通過驗證，目前也還沒有支援的軟體出現。

2.1.4 信件處理方式比較

下面比較目前現有的各式 E-Mail 處理方式

u 登入到信件伺服器上，利用 elm 或 pine讀信

u 在使用者端利用支援 POP3 的信件處理程式讀信

u 在使用者端利用支援 IMAP4 的信件處理程式讀信

基本上，這三者的送信方式都是藉由 SMTP 協定，POP3、IMAP4 兩種協定只定義讀信的功能，因此下列比較主要針對讀信部份：

功能比較	在信件伺服器上利用 elm 讀信	遠端利用POP3來讀取信件	遠端利用IMAP4來讀取信件
處理系統以外的信箱	可	不可	可
信件管理	集中	分散	分散/集中
連線時間	長	短	長
信件處理方式	直接處理	下載閱讀	遠端處理
支援信件以外的服務	可	無	有
網路品質之容忍能力	低	低	低
快取功能	無	無	無
收送信整合	可	無	無
多媒體信件處理	難	可	可

大致來講，利用遠端簽入在信件伺服器上使用信件處理程式來處理信件，有集中處理的優點，若網路頻寬足夠的話，這種方式對於一般的信件處理是最恰當的。但是，對於多媒體信件的支援，以及與其他應用程式的整合性，相對來講，就比較弱一點。

POP3是目前使用數據機撥接網路的使用者比較常用的信件處理方式，在個人電腦端，有各式各樣的POP3信件處理程式可供選擇，他們的功能大多差不多，也都有一定的多媒體信件支援能力。但是受限於POP3本身協定的有限功能，比較難達到信件的集中管理功能，而且無法對信件作過濾，不管是否為垃圾信件，均需全部下載。

IMAP4能解決POP3的不足之處，它的信件處理可以是分散在使用者端，也可以集中在伺服器端，信件在下載之前，可以先經過適當的過濾，而且已讀過的信件也可以儲存在伺服器端，有利於信件的集中管理。IMAP4的缺點是，可能會對伺服器造成比較高的負荷，而且對於網路不穩定時的容忍能力，也有待考驗。

在我們的系統中，對於電子郵件的處理，主要是在定義完整的底層系統之上架構出能容忍網路傳輸不穩定的電子郵件系統，設法達到快取、預先下載、訊息保存等功能；同時參考IMAP4的作法，提供下載前過濾以及伺服器端信件儲存的服務。

2.2 檔案傳輸系統（FTP）之簡述與分析

檔案傳輸系統的起源可以溯源至1971年在M.I.T所建構的檔案傳輸功能（File Transfer Protocol），經過一二十年的演進，FTP已經成為網路上檔案資源分享的重要服務，由於其架構出快速及穩定的檔案傳輸功能，使得FTP變成網路上最便利的資源共享方法之一。

最新的FTP通訊協定為RFC 959 [14]，所定義的檔案傳輸是以TCP為基本的通訊管道，整個FTP的運作方式可用下圖來說明：

圖 7 FTP Transfer Model

首先，使用者藉由使用者介面對遠端的命令解譯器（protocol interpreter）發出命令，而所需要的資料檔案傳送（Data transfer），則經由另外一條連線傳送。FTP命令的連線一般是TCP port 21，而資料傳送連線則不一定。資料連線是雙向的，而且可由任一方開啟此連線（Passive/Active）。

所有命令FTP命令與回應均為一般的ASCII文字，利用這些命令，使用者可以取得身份認證、目錄索引、改變目錄、檔案上載、檔案下載等檔案傳輸服務基本功能。

這種資料傳送另外使用一個連線的作法，也使得FTP所能達到的功能更加具有彈性，例如下列這種檔案傳輸情形，使用者端既非檔案來源，也非檔案目的地，但是利用命令控制，能讓兩個遠端的FTP伺服器作檔案交換的動作。

圖 8 遠端控制兩FTP互傳資料

上述的整個FTP運作方式，基本上是沒什麼大問題，在區域網路，或者網路連線穩定的地方，這種檔案傳輸架構都能運作的很好。但是若是網路連線較慢或不穩定的狀況，FTP的Connection Oriented傳輸方式，就可能會遭受的一些困難。

圖 9 直接與間接傳送檔案

上圖表示出數據機撥接的使用者利用檔案傳輸服務來取得檔案的方法；傳統下載檔案必須直接與遠端FTP伺服器建立連線，但如上圖所示，若遠方伺服器在國外，則此連線就可能必須跨過兩段連線不穩定的地區，增加了傳輸的失敗機率。若利用在撥接伺服器上的代理伺服器當作中繼站，由其負責把檔案下載至檔案系統中，則對於撥接用用戶而言，所需跨過的就只有撥接所需的PPP連線而已。現有的WWW Proxy Server也大多支援FTP Proxy，但是角色大多定位在提供檔案快取的功能，對於間接連線代理的功能，就未能和應用程式作完整的互動。我們的系統，也希望能提供一個很簡單的介面，讓FTP能很快具有這種代理者功能。

2.3 現有系統之改進需求

對於現有電子郵件系統以及檔案傳輸系統的改進，事實上已經有各種方法出現，我們則是希望利用我們設計的底層基本架構，建構出現有的各項服務，同時也希望對E-Mail以及FTP兩項服務作一些改進，來進一步證明整個系統架構之可行性。

在電子郵件系統方面，我們建立一個完整，包含各種基本功能的郵件系統，並與現有系統作連結，希望達到的改進功能有下列幾項：

A. 整合收發信功能：同時支援類似 POP3 的收信功能，以及 SMTP 的送信功能，並將兩者整合做最佳化，並設法利用兩者的關係達成減低傳輸量的要求。

B. 快取（Caching）：利用底層的快取功能，使得上層的郵件處理完全能以透明化的方式達到快取的功能，也就是在閱讀已讀過的信件時，可以直接由快取中取得，不需經由網路再重傳一次。這邊牽涉到的議題還包括命名規則（naming）與一致性（consistency）的問題。

C. 行動計算環境之考量：包含預先下載、訊息過濾、訊息壓縮，以及網路不穩定時的容錯能力。同時在網路斷線並回復後，能自動重傳未傳完的部份，而不必全部重傳，而在網路斷線期間的動作，也可藉由訊息保存的能力，在連線恢復後，由系統自動完成。

D. 讓使用者能對遠端郵件作各種操作：所有信件的處理與保存均集中在伺服器上面，不論從何處上線查看信箱，均可以看到相同的處理環境。

在檔案傳輸系統方面，我們則主要在展示系統對於間接檔案傳輸架構的支援能力，利用一個簡單的介面，建構出基本的檔案傳輸下載能力。對於更複雜的功能，例如快取、續傳等，則尚未加入。

第三章系統架構

3.1 系統功能概述

本系統的最重要目的就是希望能建構出一個網路應用程式發展平台（framework），尤其是針對於網路傳輸品質的容忍，以及行動計算環境的種種需求，都能在系統中作適度的考量；讓各類網路應用，能很快的經由系統所提供的應用程式介面（API），來取得所需要的服務。綜合來講，我們的發展平台有下列幾項功能：

1. 網路連線轉化為檔案存取

所有原來對網路上的連線存取動作，在我們的系統中，都將之轉化為對檔案的存取，利用一致性的介面，提供整合性的網路傳輸服務。所有網路應用可以完全不管底層的網路系統運作情形，只需瞭解如何存取檔案即可。

2. 快取功能

底層檔案系統自動提供快取功能，已經存取過的檔案都會在使用者端的檔案系統中存一份快取，所以若檔案系統偵測到所存取的檔案已經讀取過了，會直接讀取快取中的檔案，不會再經由網路向遠端檔案系統要求相同的檔案。底層檔案系統同時會對快取的檔案是否更新過作檢查，使用者不用擔心拿到舊的檔案。

3. 訊息壓縮與偵錯功能

在底層檔案系統處理網路傳輸部分，所有的訊息都會經過壓縮，減少傳輸資料量；同時所有傳輸的訊息都會經過CRC 計算checksum，預防訊息在傳輸過程中發生錯誤。

4. 斷線處理與重傳

系統間的網路訊息傳輸，會自動偵測網路狀況，斷線時，訊息會被儲存起來；當連線重新接上時，訊息會被重新傳送出去。系統會確實保證訊息不會遺漏，完完整整的傳送到目的地。

5. 提供易於使用的應用程式介面

在底層的檔案系統之上，我們提供十分簡單而且易於使用的應用程式介面，讓各類網路服務能藉由呼叫這些系統提供的函數來取得系統所提供的種種功能，完全不需對網路的存取花費任何心力。

底層檔案系統所提供的功能，主要是把網路存取的部分隱藏起來，網路應用程式開發者只要知道如何對我們的系統作存取，如何撰寫可以掛到系統上面的服務代理者（Service Proxy），就可以很輕易的完成一個具有高效率網路存取功能的網路應用程式。

3.2 系統架構

由於本系統的目標是希望能支援各類的網路服務，而不是單單為了解決電子郵件系統而設計的。因此，在設計整個系統架構之時，特別把與特定網路服務無關的部份獨立出來，並讓電子郵件子系統以及檔案傳輸子系統，以類似附加模組的方式掛在我們的系統之上。

因此，整個系統部份實際分成兩層，最底下的一層是與特定服務無關的部份，在其上面則銜接著一層各類網路的子系統，而此兩層所組成的系統之上，則是真正與使用者接觸的應用程式與真正服務的連結，系統部分的架構如下圖所示：

圖 10 系統分層架構圖

圖 11 GFS系統架構圖

這樣的設計使得各式各樣的網路服務均可藉由模組化的方式來整合進系統當中；上圖主要是以電子郵件系統為例，另外也可藉由設計其他的網路服務的第二層部份（如FTP Proxy），來直接共用底層的系統。

事實上，與特定服務無關的部分事實上是一個虛擬的檔案系統，我們稱之為General File System，簡稱GFS。而在實際執行的時候，GFS之下則還有Java Virtual Machine、Native File System以及Operation System三層。

最底下三層是屬於系統執行環境部分，中間的兩層則是我們系統最主要核心所在，而最上層，則是與使用者直接溝通的應用程式部分。下面我們針對我們主系統的兩層架構作深入的說明，而在後面的章節中，我們也會對各層所負責的功能以及各層間的呼叫介面作詳細的剖析。

3.2.1 第一層 – 虛擬檔案系統 (GFS)

整個系統最底層的一層是屬於各項網路服務通用的部分，這一部份主要由一個虛擬檔案系統組成，此即GFS。GFS是一個整合各類網路服務的檔案系統；也就是說，本系統把所有服務所需要的網路通訊部分，都整合進檔案系統之中；所有資訊的傳輸與獲取，都轉為對檔案系統的存取，如此一來上層各個應用程式就只需要知道如何操作GFS檔案系統，即可得到所需要的網路服務。除此之外，GFS可以掌握網路的傳輸狀況，針對訊息的傳輸做適當的控制與保存。

圖 12 GFS系統功能示意

快取（caching）主要是藉由類似Andrew File System的觀念配合上層網路服務所提供的訊息命名規則來完成，目的是為了提供一個完全自動化的快取功能，讓所有的網路服務都能很容易享受到快取的優點。

上圖的Message Queue主要是為了解決某些環境下（如：行動計算）網路不穩定的問題。當網路斷線或不穩定時，此Message Queue的作用就是把上層的訊息指令以批次方式儲存下來，等到連線恢復後，再將所有未送出的訊息自動送出，完全不需上層的網路服務或應用程式操心。甚至即使程式或電腦當掉了，這些訊息也會被以儲存在硬碟（persistent）的方式，保留下來，下次重新啟動時，所有未送出的訊息也照樣不會遺漏。

GFS除了負責檔案處理與快取之外，還可負責傳送上層layer之間的通訊協定或特殊訊息，在GFS之間，這些訊息和檔案的傳輸一樣，會被放進Message Queue中保存，確保資料正確傳送到目的地。

以電子郵件系統為例，GFS的快取功能主要就是把已讀過的信件以檔案的形式儲存下來，則以後若有要讀同樣的信件時，就可以不必再經由網路傳送一次。另外就是當傳送信件或處理信件時，若網路斷掉甚至或機器當掉，則GFS會負責把已做過的動作保存在硬碟中，直到動作完成為止。同時，GFS系統還負責轉送上層E-Mail系統之間相互溝通的命令。

底層的GFS系統事實上並不曉得它所處理的是哪一種網路服務，GFS系統本身只認得檔名，而此檔名是由上層layer（如E-Mail或FTP）指定的。對於電子郵件系統之間的通訊協定，GFS只負責轉送這些訊息，並不負責處理其內容。

綜合上面所述，GFS是一個「與網路服務無關」的底層系統，其上面可以銜接各式各樣的網路服務，同時GFS並提供了基本的網路傳輸控制，例如快取和重傳等功能。

3.2.2 第二層 – 特定網路服務代理者 (Service Proxy)

連接在GFS上面的是針對各項網路服務作特殊處理的部份，各項服務依據其性質，製作出適合特定網路環境（如：行動計算）的網路服務代理者（Service Proxy）。除此之外，此層還需負責提供該項網路服務的資訊命名規則給GFS，以便GFS利用此命名規則來作適當的快取處理與訊息保存。

圖 13 特定服務與GFS之連接

以電子郵件系統為例，這個Service Proxy部份就稱為E-Mail Proxy﹐主要在提供應用程式讀信和送信的功能，並且知道如何經由SMTP伺服器來送信以及如何到郵件伺服器上取信。

Service Proxy分為client與server兩種：以此電子郵件系統為例，在client端有Mail Client Proxy，在server端有Mail Server Proxy；Mail Client Proxy負責接收來自使用者端的應用程式各種信件處理要求，而Mail Server Proxy則負責代為取信與送信。

對於GFS而言，E-Mail Proxy所扮演的角色就是提供所有信件等訊息一個特定的命名規則，GFS才可以由此naming來向遠方GFS提出讀取檔案的要求，同時對檔案存取作快取處理。此命名規則是由該項網路服務提供者所自行定義，對於成對的Server Proxy與Client Proxy，兩者必須遵守一樣的命名規則，這樣網路服務才可以得到正確的資訊。

3.3 電子郵件子系統

在一個網路不穩定的環境中，GFS所能提供最有用的功能就是快取。在本系統中，我們以電子郵件（E-Mail）子系統來展示GFS系統所具有的快取功能，我們設法利用GFS的快取功能來改良目前廣泛使用的POP3所存在的一些問題，使之能善用快取的功能來達到降低網路傳輸頻率的效果。

同時，針對現有的電子郵件系統，我們由前一章的分析中，知道POP3最重要的一個缺點是無法預先對電子郵件的內容作分析，讓使用者自行選擇想要觀看的信件；使用者必須下載全部的信件內容，才能得知所要觀看的信件資訊。同時，由於POP3通訊協定先天上的限制，使得快取的功能很難達成。因此，電子郵件子系統配合底層GFS快取功能的運作，最主要有下列兩大改進：

1. 使用者可以預先得知信箱中所有信件的資訊，而不必先行下載信件本體。使用者對於有興趣的信件，可以選擇性下傳；而不必像POP3一樣需全部下傳。

2. 使用者已經閱讀過的信件或標題，在使用者下次要求同樣的內容時，可直接由存在於使用者端的快取中取得，而不需經由網路再重傳一次，GFS會自動檢查該檔案是否更新過。

GFS系統下的快取運作過程約如下圖所示：

圖 14 GFS系統的快取功能

快取功能主要是由我們系統中的兩層layer之間互相配合來達成。底層的GFS負責快取物件的儲存，同時會判別所要求的物件是否已經存在快取之中，以及被快取的物件內容是否與伺服器端物件同步，上一層的網路服務只需下一個檔案讀取指令，即會引發GFS一連串判斷快取物件的程序。

在本系統中，我們利用上層的Service Proxy來提供各類資訊的命名規則（naming），底層系統則利用此naming來儲存或尋找快取中的內容，而底層系統並不知道它所處理的檔案內容的是什麼。

舉例來說，假設某資訊（例如一封信）被Mail Proxy取名為「foo」，則當使用者要求取得此資訊時，Mail Proxy就直接把存取「foo」的要求向底層的GFS提出。

底層的GFS接到存取此檔案的要求後，會先看看快取中是否存在「foo」這個檔案，若無則把此存取要求轉送給遠端的GFS，使用者端的GFS在取得檔案後，即會在GFS中存放一份，然後再把資訊往上傳給Mail Proxy。若快取中已經存在此檔案，則為了資訊的同步，GFS還會幫忙檢查使用者端快取的資料是否過期了，若過期了，GFS會自動幫忙更新。Mail Proxy同時可以根據需要選擇要不要GFS作這項檢查。

在遠端的GFS部分，接收到檔案存取的要求後，會先判斷此檔案是由那個Service Proxy負責的，例如：Mail Proxy，然後將存取要求轉為向Mail Proxy提出，Mail Proxy需根據自己定的命名規則，負責將此檔案代表的資訊傳回給GFS，讓GFS把檔案傳回給使用者端。例如此時的Mail Proxy接收到存取「foo」檔案的要求，就需負責把代表該檔案的信件內容傳回給GFS。

3.4 網路傳輸的批次處理與偵錯能力

在網路不穩定的環境中，另一個重要的議題就是如何使得所有的通訊傳輸都能正確無誤的完成，不會受網路是否順暢的影響，這就是本系統所強調的網路錯誤容忍（fault-tolerant）能力。在本系統中，錯誤更正的功能完全由底層的GFS來達成，上層的命令或動作均會由下層的GFS作適當的保存，直到通訊正確無誤的完成為止。

GFS作訊息保存的方式是把上層的命令以批次（batch）方式放在佇列（queue）之中，在網路順暢時，伺機送出。如此一來，不但避免因網路斷線造成資料流失，同時也可以減低client與server間網路傳輸的頻率，有效提昇網路的使用率。

圖 15 GFS訊息傳輸架構

如上圖所示，GFS對於必須轉送到遠端的訊息或資料，都會先放置到一個佇列（queue）中，而此佇列則會自動存放一份在永久性的儲存媒體（如硬碟）上（persistent storage），所以即使因誤觸電源開關而關機或因系統當機而重新啟動，此佇列仍然存在不會消失，如此一來，提供了使用者一個訊息傳輸的絕對保證；使用者不必擔心資料會因系統或網路不穩而流失。

在訊息傳送至目的地後，遠端GFS同時會對此訊息封包作CRC的檢查，看看傳輸過程是否錯誤。只有當訊息被遠端GFS正確無誤的接收，使用者端的GFS接受到來自遠端GFS的ACK訊息後，才會將該訊息自佇列中刪除（dequeue），否則訊息還會被傳送一次，直到成功為止。

同時，所有傳輸的訊息，都會經過壓縮，有效降低傳輸所需資料量。以電子郵件子系統為例，由於傳輸的資料多為文字型態資料，可壓縮率極高，經過壓縮後的傳輸量大約可減少50%以上。

對於GFS而言，所處理的工作就是確保訊息正確且快速的傳送到目的地，也就是把網路傳輸部分完全對上層的網路服務隱藏起來，由GFS完全掌控。另外，前一節所述檔案系統的快取部分，也是GFS的功能之一。

3.5 檔案傳輸子系統（FTP Proxy）

除了前述的電子郵件子系統之外，我們也在GFS上面另外架設一個檔案傳輸子系統（FTP Service Proxy）。架設這一個子系統的目的有兩個：一是展示GFS平台之可擴充性，二是說明分層架構的高度彈性。

我們的檔案傳輸子系統目前仍未具有傳統FTP所有的功能，然而其最主要的改進是增加FTP系統的代理傳輸能力（proxy-ftp），希望能為網路傳輸不穩的地區，提供有效率的檔案下載功能。

如同我們在第二章中的說明，在某些網路狀況之下，檔案傳輸常常會因為跨過許多段網路而造成極高的不穩定性。因此，採用間接式的網路傳輸（Indirect FTP），讓使用者能順利的下載所需的檔案就成為解決這個問題的最好方式。而藉由我們底層GFS系統所提供的彈性，我們很輕易的可以針對間接式傳輸設計出一個真正可以實際運用的FTP系統。

圖 16 間接檔案傳輸架構

如同電子郵件子系統一樣，檔案傳輸子系統分為FTP Client Proxy、FTP Server Proxy兩部分，同時我們也設計了一個簡單的FTP應用程式使用者介面，來真正控制FTP的運作。

使用者可以要求遠端FTP Server Proxy代為連接哪一台FTP伺服器，之後在使用者端所看到、所感覺到的檔案傳輸情況都會跟使用一般的FTP程式一樣。而事實上，所有使用者的檔案傳輸要求，FTP Server Proxy都會代為轉為向所指定的FTP伺服器提出相同的要求，檔案的傳輸會先下載到遠端GFS的檔案系統中，再傳回使用者端的GFS系統之中，最後再由FTP Client Proxy把檔案傳回給應用程式端。

我們利用系統所提供的命名規則，以類似AFS的方式，告訴遠端的FTP Server Proxy所需要的檔案位置，由遠端的FTP Server Proxy代為取得所需要的檔案。在這之中，GFS同樣已經代為處理掉大部分的網路傳輸問題，同時對於檔案的快取以及錯誤更正等問題，也都提供了完整的解決方法。

在撰寫FTP網路傳輸服務之時，只要透過系統所提供的應用程式介面（API），套用既有的程式框架，就能很快的設計出一個具有高效率與高度網路傳輸容忍能力的應用程式。

第四章實作

4.1 系統實作環境

系統主要的實作環境如下

伺服器部分 Solaris 2.6, SUN JDK 1.1.6

客戶端部分 Microsoft Windows 95, SUN JDK 1.1.6

伺服器部分由於目前大部分的信件伺服器都以UNIX為主，因此為了能使本系統中的電子郵件子系統能正常運作，因此伺服器必須建置在UNIX的機器上，另外也由於系統許多功能上的需要，Java必須使用JDK 1.1 [22]以上的版本。因此我們選定的程式發展環境就由Solaris搭配Windows 95作為Server/Client的作業平台。

本系統亦曾經於Solaris/Solaris與Linux/Win95的Server/Client環境測試無誤，所使用的Java亦均為JDK 1.1以上的版本，Solaris的client環境必須在X-window下使用。

在使用Java開發本系統時，所使用到比較特別的JDK API主要包含下列幾個重點，有一些是屬於JDK 1.1所獨有的部分：

1. Object Serialization

主要是用在GFS之間訊息的傳輸，以及利用此機制將暫時未能傳輸出去的訊息儲存在硬碟中。

2. Compression API

藉助於JDK 1.1所提供的Compression API，系統可以很輕易的對訊息之傳遞做壓縮，有效降低傳輸量。

3. CRC Checking

系統使用JDK 1.1的CRC32 checksum來確保傳輸的資料能正確傳輸到目的地。

4. AWT delegation model

在應用程式端，我們使用AWT 1.1的delegation event model，使得程式畫面部分易於設計，同時增強其執行效率。

4.2 程式架構說明

電子郵件子系統方面，程式總共分為四大部分，GFS、Mail Client Proxy、Mail Server Proxy以及應用程式端的Mail Explorer。另外檔案傳輸子系統方面，則有FTP Server Proxy、FTP Client Proxy以及其應用程式端使用者介面Proxy FTP。

GFS為系統最主要的底層架構，負責大部分的網路傳輸工作；在系統啟動之初，GFS會為每一項網路服務分別開一個執行緒（Thread），包含Mail Client/Server Proxy以及FTP Client/Server Proxy。

Mail Server Proxy則負責真正對mail spool與使用者自己的信箱作動作，Mail Client Proxy則負責接受Mail Explorer的連線要求，一般使用者看到的就是這個Mail Explorer介面。下面分段詳細介紹各部分：

A. GFS

GFS可視作一個底層的網路檔案系統，應用程式可將原先的許多必須經由網路傳輸的要求轉化成對GFS檔案的存取，由GFS代為處理網路傳輸部分，同時GFS會對這些檔案做適當的快取以及維護快取的一致性；另外，GFS也可代上層的網路服務傳遞訊息。

而GFS與GFS之間這些經由網路傳遞的訊息，都會由GFS的佇列機制確保訊息不會遺失，同時對於尚未處理的訊息，也會儲存於硬碟之中，直到訊息被處理完為止。

GFS系統在初始化之時，會同時啟動掛在其上的各個網路服務，例如Mail Proxy與FTP Proxy，並開始接受proxy對GFS的呼叫以及遠方GFS的連接。GFS會在所指定的目錄下維護一份「General File System」，此虛擬檔案系統除了提供上層網路服務置放相關的檔案以及快取之外，也是系統未送出訊息永久儲存的地方。

B. Mail Server Proxy

Mail Server Proxy 負責取信與送信的真正動作；取信時直接自mail spool中存取，送信時直接經由SMTP通訊協定與信件伺服器溝通。Mail Server Proxy主要是接受GFS的呼叫，處理遠端Mail Client Proxy對GFS的存取動作。

C. Mail Client Proxy

Mail Client Proxy負責接收與處理應用程式（Mail Explorer）的訊息與命令，並將之轉化為對GFS檔案系統的存取，在取得所需要的訊息後，再傳回給應用程式端。

D. Mail Explorer

Mail Explorer是使用者接取及發送信件的GUI介面，Mail Explorer經由我們所定義的一套Mobile Mail Protocol （後詳述）對位於使用者端的Mail Client Proxy發送所需要的命令。

GFS的執行畫面如下所示：

圖 17 GFS執行畫面

啟動GFS需指定一個目錄來當作GFS的虛擬檔案系統，上圖的例子是file-system/ 子目錄，在GFS啟動之後，會開啟各類Service Proxy，例如Mail及FTP Proxy，同時開始接受遠端GFS的連接以及上層網路服務的呼叫。

4.3 GFS之檔案存取功能

如前所述，GFS為一虛擬的檔案系統，目前提供上層網路服務一些基本的檔案存取與訊息發送的功能，GFS所提供的函數所接受的檔名均為在GFS系統中的檔名，並不是真正作業系統接受的檔名。目前GFS僅提供六大功能供Service Proxy呼叫之用，包含如下：

1. gfsFile()

此函數用以取得GFS系統中某一檔案的資訊。

2. gfsRead()

此函數用以讀取GFS系統中的檔案。

¨ 如果該檔案在客戶端已存在，則直接將該檔開啟後回傳。

¨ 如果該檔案屬於遠端所有，則有兩種選擇：

a. 不需驗證快取是否最新

此時若快取中已有該檔案存在，則直接開啟回傳。

若不存在，則再向遠端GFS提出要求。

b. 驗證快取之正確與否

此時會向遠端的GFS驗證此檔是否有更新過，若有更新，則將新的檔案傳回，若未更新，則將快取中的檔案直接傳回給上層proxy。

3. gfsWrite()

此函數用以開啟GFS系統中的檔案供寫入之用。

此函數傳回OutputStream，在寫入完成後需自行將其關閉，至於寫入該檔的用意為何，此函數並不作處理。

4. gfsSave()

此函數用以將GFS系統中的一個新檔案資訊告知遠方的GFS，該檔案可能是經由gfsWrite() 寫入GFS中的。例如在本系統的Mail Client Proxy，即是利用此函數來通知遠端的Mail Server Proxy有新信件要送出去。

5. gfsFetch()

此函數的動作略同於gfsRead()，但此函數會立即return，讀取檔案的動作會放在背景處理。此函數的最主要用途是提供行動計算環境下，在離線前，告知系統預先下載某些將來可能會讀取的檔案之用。

6. sendMessage()

此函數可提供上層的網路服務發送訊息之用，發送訊息的格式可由上層網路服務自定，GFS僅將之視為一個物件，利用JDK 1.1所提供的Object Serialization將訊息傳遞出去傳遞出去。

上面這些函數主要大多由客戶端的proxy呼叫使用，由client proxy藉由呼叫使用適當的函數來取得所需要的網路服務。

而這些命令要求均會反應到伺服器端的server proxy，遠端的GFS會藉由呼叫server proxy的三個call back function，來達成client proxy所要求的動作。因此server proxy必須要實作（implement）下列三個abstract function：

1. refresh_file()

此函數是由GFS詢問server proxy某個檔案是否需要更新，若需更新，則由server proxy負責更新檔案系統中的檔案；若不需更新，則直接回傳檔案目前狀態。

此函數的作用是在server端對於client端的gfsRead()、gfsFetch() 等呼叫，提供正確的檔案資訊。例如在電子郵件子系統中，讀取信件列表、讀取信件等功能，均是藉由呼叫mail server proxy此函數來取得需要的資訊。

2. notify_file()

此函數是由GFS通知server proxy，遠端的GFS已儲存一個檔案到GFS檔案系統之中，server proxy可在此函數中做相對應的動作。

此函數作用是在伺服器端對於客戶端的gfsSave() 呼叫，針對該項網路服務性質做出相對應的動作。例如在本系統中的mail client proxy會把送出的信件先存到GFS中，再通知遠端的mail server proxy有新的檔案存入GFS，然後由遠端的proxy將信件藉由SMTP真正將信件送出。

3. notify_msg()

此函數是由GFS通知server proxy，遠方的client proxy藉由GFS送達一個訊息物件。該訊息物件格式由client proxy與server proxy共同決定，因此server proxy即可根據該訊息物件內容執行其預先與client proxy協定好的動作。

此函數目的是在伺服器端對於客戶端的sendMessage()呼叫做出適當的反應。例如在本系統中，mail client proxy要求建立新的信件夾、刪除某封信、以及儲存信件的動作，都是藉由訊息物件向遠端的mail server proxy提出要求的。

因此，為了讓每一個server proxy都能對client proxy的呼叫作出反應，Server Proxy必須繼承下列的類別，同時override三個函數：

abstract public class ServerProxy extends Proxy {

abstract public FileStatus refresh_file( String filename );

abstract public boolean notify_file( String filename );

abstract public Object notify_msg( Object msg );

}

上述的所有函數之中，我們也有提供一個選項，可以為所想要讀取的檔案加上密碼管制，例如我們的檔案傳輸子系統就是利用這個方法來對使用者的身份作認證，來取得登入至遠端系統的權利。

圖 18 Service Proxy與GFS之間的介面

4.4 GFS之訊息傳遞功能

GFS與GFS之間的通訊，均是以一個一個的 ”Message Block” 為單位，Message Block可傳送GFS之間的所有命令要求、各類檔案、及訊息等。GFS傳遞Message Block的方式是採用JDK 1.1提供的Object Serialization將之以Object方式直接透過網路資料流傳送。

對於不需即時送出，或者因網路問題，暫時無法送出的Message Block，均會被儲存在硬碟當中（persistent）。對於收到來自遠端GFS的 Message Block，尚未處理的部分也同樣會被保存於硬碟之中。

這些未成功送出或未處理的Message Block會由系統定時檢查是否已可處理，若系統當掉，在系統重新啟動時，也會將硬碟中尚未完成的指令讀入，直到處理完所有訊息為止。

在GFS間傳遞的Message Block，均會利用CRC32 checksum作錯誤檢查，同時互相作確認（acknowledgement），確保訊息正確無誤的送到對方。而傳送訊息時，GFS也會設法依據原來發送的順序處理，以維持訊息傳輸的先後關係。

如果傳送的是一個檔案，GFS同時會對該檔案作壓縮，減低傳輸的訊息量後再送出。一般而言，壓縮的動作可以大幅降低通訊量至50%左右。

對於檔案的讀取動作，GFS會自動確認快取中的資料是否需要更新，非必要不浪費額外的網路頻寬。同時由於各個系統的時間可能不是同步的，因此如何判斷檔案是否更新變得很麻煩。因此，GFS會在客戶端的檔案系統中的每一個目錄，儲存一個檔案 .dir 紀錄該目錄下檔案於伺服器上的Last Modified Time，GFS即會藉此記錄來與伺服器共同檢視檔案是否更新，進而來達到時間同步（Time synchronization）的需求。

4.5 Mail Client Proxy與應用程式間的介面

在應用程式與Mail Client Proxy 之間的介面部分由於需要考慮特殊網路環境（如mobile）的特性，以作更有效率的存取，因此直接使用舊有的POP3 protocol並不適合，因此在這部分，我們設計了一個簡單的通訊介面，用以對特殊網路環境有更佳的適應力，同時也針對POP3沒有考慮到的送信部分提供支援。

此通訊協定在本系統中稱之為Mobile Mail Protocol，使用的TCP port為 5510。在此通訊協定中，client proxy為被動的等待來自應用程式的連線請求。由於應用程式與client proxy 均在同一台機器上，因此兩者之間的連線可能會一直維持。

命令與回應之訊息格式均為以 \r \n 結尾之 ASCII 字串

在應用程式端得到的回應是以一個 3 位數的數字代碼為首，代碼的意義採用類似SMTP/NNTP [6]的分類如下：

1xx - 訊息資料

2xx - 指令正確

3xx - 指令尚未完成，需繼續傳送其它資料

4xx - 指令正確，但因某些原因而無效

5xx - 指令未提供、錯誤或是嚴重的程式錯誤發生

6xx - 指令正確，但資料可能錯誤

x0x - 未通過身份確認，連線正常

x1x - 已通過身份確認，連線正常

x2x - 連線將要切斷

xx0 - 僅有一行回應

xx1 - 後尚有一行之回應

xx2 - 後有多行回應，以 '.' 一行結束

在此代碼後會跟隨著一些文字資訊，依回應的狀態而有所不同。

命令部份，則以 POP3 為基礎，並在考量特殊網路環境下，作一些擴充。當命令或回應需要多行的訊息時，則以僅有一個 . 之一行作為訊息之結束。首先當應用程式連接上Mail Client Proxy時（TCP port 5510），proxy會回應下列連接正確的訊息：

100 java.csie.nctu.edu.tw E-Mail Proxy Ready

接下來，分為兩個階段，首先必須通過身份確認，此為認證階段（authentication phase），接下來就可以作各類的讀信、取信等動作，即動作階段（communication phase）。以下，我們就針對這兩個階段的各種命令作一些說明。

Authentication Phase

<命令> SERV [hostname]

<功用> 選擇 Mail server，告知proxy代為連接哪台的mail server

<回應> 200 set mail server to [hostname]

<命令> AUTH [username] [password]

<功用> 進行身份確認

<回應> 210 [username] login on [hostname]

Communication Phase

<命令> INDEX

<功用> 取得所有信箱列表

<回應> 212 mailboxes follows

<回應> inbox

<回應> outbox

<回應> .

<命令> SELECT [mail-box]

<功用> 指定作用的信箱

<回應> 210 [mail-box] selected.

<命令> LIST

<功用> 列出信箱中之信件資訊

<回應> 212 mails in [mail-box] follows.

<回應> C msg-id date email-from email-to lines size subject

<回應> .

（經由LIST命令回應給應用程式的資訊包括下列八項）

1. 此封信是否有快取之存在（C / U）

2. 此封信的代號

3. 此封信的日期

4. 寄信者的E-Mail address

5. 收信者的E-Mail address

6. 信件行數

7. 信件大小

8. 信件標題

<命令> RETR [msg-id]

<功用> 取得信件

<回應> 212 content of [msg-id] in [mail-box] follows

<回應> <RFC 822 mail content>

<回應> .

<命令> PREFETCH

<功用> 預先取得信件

<回應> 310 send the msgid to be prefetched, ends with '.'

<命令> msg-id-1

<命令> msg-id-2

<命令> .

<回應> 210 total 2 prefetch requests sent.

<命令> DEL [msg-id]

<功用> 刪除信件

<回應> 210 [msg-id] deleted in [mail-box]

<命令> SEND [email-addr]

<功用> 送出信件

<回應> 310 send your message in RFC 822 format

<命令> <RFC 822 mail content>

<命令> .

<回應> 210 message sending.

<命令> SAVE [msg-id] [mail-box]

<功用> 存入信件

<回應> 210 saved [msg-id] in [mail-box] into [mail-box]

<命令> NEW [folder-name]

<功用> 新增信件夾(信箱)

<回應> 210 [folder-name] created

<命令> HELP

<功用> 取得命令說明

<回應> 212 useful commands follows

<回應> <help message>

<回應> .

<命令> QUIT

<功用> 結束連線

<回應> 120 Bye!

以上所述的Mobile Mail Protocol整理如下：

◎ Authentication phase

SERV [hostname] select a mail server

AUTH [username] [passwd] authentication phase login

◎ Communication phase

INDEX list mailboxes in this account

SELECT [mailbox] select an active mailbox

LIST information of the mails in mailbox

RETR [msg-id] retrieve the mail with msg-id

DEL [msg-id] delete the mail with msg-id

SEND [email-addr] send the mail to an email address

SAVE [msg-id] [mail-box] save the mail in mailbox

NEW [folder] create a new mail folder

PREFETCH prefetch mails

HELP available commands

QUIT say goodbye

簡言之，我們所設計的郵件傳輸協定比傳統的POP3 加強了幾個功能：

1. 多重信箱處理功能 (INDEX, SELECT)

2. 更詳細的信件資訊 (LIST)

3. 送信功能 (SEND)

4. 預先下載功能 (PREFETCH)

5. 在伺服器上的信件處理 (SAVE, NEW, DEL)

4.6 Mail Proxy之檔案命名規則

Mail Client Proxy在接到Mail Explorer的請求之後，必須將之轉化為對GFS檔案系統的存取。因此，在這個地方，適當的命名規則就變成一個很重要的課題；在這一小節，我們將針對郵件服務在檔案系統中的命名方式做一些定義。

首先，在談到Mail Proxy的命名方式之前，先來看看GFS本身內定的命名規則：

/ IP-Address / service /

所有proxy service在GFS系統內的檔案都必須位於上述規定的命名目錄之下，IP-Address表示伺服器端的位址，而service表示該proxy的名字（如”mail”或”ftp”）。

在此目錄下的所有檔案均為該proxy service所擁有，其下檔案的命名方式也由proxy service自訂，GFS只認得上述這前兩層的目錄，而其後的目錄則交由該項proxy處理。

接下來，針對Mail Proxy的命名規則，定義如下：

使用者的目錄 / IP-Address / mail / username /

使用者的信箱列表 / IP-Address / mail / username / index

使用者的inbox信箱 / IP-Address / mail / username / inbox /

使用者inbox信箱之資訊 / IP-Address / mail / username / inbox / index

使用者inbox信箱內的信件 / IP-Address / mail / username / inbox / msgid

使用者的outbox信箱 / IP-Address / mail / username / outbox /

使用者outbox信箱之資訊 / IP-Address / mail / username / outbox / index

使用者outbox信箱內的信件 / IP-Address / mail / username / outbox / msgid

因此，Mail Client Proxy會將所有送信、讀信的動作依據上述的命名方式，轉成對GFS系統的檔案存取動作，然後由GFS將此存取動作告知遠端的GFS。

遠端的GFS收到此訊息後，再轉知Mail Server Proxy；Mail Server Proxy也是根據上述同樣的命名規則，提供適當的檔案資訊給GFS。之後再循同樣路徑將所需要的訊息傳回使用者端。下面是一個在客戶端的GFS檔案系統的大概架構：

圖 19 郵件子系統目錄架構

如上圖所示，使用者cdsheen的inbox信箱內，每一封讀過的信件，都會以msgid當作檔名，存放一份在快取檔案系統之中。而這些檔案由於都在mail的目錄之下，所以一切動作都會由GFS詢問Mail Proxy如何對存取該檔案的請求作出適當的回應。

使用者可以使用多個GFS上的信箱，這時儘管使用者帳號名稱一樣，也不會產生混淆，因為檔案是以GFS的IP Address來當作為最上層的目錄名稱。

4.7 FTP Proxy之檔案命名規則

對於檔案傳輸子系統而言，命名規則主要是增加了間接傳輸的功能，讓FTP Proxy可代為連接所指定的FTP伺服器。在我們的實作中，我們將檔案命名為下列形式：

/ IP-Address / ftp / FTP-Address / username /

第一個IP-Address表示遠端GFS的位置，也就是FTP代理伺服器（FTP Server Proxy）所在的位址。接下來的「ftp」則是表示檔案傳輸子系統。FTP-Address則是要求FTP Proxy代為連接的真正FTP站位址。最後的username則是登入該FTP 伺服器所用的使用者名稱。至於密碼，則會經由參數設定，在使用者端讀取檔案時傳入。

/ 140.113.209.112 / ftp / 140.113.214.168 / cdsheen / hello.c

例如上面這個命名即表示，由在140.113.209.112上面的FTP Server Proxy代為連接140.113.214.168上的FTP Service，同時使用cdsheen登入該系統，並在其目錄下找到一個名稱為hello.c的檔案。至於登入密碼，則在呼叫gfsRead() 時，由FTP Client Proxy指定。

另外，對於每個目錄下的目錄列表，我們將之命名為 .index。因此整個檔案傳輸子系統的目錄架構就像下面這個例子一樣：

圖 20 檔案傳輸子系統目錄架構

第五章成果

5.1 系統流程說明

在這一節，我們以電子郵件子系統為例，詳述其運作流程，同時模擬特殊的網路狀況，說明系統所能提供的功能支援。電子郵件子系統同時針對電子郵件系統本身作了一些改進，首先，我們先來回顧一下使用者讀信的兩個最常用的方法：

1. 使用者利用telnet登入信件伺服器，並在上面讀信、處理信件、及發送信件，由於這些動作均要在伺服器上完成，因此需要維持長時間的連線，網路品質上的要求自然較高。

2. 使用者利用POP3把信件下載下來，利用SMTP直接送信。這種方式由於把信件全部下再了，因此如果甲只想閱讀乙的信件，POP3並未提供此種選擇性讀取功能。同時收發信的動作也同樣易於因網路問題而中斷。

很顯然的，這兩種方式所提供的功能並不足以在網路速度慢或行動計算環境下對網路的傳輸作更有效率的應用。

因此，在我們的電子郵件子系統，希望能針對網路的有限頻寬作更有效的利用，以及能針對POP3通訊協定所存在的問題作一些改進。我們利用下面這個簡單的例子，簡單概述系統如何藉由Mail Proxy與GFS的配合，來達到提高網路傳輸效率的要求：

假設某人在信件伺服器上有下列幾個信箱：

INBOX	接收的信件
OUTBOX	所發送的信件
Friend	好友的信
Boss	老闆的信

下面我們來模擬一些狀況，並考慮使用者可能的行為，來看看電子郵件子系統所採取的相對應動作：

1. 打開 INBOX 信箱﹐瀏覽信箱狀態

此時系統會顯示 INBOX 的狀態，包括寄信者、寄信時間、信件大小、信件標題，以及此封信是否在客戶端有快取（標示為C）。

		寄信者	寄信時間	信件大小	信件標題
C	1	A	6/1	650 bytes	Hello, 好久不見
	2	B	6/2	5.7 Kbytes	[廣告] 電腦周邊特價大優惠
C	3	A	6/2	4.5 Kbytes	Re: Hello, 好久不見
	4	C	6/3	820 bytes	請問….
	5	D	6/5	560 bytes	Homework!