rfc 854: Telnet 協議規範

rfc854:TELNET 協議規範

組織:中國互動出版網(http://www.china-pub.com/)
RFC文檔中文翻譯計劃(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:[email protected]
譯者:
譯文發佈時間:2001-10-20
版權:本中文翻譯文檔版權歸中國互動出版網所有。可以用於非商業用途自由轉載,但必須保留本文檔的翻譯及版權信息。

Network Working Group
Request for Comments: 854
Obsoletes: NIC 18639

J. Postel
J. Reynolds
ISI
May 1983

本RFC指定了一個ARPA互聯網社區的標準。在ARPA互聯網上的主機應該採納與實現該標準。

簡介

TELNET協議的目的是提供一個相對通用的,雙向的,面向八位字節的通信機制。它的主要目標是允許界面終端設備和麪向終端的過程能通過一個標準過程進行互相交互。另外,可以預想,該協議可以應用到終端到終端通信(“連接”)和過程到過程通信(分佈計算)中。

一般性的考慮

一個TELNET連接就是一個用來傳輸帶有TELNET控制信息數據的傳輸控制協議(TCP)的連接。

TELNET協議的建立基於這樣三個主要想法:一,網絡虛終端的概念;二,可談判的選項的原理;三,對終端和過程進行均衡看待的觀點。

1.一旦一個TELNET連接建立後,通信的兩端被假設爲在一個”網絡虛擬終端”,或者NVT上開始和終止操作。一個NVT可以被想象爲一個能提供 標準的,網絡範圍的規範終端的中間代表者。這消除了”服務者”和”用戶”之間需要保存對方終端和終端處理協定的信息的必要。所有的主機,包括用戶和服務 器,把他們本地的設備屬性和協定映射爲就象一個在網絡上的NVT,而且每一方都可以假設對方也有一個類似的映射。NVT有意地使過度受限(沒有提供給主機 足夠的詞彙來映射到他們的本地字符集)和過度包含(使用適當的終止來處罰用戶)達到了平衡。

注意:”用戶”機通常指那些進行連接的物理終端,”服務器”提出指的是那些能夠提供一些服務的機器。從終端到終端或過程到過程的可應用的平等性來看,”用戶”指的是初始化通信連接的機器。

2.可談判的選項的觀點基於這樣一個事實:許多主機都希望能夠在NVT之上提供更多的服務,而許多用戶將會擁有一個更復雜的終端,並且希望能夠得到 一流的,而不是極少的一點服務。儘管相互獨立,但建立在TELNET協議中的是許許多多的”選項”,這些選項將被用來認可及 同”DO,DON’T,WILL,WON’T”結構(下面將會討論)一起使用去允許用戶和服務器同意在他們的TELNET連接上使用更精緻的(或者可能是 完全不同的)協議集合。這些選項包括改變字符集,回顯,等等。

建立選項使用的基本策略,是讓每一方(或雙方)初始化一個使一些選項有效的請求,另一方可以接受或拒絕該請求。如果該請求被接受了,選項立即生效; 如果該請求被拒絕,連接的另一端仍然保留NVT的特性。很顯然,一方經常可以通過拒絕來使能,而從來不能通過拒絕來取消一些選項,因爲這些選項是雙方爲了 支持NVT而準備的。

我們已經建立了一套談判選項的規則,使得雙方在同時請求一個相同選項的時候,每一方都可以把對方的請求當作對自己的請求的肯定迴應。

3.談判句法的對稱性可能會導致無窮盡的應答循環--每一方都把對方發送過來的命令當作必須回答的請求而不是對方的應答。爲防止這種循環,可以應用下面這些規則:

  1. a.一方只能請求改變選項的狀態。也就是一方不能只發送宣佈它所使用的模式的請求。
  2. b.如果一方所接收到的請求是要求它進入當前它所在的狀態,那麼該請求將不會被應
    答。這種不應答對防止無窮盡的循環是非常重要的。對於那些改變模式的請求,都需要一個
    應答--儘管該模式不一定改變。
  3. c.無論何時,只要一方向第二方發送一個選項命令,不管該命令是請求還是應答,而
    且使用該選項將會對從第一方發送到第二方的數據進行處理時生產影響,那麼必須把該命令
    插到數據流中它希望開始起作用的點上。(要注意到在傳送請求和接收到可能是否定的應答
    的過程需要一些時間。因此,一臺主機可能在發出請求一個選項的請求後希望緩衝要發送的
    數據,直到它知道該請求是被接受還是被拒絕,來隱藏這段對用戶來說是"不確定"的時間。)

選項請求在TELENT連接剛剛建立起的時候要在在連接的兩端來來回回傳送許多次,每一方都試圖從對方獲取儘可能好的服務。然而,在另一方面,選項 可以用來動態地改變連接的特性,使它與對本地狀態的改變相一致。例如,NVT(後面將要解釋)使用的傳輸方式比較適合一個用BASIC語言編的應用,這類 應用在傳輸數據時是每次一行,而對那些每次傳輸一個字符的應用(比如NLS)就不是很適合。當對本地的處理來說是合適的,一個服務器可能會忍受這種“臨時 的特徵”所需的巨大的處理器開銷,並且會談判一個合適的選項。然而,當不再需要詳盡的控制時,處理開銷可以(通過談判)切換回NVT下的狀態。

如果一個過程在收到一個拒絕迴應後,僅僅是重新請求該選項,那麼由一個過程發起的請求將會導致不停的請求循環。 爲了防止出現這樣的循環,不能重複被拒絕的請求,除非已經改變了某些選項。在運行中,這可能意味着該過程運行一個不同的程序,或者用戶已經發出了另外的命 令,或者出現了其他所有可以影響一個過程及其選項的上下文的東西。根據經驗,重新請求只能是一個連接的另外一端在後來又提交了某些信息,或者本地用戶的交 互的需要。

選項的設計者不應該拘泥於選項談判中有限的一些語法。使用簡單的語法的本意是希望使得選項易於使用 – 因爲要忽略它們是很容易的。如果有一些特殊的選項需要一個比“DO,DON’T,WILL,WON’T”更完整的談判結構,一個比較好的方法是用"DO, DON'T, WILL, WON'T"使雙方都能理解該選項,一旦這個過程已經完成,就可以自由地使用一個更爲特別的語法。比如,一方可以發送一個請求來通知(建立)一行的長度。 如果這個請求被另一方所接受,那麼可以用另外一個不同的語法來進行實際的對一行的長度的談判 – 如一個”子談判“可能包括可以允許的最小值,可以允許的最大值,以及最合適的行的長度等字段。一個較爲重要的原理是,這樣的擴展談判只有在前面的一些(標 準)談判已經建立,並且雙方都可以解釋這些擴展語法的情況下才能開始。

總之,WILL XXX由雙方發送出去,表示該方希望(提出)開始對選項XXX進行處理。DO XXX和DON'T XXX表示它的肯定和否定迴應;類似地,DO XXX發送出去指示(請求)對方(也即DO的接收者)開始對選項XXX進行處理,WILL XXX和WON'T XXX表示肯定和否定迴應。

由於在沒有使用任何的選項的情況下,NVT通過使用DON'T和WON'T迴應來保證連接在連接的雙方都可以處理的狀態中。因此,所有主機都應該這樣實現它們的TELNET進程:在完全不知道一個不支持的選項的情況下,只需要簡單地拒絕任何無法瞭解的該選項請求。

TELNET協議儘可能地使服務器和用戶之間是對稱的,以便比較容易和自然地包含用戶到用戶(連接)和服務器到服務器(協作處理)這兩種情況。儘管 不是完全需要,但我們也希望選項能夠加強這個目的。在任何情況下,我們更傾向於明確承認對稱性是一個操作上的原則,而不是一個不變的標準。

請參考相關文檔“TELNET選項規範”來得到關於如何建立新的選項的信息。

網絡虛終端

網絡虛終端(NVT)是一個雙向的字符設備。NVT有一個打印機和一個鍵盤。打印機負責進來的數據,而鍵盤負責產生通過TELNET連接發送出去的 數據,並且在需要"回顯“時,同時在NVT的打印機上回顯這些數據。”回顯“並不要求數據一定要經過網絡(儘管有一個選項可以控制該操作的”遠程“模式, 但並不要求主機實現該選項)。

除了在這裏說明的外,所有的編碼集合都是有八位的,但只使用其中的七位的USASCII碼。所有的代碼轉換和時區方面的問題都是本地的事情,而不影響NVT。

數據的傳輸

儘管一個通過網絡連接的TELNET連接本質上是全雙工的,但通常把NVT看作在線性緩衝模式下的半雙工設備。也就是說,除非已經和對方談判好,以下情形 對應於通過TELNET連接進行數據傳輸。

1) 在本地緩衝空間允許的可用範圍內,可以在產生數據的機器上彙集數據,直到完整的一行數據已經準備好傳輸,或者某些在局部定義的信號明確地要求傳輸數據。這些信號既可以有進程產生,也可以有用戶發出。

定義這個規則的動機是,對於一些主機,處理網絡輸入中斷的代價是很高的,另外,缺省的NVT規範指定“回顯”操作的數據不經過網絡的傳輸。因此,有 理由在產生數據的源上緩衝一些數據。許多系統都會在輸入一行結束後進行一些動作(行式打印機或者卡片打孔機經常都是這樣子的),因此數據傳輸可以在一行數 據結束時觸發。另外,有時候一個用戶或者進程會發現有必要或者應該提供一些不在一行的結尾結束的數據;因此實現者要注意,提供的局部信號機制要確保所有的 緩衝數據都能夠被立即發送出去。

2) 當一個過程已完成向一個NVT打印機發送數據,並且輸入隊列中也沒有來自NVT鍵盤,需要進一步進行處理的數據(就是說,當一個在TELNET連接的一端 的過程無法在另一端沒有數據輸入的情況下進行處理),該過程必須傳輸TELNET 的繼續(Go Ahead,GA)命令。

