首先介紹基本的單字符方式，該方式類似于Rlogin。用戶在終端輸入的每個字符都將由終端發送到服務器進程，服務器進程的響應也將以字符方式回顯到終端上。在這里運行的是一個新的客戶進程BSD/386，它試圖激活很多新的選項，服務器進程還是運行老的SVR4，我們將看到很多選項被服務器拒絕。

　　為了看到服務器和客戶機之間選項協商的內容，我們將激活客戶進程的一個選項來顯示所有的選項協商。同樣我們運行tcpdump來獲得數據報交換的時間次序。圖26-12顯示了這個交互會話。

　　在圖中，我們已經對由SENT或RCVD開頭的選項協商的每一步都進行了標注。關于每一步的解釋如下：

1)客戶發起SUPPRESSGOAHEAD選項協商。由于GOAHEAD命令通常是由服務器發送給客戶的，而且客戶希望服務器激活該選項，因此該選項的請求方式是DO（由于激活這一選項將會禁止GA命令的發送，上述過程很輕易讓人混淆）。在第10行可以看到服務器進程同意該選項。

2)客戶進程要按照在RFC1091[VanBokkelen1989]中的定義發送終端類型。這對Unix類型的客戶進程來講是很普通的。因為客戶進程要激活本地的選項，所以該選項的請求方式是WILL。


調用客戶進程，不帶任何命令行選項告訴客戶進程顯示所有的選項協商過程，現在和服務器建立連接，我們鍵入用戶和口令，服務進程不回顯這些數據，然后操作系統問候輸出，然后是外殼提示符。

3)NAWS的意思是“協商窗口大小”，它在RFC1073[Waitzman]中有定義。假如服務器進程同意該選項（實際上不同意，見11行），客戶進程就要發送終端窗口的行、列大小的子選項。而且只要窗口大小發生變化，客戶進程隨時都將向服務器進程發送這一子選項（這和圖26-4中Rlogin的0x80命令類似）。

4)TSPEED選項答應發送方（通常是客戶進程）發送它的終端速率，這在RFC1079[Hedrick1988b]中有定義。假如服務器進程同意（實際上不同意，見12行），客戶進程將發送其發送速率和接收速率的子選項。

5)LFLOW代表“本地流量控制”，這在RFC1371[Hedrick和Borman1992]中定義。客戶進程給服務器進程發送該選項，表示客戶進程希望用命令方式激活或禁止流量控制。假如服務器進程同意（實際上不同意，見13行），只要Control_S和Control_Q進程需要在客戶進程和服務器進程進行切換，客戶進程都要向服務器進程發送子選項（這類似于圖26-4中Rlogin的0x10和0x20命令）。正如在關于Rlogin的討論中我們所提到的那樣，由客戶進程進行流量控制的效果比由服務器進程來完成要好。

6)LINEMODE代表在26.4中所說的實行方式。所有終端字符的處理由Telnet客戶進程完成（例如回格，刪除行等），然后整行發送給服務器進程。在本節后面，我們將介紹一個例子。該選項同樣被服務器進程拒絕，如14行所示。7)ENVIRON選項答應客戶進程把環境變量發送給服務器進程，這在RFC1408[Borman1993a]中有定義。這樣就可以把客戶進程的用戶環境變量自動傳播到服務器進程。在15行，服務器進程拒絕該選項（Unix中的環境變量通常是大寫字母，緊跟一個等號，然后是一個字符串值，當然這只是一個慣例而已）。默認情況下，BSD/386Telnet客戶進程發送兩個環境變量：DISPLAY和PRINTER，前提是這兩個變量已經定義并且有效。Telnet用戶可以定義其他一些要發送的環境變量。

8)STATUS選項（RFC859[Postel和Reynolds1983e]中定義）答應連接的一方詢問對方對Telnet選項目前狀態的理解。在這個例子中，客戶進程要求對方激活選項（DO）。假如服務器進程同意（實際上不同意，見16行），客戶進程就可以要求服務器進程以子選項的形式發送它的狀態值。

9)這是服務器進程的第一個響應。服務器進程同意激活終端類型選項（幾乎所有的Unix類型的服務器進程都支持該選項）。但現在客戶進程還不能立即發送它的終端類型。它必須要等到服務器進程用子選項的形式詢問終端類型的時候才能夠發送（17行）。

