為了磋商會議控制和用遠程終端轉移文件, uucico 使用一套統一的信息。這經常被參考作為高級的協議。
在初始化階段和掛斷階段期間,這些簡單地作為字符串被發送到對面。然而,在真正的轉移階段期間,一個
附加的低級的協議被雇用,它對高水平協議大部分是透明的。當使用不可靠的行時,這是使誤差檢查成為
可能,例如。
--------------------------------------------------------------------------------
協議概述
當 UUCP 使用不同連接的類型時,例如連續的行或 TCP ,或甚至 X.25 ,特定的低級的協議被需求。
另外, UUCP 的若幹實現介紹了粗略地做一樣的事情的不同的協議。
協議能被劃分成兩個范疇:流水般的和包裹導向的協議。面一種協議總的來說轉移一個文件,可能在它
上面計算檢查和。這幾乎是自由的,但是要求一個可靠的連接,因為任何錯誤將導致全部的文件被重新
發送。這些協議通常在 TCP 連接上被使用,但是不適用在電話線上的使用。盡管現代的調制解調器
在錯誤修正時做相當好的一個工作,他們不是完美的,在那裡也一樣沒有在你的計算機和調制解調器之
間的任何錯誤探測。
另一方面,包裹協議把文件分開成相等大小的若幹塊文件。每個包獨立被發送和收到,檢查和被計算,
並且致謝被返回到發送者。為了使這更有效,滑動窗戶協議被發明,它承認一個突出的有限的數字(一扇窗戶)
在任何時間的確認 。這極大地減少 uucico 在發送期間等待的時間的數量。盡管如此,與一個流水般的協
議相比的相對大的開銷使在 TCP 上使用包裹協議低效。
數據路徑的寬度也有差別。有時,在一個連續的連接上發送8小點字符是不可能的,例如如果連接通過一個
愚蠢的終端服務器。在這種情況中,有 第8 個位集合的字符必須在發送上被引用。當你在一個7小點連接
上發送8小點字符時,他們必須在最糟情況的假設之下,這使得被發送的數據的數量加倍,盡管硬件做的壓縮
可以為此補償。能發送任意的8小點字符的行通常被稱為幹淨的8小點。這是為所有的 TCP 連接的情形,就象
為大多數調制解調器連接一樣。
下列協議與 Taylor UUCP 1.04 是可得到的:
--------------------------------------------------------------------------------
調節傳動協議
所有的協議承認在文件包大小中的一些變化,超時,等等。通常,缺省在標準的情形下面提供了很好的工作,
但是不能為你的最佳狀況。 g 協議,例如,從 1∼7 的使用窗口大小,並且文件包通過 4096從 64 的 2種
修正距離依大小排列。如果你的電話線通常是這樣吵鬧,以至它掉落超過 5 個百分比的所有的文件包,你應
該可能降低文件包大小並且縮小窗口。另一方面,在很好的電話線上為每個 128 字節發送 ACKs 協議的開
銷可以証明是浪費的,因此你可能增加文件包大小到 512 或甚至 1024 。
Taylor UUCP 提供一個機制,它由在 sys 文件中與協議參數命令一起調節這些參數以適合你的需要。例
如,當與pablo談話時,設置g-protocol的文件包大小到 512 ,你必須增加:
可調的參數和他們的名字從協議到協議都有變化。為了他們的一張完全的表,參考在 Taylor UUCP 來源
中被封裝了的文檔。
--------------------------------------------------------------------------------
選擇特定的協議
不是 uucico 的每個實現說話並且理解每個協議,這樣在起始的握手階段期間,兩個過程必須在一個普通的
協議上達成一致。主人 uucico 通過發送 Pprotlist 為奴隸提供一張支持的協議列表,從中奴隸可以揀一個。
基被使用的端口類型(調制解調器, TCP ,或直接), uucico 將填寫協議的一張缺省表。對調制解調器和
直接的連接,這張表通常組成i,a,g ,G ,和j 。對 TCP 連接,這張表是 t , e ,i,a, g , G , j ,
和f 。你能用協議命令制服這張缺省表,它可以象一個端口入口一樣在一個系統入口被指定。例如,你可能象
這一樣為你的調制解調器端口編輯端口文件入口:
這將需要到來的或出去的連接,這些連接通過這個端口使用i, g ,或G.如果遠程系統不支持這些中的一些
東西,會話將失敗。
--------------------------------------------------------------------------------
(http://www.fanqiang.com)
進入【UNIX論壇】
|