這個規則並不要求在一個連接的兩端上的終端都發送TELNET GA命令,因爲服務器開始進行處理時,一般情況下都不需要一個特別的信號(以及斷開連接信號和其他在本地定義的特性)。況且,TELNET GA被設計來幫助一個具有“可鎖定”鍵盤的本地計算機(如IBM2741)建立一個物理上的半雙工終端。這種終端的一個說明可能對解釋GA命令的正確用法 有幫助。

終端到計算機的連接總是在用戶或者計算機的控制之下。任何一方都不能單方面地奪取另一方的控制;而且取得控制的一方必須明確地放棄它地控制。在終端 這一方,硬件上就支持在每次一個“連接”終止的時候(也就是在用戶按下“新連接”的鍵時),它就放棄控制。 當這種情況發生時,連接的(本地)計算機處理輸入的數據,決定是否要產生輸出,如果不需要的話,就把控制返回給終端。如果要產生輸出,計算機維持控制,直 到所有的輸出都被傳輸完畢。

通過網絡使用這種類型的終端,困難是顯而易見的。“本地”計算機在看到一個結束連線信號後,無法決定是否要保持控制,這個決定只能由處理這些數據的 “遠程”計算機作出。因此,TELNET中的GA命令提供了一個機制,使“遠程”計算機(服務器)如何給“本地”計算機(用戶)發送信號,告訴對方現在是 給用戶終端傳遞控制的時間。當用戶需要獲得對終端的控制時,它應該並且只能在這段時間傳遞。 注意,過早地傳遞GA命令將導致輸出阻塞,由此用戶可能會認爲傳輸系統已經被暫停,因此將導致用戶手工轉向連接時失敗。