10)服務器進程同意抑制發送GOAHEAD命令。11)服務器進程不同意客戶進程發送它的窗口大小。12)服務器進程不同意客戶進程發送它的終端速率。13)服務器進程不同意客戶進程實施流量控制。14)服務器進程不同意客戶進程激活行方式選項。15)服務器進程不同意客戶進程發送環境變量。16)服務器進程不發送狀態信息。17)這是服務器進程要求客戶進程發送終端類型的子選項。18)客戶進程把終端類型“IBMPC3”以6字節的字符串形式發送給服務器進程。19)服務器進程要求客戶進程發起請求，要求服務器進程激活回顯選項。這是本例中服務器進程第一次主動發起選項協商。20)客戶進程同意由服務器進程實現回顯功能。21)服務器進程要求客戶進程實現回顯功能。這個命令是多余的，它只是將前兩行進行了交換。這是目前大多數Unix的Telnet服務器進程判定客戶進程是否運行4.2BSD或更新的BSD版本時的一個方法。假如客戶進程回送WILLECHO，就表明客戶進程運行的是老版本的

4.2BSD，不支持TCP的緊急方式（在這種情況下就不能采用TCP緊急方式）。22)客戶進程回送WONTECHO，表示它不是一臺4.2BSD主機。23)對于客戶進程回送的WONTECHO，服務器進程以DONTECHO作為響應。圖26-13顯示的是本例中服務器進程和客戶進程交互的時間系列（去掉了連接建立部分）。報文段1包含了圖26-12中的1~8行。該報文段中包含24個字節數據，每個選項占3個字節。這是客戶進程發起的選項協商。該報文段顯示多個Telnet選項可以打在一個TCP段中發送。報文段3是圖26-12中的第9行，即DOTERMINALTYPE命令。報文段5包含下面的8個選項協商中服務器進程的響應，即圖26-12中的10~17行。該報文段的長度是27個字節，因為10~16行是常規選項，每個占3個字節，而17行的子選項部分占6個字節。報文段6包含12個字節，和18行對應，這是客戶發送它的終端類型的子選項。報文段8（53個字節）包含兩個Telnet命令和47字節的輸出數據。前面的兩個服務器進程發送Telnet命令占6字節，：WILLECHO和DOECHO（19和21行）。后47個字節的數據是：/r/n/r/nUNIX(r)SystemVRelease4.0(svr4)/r/n/r/0/r/n/r/0前面4個字節數據在字符串輸出之前產生兩個空行。兩字節的字符序列“/r/n”在Telnet中被認為是換行命令，而兩字節的字符序列“/r/0”則被認為是回車命令。這表明數據和命令可以在一個數據段中傳輸。Telnet服務器進程和客戶進程必須掃描接收到的每個字符，尋找IAC字節并執行它后續的命令。

　　報文段9包含客戶進程發送的最后兩個選項：20和22行。23行是報文段10的響應，也是服務器進程發送的最后一個選項數據。

　　從現在開始，雙方就可以交互數據了。當然在交互數據的過程中還可以進行選項協商，我們在該例子中就不多介紹了。報文段12是服務器進程發送的提示符“login:”。報文段14是用戶輸入的登錄用戶名的第一個字符，它的回顯在報文段15中。這和我們在19.2節中介紹的Rlogin交互類似：客戶進程每次發送一個字符，服務器進程完成回顯工作。

　　圖26-12中的選項協商由客戶進程初始化的，但是在本書中我們已經介紹了用Telnet客戶進程連接某些標準服務器進程如：日間（daytime）服務器、回顯(echo)服務器等情況。當然我們介紹這些的目的是為了描述TCP的各種特性。但考察這些例子中的分組交換，如圖18-1，我們并沒有看到客戶進程發起的選項協商。為什么？這是因為在Unix系統中，除非使用標準的Telnet端口號23，否則客戶進程不進行選項協商。這個特性使得Telnet客戶進程可以使用標準的NVT同其他一些非Telnet服務器進程交換數據。我們已經在日間服務器、回顯服務器和丟棄(discard)服務器中使用了這個特性，在后面章節介紹FTP和SMTP服務器的時候我們還將使用該特性。