為了描述Telnet的行方式選項協商過程，我們在主機bsdi運行客戶進程，服務器是位于vangogh.vs.berkeley.edu節點運行4.4BSD操作系統的一臺主機。BSD/386和4.4BSD都支持這個選項。

　　我們不具體討論所有的報文、選項和子選項協商過程，因為這個過程和前面的例子類似，而且對于行方式選項我們已經論述得比較清楚。下面我們僅僅討論在選項協商中的一些區別。1)對于BSD/386希望協商的選項例如：窗口大小、本地流量控制、狀態、環境變量和終端速率等，4.4BSD服務器進程都支持。2)4.4BSD服務器進程將協商一個BSD/386客戶進程不支持的新選項：鑒別（為避免以明文形式在網絡上傳輸用戶口令）。

3)和上個例子一樣，客戶進程發送WILLLINEMODE選項，由于服務器進程支持該選項，所以服務器進程發送DOLINEMODE。此時客戶進程以子選項形式給服務器進程發送16個特定字符。這些字符是能影響客戶進程的特定終端字符值：如中斷字符，文件結束符等。服務器進程給客戶進程發送一個子選項，讓客戶進程處理所有的輸入，執行所有的編輯功能（刪除字符，刪除行等）。客戶進程把除控制字符以外的字符以行的形式發送給服務器進程。服務器進程還要求客戶進程把所有中斷鍵和信號鍵轉換為相應的Telnet字符。例如中斷鍵是Control_C，我們可以按Control_C來中斷服務器端的某個進程。客戶進程必須把Control_C轉換為Telnet的ip命令（）傳輸給服務器進程。

4)當用戶輸入口令時情況也有所不同。在Rlogin和一次一字符方式的Telnet中，都是由服務器進程負責回顯，所以當服務器進程讀到口令時，它并不回顯這些字符。但在行方式中由客戶進程負責回顯。下面這些交互過程將處理這種情況：

(a)服務器進程發送WILLECHO，以告訴客戶進程：服務器進程將處理回顯。

(b)客戶進程回送DOECHO。

(c)服務器進程向客戶進程發送字符串PassWord:，客戶進程把它發送到終端上。

(d)然后用戶輸入口令，當用戶按下RETURN鍵的時候，客戶進程把口令發送給服務器進程。此時口令不回顯，因為客戶進程認為服務器進程將回顯它。

(e)由于口令的結束符RETURN沒有回顯，服務器進程發送兩字節字符序列CR和LF以移動光標。

(f)服務器進程發送WONTECHO。

(g)客戶進程回送DONTECHO。然后繼續由客戶進程負責回顯。

一旦登錄完成，客戶進程將把數據以整行的方式發送給服務器進程。這就是行方式選項的目的。行方式大大地減少了客戶進程和服務器進程之間的數據交互數量，而且對于用戶的擊鍵（也就是回顯和編輯）提供更快的響應。圖26-14顯示的是當我們輸入命令時，在行方式連接下分組交換的情況。Vangogh%date

（去掉了業務種類信息和窗口通告信息）。

　　把它和在Rlogin中輸入同樣命令時的情況進行一下比較。我們看到在Telnet行方式下只需要2個報文段（一個包含數據，另一個用于ACK，連同IP和TCP首部共86字節），而在Rlogin中要發送15個報文段（5個有鍵入的數據，5個有回顯的數據，5個是ACK，共611字節）。可見節省的數據量是非常可觀的。

　　假如在服務器端運行一個需要進入單個字符方式的應用程序（例如vi編輯器）會怎么樣呢？實際上將發生如下的一些交互：

1)當服務器的應用程序啟動了，并改變其偽終端方式時，Telnet服務器進程被通告需要進入單個字符方式。然后服務器發送WILLECHO命令和行方式子選項，以告知客戶不要再以行方式工作，轉而進入單個字符方式。

2)客戶響應以DOECHO，并確認行方式子選項。

3)應用程序在服務器上運行。我們鍵入的每個字符將發送到服務器（當然要強制使用Nagle算法），此時服務器將處理必要的回顯工作。

4)當應用程序終止時，就恢復其偽終端方式，并通告Telnet服務器。服務器將向客戶發送WONTECHO命令，同時發送行方式子選項，告訴客戶恢復進入行方式。

5)客戶響應DONTECHO，確認進入行方式。

　　上述情況同我們鍵入口令之間的區別表明：回顯功能和單個字符方式與一次一行方式沒有依靠關系。當我們鍵入口令時，回顯功能必須失效，但一次一行方式有效。對于一個全屏應用來講，例如編輯器，回顯必須失效而單個字符方式必須有效。

圖26-15概括了Rlogin和Telnet不同方式之間的差異。
應用程序客戶進程發送進程回顯？例子一次一字符
一次一行R l o g i n • 否Te l n e t • 否Te l n e t ，行方式• 是正常命令Te l n e t ，行方式• 否鍵入我們的口令Te l n e t ，行方式• 否v i編輯器