當然,前面所說的這種情況不會在通訊過程中用戶到服務器這個方向上出現。在這個方向上,儘管沒有必要,但在任何時候都可能發送出GA。同樣,如果 TELNET連接被應用在過程到過程的通訊中,在兩個方向上都不需要發送GA。最後,對於終端到終端的通訊,在兩個方向上可能都需要GA。如果一個主機打 算支持終端到終端的通訊,建議主機在需要通過TELNET連接發送GA的時候,提供一個手工發信號給用戶的方法。然而,在實現TELNET過程中,這一點 並不是必需的。

注意:由於TELNET模型的對稱性,從理論上來說,在一個TELNET連接的每一端,都必須有一個NVT。

控制功能的標準表示

就象我們在本文檔的簡介中所說,TELENT協議的主要目標是在通過網絡連接的終端設備和麪向終端的過程之間提供一個標準的接口。早期具有這種互聯 性質的實驗表明,大部分的服務器都實現了某些功能,但調用這些功能的方式卻差別很大。對於一個要與多個服務器系統交互的用戶來說,這些差別是一個非常大的 障礙。因此,TELNET協議定義了這些功能中的下面5種的標準表示。這些標準表示包括標準,含義 --- 儘管不是必需的(除了中斷進程(IP)功能,使用TELENT協議的其他協議可能需要該功能)。因此,一個沒有給本地用戶提供某種功能的系統也沒有必要給 網絡上的其他用戶提供該功能,並且可以把該功能的標準表示當作No操作。在另一方面,如果一個系統已經給本地用戶提供了該功能,那
麼它必須給網絡上那些傳該功能的標準表示的用戶提供同樣的功能。

中斷進程 – Interrupted Process(IP)

許多系統提供掛起,中斷,中止,終止用戶進程的操作的功能。當用戶確信他的進程已經進入了無窮盡的循環,或者不小心激活了一個並不希望激活的進程 時,就要經常使用該功能。IP就是調用該功能的標準表示。該功能的實現者需要注意,其他使用TELNET協議的協議可能要使用IP,因此實現時要支持這些 協議。

中斷輸出 -- Abort Output (AO)

許多系統提供了允許一個產生輸出的進程在不向用戶的終端發送輸出的情況下完成運行(或者達到在完成運行的過程中將會達到的某一個停止點)的功能。

另外,該功能一般還清除那些已經生成但還沒有實際打印(或者顯示)到用戶的終端上的輸出。AO是調用該功能的標準表示。 比如,許多子系統通常會接受一個用戶的命令,然後以一個發送到用戶終端的長的字符串作爲迴應,最後,給用戶的終端發送一個“提示”字符(前面跟 着<CR><LF>)來表示準備接受下一個命令。如果是在傳輸字符串的過程中接收到AO,一個合理的實現應該停止繼續傳輸字符 串,而轉向發送提示符和跟在前面的CR><LF>。(這可能同接收到IP所進行的動作有一些差別。在接收到IP時,將導致停止字符串的 傳輸並且從子系統中退出。

同時還需要注意到,對那些提供這種功能的服務器,可能還需要清除那些存在於系統外的緩衝機制(在網絡中或者在用戶的本地機器上)中的內容。完成這個過程的一個合適的方法是給用戶的系統發送“同步”信號(將在下面描述)。

你在那裏嗎? -- Are You There (AYT)

許多系統提供了給用戶提供系統仍然在運行的一些可見的(如可打印的)跡象。這個功能可以在系統在一個想象不到的很長一段時間裏都沒有動靜時(可能是由於用戶沒有想象到的計算時間,或者不正常的巨大系統負荷等導致。)由用戶調用。 AYT是調用該功能的標準表示.

消除一個字符 - - Erase Character (EC)

許多系統提供了刪除在未刪除字符前面或者用戶提供的數據流中的“打印位置” 最後面的一個字符的功能。該功能通常在鍵盤輸入時輸入了錯誤的字符時使用。EC是調用該功能的標準表示。

*注意 :一個“打印位置”可能包含相互覆蓋的幾個字符,或者象下面的字符系列:<char1> BS <char2>...

消除一行 -- Erase Line (EL)

許多系統提供了刪除輸出設備上的當前一行的全部數據的功能。該功能經常在用鍵盤進行輸入編輯時使用。EL是調用該功能的標準表示。

TELNET中的“同步(SYNCH)"信號

許多系統提供了一種機制,可以允許一個終端的用戶對一個“失控“的進程重新獲得控制權。上面描述的IP和AO功能就是這種機制的例子。當在本地使用 時,這樣的系統可以訪問由用戶提供的所有信號,而不管這些信號是一些普通字符或者是由電傳打字機中的"BREAK"鍵或IBM 2741中的"ATTN"鍵發送的”帶外“信號。然而當通過網絡把系統聯結起來時,這可能是不正確的。網絡的流程控制機制可能導致把這些信號緩衝到其他地 方,比如用戶的機器中。

爲了解決這個問題,提出了TELNET中的"同步" 機制。

一個同步信號包含一個同TELNET命令DATA MARK結合在一起的TCP緊急通知。該緊急通知與TELNET連接中的流程控制沒有關係,接收它的進程用它來調用數據流的特殊處理過程。在這種模式中, 立即對數據流進行掃描,查找下面定義的一些“有趣“的信號,而把那些干涉的數據丟棄。

TELNET命令DATA MARK (DM)是數據流中的同步標記,表示所有特殊的信號都已經產生,接受者可以繼續對數據流進行一般的處理。

同步信號通過TCP中的發送操作發送,在發送過程中需要把緊急標誌設爲“真“,並且把DM作爲最後(或者唯一的)一個字節。

當許多同步信號快速地連續不斷地發送時,可以合併緊急通知。不可能去計算緊急通知的次數,因爲接收到的緊急通知的次數可能等於或者少於發送次數。在普通模式中,一個DM是沒有任何操作的,但在緊急模式中,它表示緊急處理過程的結束。

如果在發現DM之前,TCP已經指示緊急數據的結束,TELNET應該繼續對數據流進行特殊的處理,直到發現DM。

如果在發現DM之後,TCP指示有更多的緊急數據,它只能是另外同步信號。TELNET應該繼續對數據流進行特殊的處理,直到發現另外一個DM。

定義的“有趣的“信號爲:TELNET中的IP, AO, 和 AYT (沒有EC 或EL)的標準表示;與這些標準表示類似的本地表示(如果有的話);所有的其他TELNET命令;其他在不延遲數據流的掃描並且能夠起作用的自定義信號。

由於SYNCH機制的一個影響是丟棄本來在發送者和接收者之間要傳輸的所有字符(除了TELNET命令),如果需要,這個機制可以作爲清除數據路徑 的一種標準方式。例如,在一個終端上的用戶需要傳輸一個AO,接收到該AO的服務器應該給該用戶返回一個同步信號(如果它提供該功能的話)。

最後,就象在TELNET層,需要把一個TCP緊急通知當作一個帶外信號,因此其他使用TELNET的協議可能需要從不同層次來看可以當作帶外信號的TELNET命令。

通過約定系列[IP, Synch] 可以把它作爲這樣的信號。例如,假設有一個使用TELNET協議的其他協議定義了一個類似於TELNET命令AO的字符串STOP。想象用戶使用該協議的 目的是希望服務器處理STOP字符串,但由於服務器在處理其他的命令,導致連接被阻塞。用戶應該引導他的系統:

  1. 發送出TELNET IP字符;
  2. 發送出TELNET SYNC系列,也就是:在一個緊急模式的TCP發送操作中把Data Mark(DM)作爲唯一的字符發送出去。
  3. 發送出字符串STOP;接着
  4. 如果有的話,把其他協議中類似於TELNET DM的命令發送出去。

用戶(或者代表該用戶的進程)必須傳輸上面步驟2中的TELNET SYNCH 系列,以確保 TELNET IP已經到達服務器的TELNET 解釋器。

緊急通知將激活TELNET進程,而IP將激活隨後級別較高的進程。

NVT打印機和鍵盤

NVT打印機有一個沒有指定寬度的走紙器,並且每一頁的長度也沒有指定。NVT打印機可以產生所有95個USASCII編碼的圖形表示(從32到 126的編碼)。在33個USASCII編碼(0到31及127)和未包含的其他128個編碼(128到255)中,下面幾個編碼對NVT打印機有確定意 義:

名稱 編碼 意義
NULL (NUL) 0 沒有操作
Line Feed (LF) 10 打印頭移到下一個打印行,但不改變打印頭的水平位置。
Carriage Return (CR) 13 把打印頭移到當前行的左邊 。

另外,在NVT打印機上,儘管不是必需的,同時應該定義下面這些編碼。TELNET連接的雙方,都不會假設另一方在接收到或傳輸下面這些編碼時將會,或者已經實施某種特殊動作:

名稱 編碼 意義
BELL (BEL) 7 產生一個可以看到或可以聽到的信號(而不移動打印頭。)
Back Space (BS) 8 向左移動打印頭一個字符位置。
Horizontal Tab (HT) 9 把打印頭移到下一個水平製表符停止的位置。它仍然沒有指定每一方如何檢測或者設定如何定位這樣的製表符的停止位置。
Vertical Tab (VT) 11 把打印頭移到下一個垂直製表符停止的位置。它 仍然沒有指定每一方如何檢測或者設定如何 定位這樣的製表符的停止位置。
Form Feed (FF) 12 把打印頭移到下一頁的頂部,保持打印頭在 相同的水平位置上。

剩下的其他編碼都不會導致NVT打印實施任何動作。

在定義中,系列"CR LF"將導致NVT打印頭移動到下一行的左邊(與系列 "LF CR"的效果是一樣的)。然而,許多系統和終端並不獨立處理CR和LF,爲了模擬它們的效果,需要進行一些處理。 (比如,許多終端沒有獨立於LF的CR,但是在這樣的終端上可以用退格鍵來模擬一個CR。)因此,必須把系列CR LF"當作一個單獨的“新行”字符看待,並且在需要把它們結合在一起的時候使用它們。必須在只需要一個單獨的回車鍵時使用系列"CR NUL";在其他的場境中必須避免使用CR字符。這個規則可以確保系統在發現一個TELNET 流中有一個字符的後面跟有CR的情況下,可以作出合理的選擇:是進行“換行”功能還是進行多次的退格操作。

注意,在兩個方向上(在缺省的ASCII模式下)都需要"CR LF"或者"CR NUL",以確保NVT模式的對稱性。

儘管在某種情況下(如當遠程回顯和禁止超前選項同時起作用時),可以認爲字符並不被髮送到一個實際的打印機上,然而,爲了保證一致,在一個數據流中,如果一個CR的後面沒有跟着一個LF,該協議要求把一個NUL插到CR的後面。

相反,在接收方,如果從數據流中接收到一個跟在CR的後面的NUL(在沒有用談判選項顯式指定其他選擇的情況下),在把NVT轉換成本地字符集之前,應該把NUL去掉。

NVT鍵盤有鍵或者鍵的組合,或者鍵系列來產生所有128格USAACII編碼。要注意儘管一些在NVT打印機上沒有什麼用處,NVT鍵盤還是可以生成。

除了這些編碼,NVT鍵盤還可以生成下面這些附加的編碼,除註明外,還定義了這些編碼的意義(儘管不是必需的)。

對這些“字符”的實際代碼分配在TELNET命令這一節,因爲從某種意義上來講,我們可以認爲這些編碼是固有的,甚至在把數據流中的數據都解釋爲屬於另外的一個字符集的時候,都可以使用這些編碼。

Synch

這個鍵允許一個用戶清空到另一方的數據通道。激活該鍵將導致發送一個帶有TCP緊急通知的DM(參看命令這一節)。一對DM-緊急通知具有在前面定義的一些意義。

Break (BRK)

之所以提供這個編碼,是因爲在當前的許多系統中,它是USASCII集合之外的一個信號,並且具有本地意義。 可以用它來表示Break鍵或Attention鍵已被按下。然而,需要注意的是,它的目的是給需要它的系統提供第129個編碼,而不等同於IP的標準表示。

Interrupt Process (IP)

掛起,中斷,中止,終止一個NVT連接的進程。另外,它也是那些使用TELNET的其他協議的帶外信號的一部分。

Abort Output (AO)

允許當前的進程繼續運行直到結束,但不給用戶發送它的輸出信息。並且把一個同步信號發送給用戶。

Are You There (AYT)

給NVT發送回一些可見的(也就是可打印的)信息以表明已經收到AYT。

Erase Character (EC)

接收者將刪除數據流中最後一個未被刪除的前導字符或者“打印位置”。

Erase Line (EL)

接收方將刪除由TELNET連接發送的數據流中最後一個“CR LF”系列(但不包括該系列)後面的全部內容。

這些“額外”的鍵,也就是打印機的格式控制字符的本質是,它們是對從“NVT”到“本地”這個必須進行的映射過程的一個自然的擴展。

就象NVT中的字節68(八進制104),可以映射爲本地中代表“大寫D”的任何一個編碼,字符EC也可以映射爲本地中代表“刪除一個字符”功能。

另外,就象在一個沒有“垂直線”字符的環境下,對編碼124(八進制174)的映射是任意的,如果在本地沒有“刪除一個字符”這種機制,對EL的映射也是任意的(甚至不映射)。

類似地,對格式控制字符,如果終端確實有一個“垂直製表鍵”,那麼對VT地映射就是顯而易見的,只有在終端沒有一個垂直製表鍵的情況下,VT的作用纔是無法預測的。

TELNET命令結構

所有的TELNET命令至少包含一個兩個字節的序列:跟在命令的代碼的後面,"當作命令來解釋(Interpret as Command)"(IAC)的轉義字符。處理選項談判的命令有三個字節系列,第三個字節就成了被選項引用的編碼。之所以選擇這種格式,是這種格式能夠更 大範圍地使用"數據空間"---當然,是通過基本NVT的談判來進行。數據字節與保留的命令值的衝突被大大減少了,而所有這些衝突都需要複雜,低效的方法 來把數據字節轉換爲流。使用現在的方法,只有在需要把IAC當作數據發送時才需要把相同的數據發送兩次,其他255個代碼都可以透明地傳輸。

下面是所有已定義的TELNET命令。需要注意的是,這些代碼和代碼序列只有在前面跟有一個IAC時纔有意義。

名稱 代碼 意義
SE 240 子談判參數的結束
NOP 241 空操作
Data Mark 242 一個同步信號的數據流部分。該命令的後面經常跟着一個TCP緊急通知
Break 243 NVT的BRK字符
Interrupt Process 244 IP功能.
Abort output 245 AO功能.
Are You There 246 AYT功能.
Erase character 247 EC功能.
Erase Line 248 EL功能.
Go ahead 249 GA信號.
SB 250 表示後面所跟的是對需要的選項的子談判
WILL (option code) 251 表示希望開始使用或者確認所使用的是指定的選項。
WON'T (option code) 252 表示拒絕使用或者繼續使用指定的選項。
DO (option code) 253 表示一方要求另一方使用,或者確認你希望另一方使用指定的選項。
DON'T (option code) 254 表示一方要求另一方停止使用,或者確認你不再希望另一方使用指定的選項。
IAC 255 Data Byte 255.

連接的建立

TELNET TCP連接是在用戶端口U和服務器端口L之間建立的。服務器在用於這種類型的連接的一個衆所周知的端口L上監聽客戶請求。由於一個TPC連接是全雙工的,並且通過雙方的端口來標識,服務器可以對不同的用戶端口U和端口L的之間的許多併發連接進行應答。

端口分配

當用來給遠程用戶提供訪問服務主機的服務(也就是遠程終端訪問),這個協議分配了服務端口23(把進制27)。也就是L=23。

本RFC指定了一個ARPA互聯網社區的標準。在ARPA互聯網上的主機應該採納與實現該標準。

給TELNET協議提供一些選項的目的是,使相互通信的主機在解決不同設備之間的通信問題時獲得比由網絡虛擬終端(NVT)提供的可能框架有更好的 方案。它可以讓主機自由地創建,測試或者丟棄某些選項。當然,可以想象,那些普遍有用的選項最終大部分的主機都應該支持。因此,應該仔細地設計這些選項的 文檔,並且儘可能地公佈它們。另外,確保不在不同地選項中使用相同的選項代碼也是必要的。

本文檔指定了一個選項代碼的分配和選項的文檔標準方面的方法。在進行試驗時,可能只需要選項代碼分配而不需要完整的文檔,不過一般來說,在分配選項 代碼之前都需要一個文檔。我們通過把一個選項的文檔作爲一個RFC文檔來發布,從而發佈該選項。當然,選項的創建者也可以用其他的方式發佈選項。

選項代碼由下面人員分配:

Jonathan B。 Postel
University of Southern California
Information Sciences Institute (USC-ISI)
4676 Admiralty Way
Marina Del Rey, California 90291
(213) 822-1511

Mailbox = POSTEL@USC-ISIF

選項的文檔至少要包含下面幾個小節:

第1節 - - 命令的名稱和選項的代碼

第2節 - - 命令的意義

應該描述同該選項相關的每一個TELNET命令的意義。需要注意的是,對於複雜的選項,“子談判”是必需的,因此可能有許多相關的命令。“子談判”的原理在下面有更詳細的描述。

第3節 - 缺省的規範

對那些沒有實現,或者沒有使用該選項的主機,必須描述這些選項在這些主機中的缺省假定值。

第4節 - 動機

對創建一個特殊的選項,或者對某種選項選擇一種特殊的格式的動機進行詳細的描述,對那些還沒有碰到(或者雖然已經碰到,但沒有認識到)該選項設計來解決的問題的人,是非常有用的。

第5節 - 描述(或者實現規則)

爲了確保一個命令的兩個不同實現相互之間能夠通訊,僅僅定義命令的意義和對該命令的意圖進行說明有時候是遠遠不夠的。因此,在許多情況下,我們需要給一個命令提供一個完整的描述。這個描述可以用文本來表示,也可以是一個示例性的實現,或者是實現的線索等等。

對“子談判”的解釋

在主機之間傳遞選項時,除了一個選項編碼外可能還需要更多其他信息。例如,要求一個參數的那些選項就屬於這種情況。在主機之間傳遞除了選項代碼外的其他信息的策略包含兩個步驟:雙方都同意去”商討“該參數,第二,對參數進行”商討“。

在第一步中,同意去討論參數以一種普通的方式來進行。一方通過發送一個帶有選項代碼的DO(或WILL)命令來建議使用選項,另一方發送一個帶有選 項代碼的DO(或WILL)命令來表示接受這個建議。一旦雙方都同意使用這選項,通過在SB命令的後面跟上相應的選項代碼,參數和命令SE來開始子談判。 每一方都被假設爲能夠解析該參數。因爲在最初通過交換WILL和DO命令,雙方都表明可以支持該選項。另外,即使接收方不能解析該參數,接收方也可以通過 搜索SE命令(如字符串IAC SE)來定位參數字符串的結束位置。當然,在任何時候,任何一方都可以給另一方發送WON'T或DON'T來拒絕繼續進行進一步的子談判。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章