Vyšlo v týdeníku Computerworld č. 27/93 v roce 1993
Vytištěno z adresy: http://www.earchiv.cz/a93/a327c110.php3

Telnet - II.

V minulém dílu jsme se zabývali celkovou architekturou protokolu TELNET a jeho vazbou na prostředí, ve kterém je implementován. Ukázali jsme si, že tato vazba je zcela záměrně minimální, a díky tomu není protokol TELNET vázán na určitý operační systém. Dnes se již budeme věnovat konkrétním vlastnostem protokolu TELNET a mechanismům, které používá.

Nejprve si ale stručně připomeňme pojem virtuálního terminálu, kterému jsme věnovali 66. díl seriálu: vzhledem k velké různorodosti skutečných terminálů není dost dobře možné, aby se každá aplikace přizpůsobovala každému jednotlivému terminálu. Místo toho se zavedl tzv. virtuální terminál jako jednotný mezistupeň, kterému se z jedné strany přizpůsobují všechny aplikace, a z druhé strany všechny skutečné terminály. Jako "virtuální" je tento společný mezistupeň označován proto, že je ve skutečností jen abstrakcí, a nikoli fyzicky existujícím zařízením. V 66. dílu jsme si také naznačili, že protokol TELNET používá zvláštní případ tzv. parametrického modelu virtuálního terminálu.

NVT - Network Virtual Terminal

Virtuální terminál, používaný protokolem TELNET, je označován jako NVT, neboli Network Virtual Terminal (doslova: síťový virtuální terminál). Je zvláštním případem parametrického modelu v tom smyslu, že předpokládá pevně danou hodnotu jednotlivých parametrů, které terminál definují (viz 66. díl), čímž vlastně fixuje jeho vlastnosti i konkrétní způsob ovládání. Popišme si nyní, jaká je představa tohoto zařízení:

NVT je obousměrné, znakově orientované zařízení, které lze nejlépe přirovnat ke dvojici klávesnice-tiskárna. Klávesnice generuje jednotlivé znaky v kódu ASCII, zatímco tiskárna je průběžně tiskne. Celek pak odpovídá představě tzv. znakového, resp. řádkového terminálu (scroll mode terminal, viz 66. díl).

Ačkoli protokol TELNET využívá pro přenos dat spolehlivé a spojované přenosové služby transportního protokolu TCP, které vytváří plně duplexní spojení, NVT toto spojení využívá jen v poloduplexním režimu. Díky tomu je pak možné vystačit i s takovým skutečným terminálem, který je fyzicky poloduplexní (jako např. terminál IBM 2741).

NVT dále předpokládá, že přenos dat bude tzv. bufferován - tedy že data nebudou vysílána po jednotlivých znacích, ale že se budou nejprve hromadit ve vhodných vyrovnávacích pamětech (anglicky: buffers), a skutečně vysílány pak budou až větší celky. Jaké celky to ale mají být?

U řádkového terminálu, jakým je NVT, je jednoznačným kandidátem řádka. Délka řádky ovšem není pevně stanovena, a to ani u tiskárny. Na straně klienta určuje skutečnou délku každé jednotlivé řádky uživatel, který pracuje na příslušném terminálu - tím, že v určitý okamžik zmáčkne tlačítko ENTER, RETURN, NEW LINE či jak se na jeho terminálu jmenuje klávesa, kterou se zadává konec řádky. Klientská složka protokolu TELNET, která zpracovává uživatelův vstup z klávesnice, může na základě zmáčknutí této klávesy obdržet různý kód (např. jen znak CR, jen znak LF, dvojici znaků CR a LF apod.), podle konkrétního použitého terminálu. Sama však musí na jeho základě vygenerovat dvojici znaků CR a LF, neboť virtuální terminál NVT počítá s tím, že řádky budou zakončovány právě tímto způsobem. Analogicky je tomu i na straně serveru - aplikační proces, který generuje data, určená k zobrazení na terminálu, je člení na jednotlivé řádky takovým způsobem, jaký předpokládá příslušná "místní" konvence. Serverová složka protokolu TELNET je však před odesláním překládá do takového tvaru, aby byly zakončeny dvojicí CR LF.

Protokol TELNET tedy předpokládá, že data budou standardně přenášena po celých řádcích. To ale nemusí být vždy možné - není-li délka řádky předem omezena, může se stát, že pro ni nebude k dispozici dostatečně velká vyrovnávací paměť. Také to ale nemusí být vždy žádoucí - někdy může být vhodné, či dokonce nutné odesílat menší celky než celé řádky, až např. po jednotlivé znaky. S touto možností protokol TELNET počítá, a doporučuje ji realizovat. Přesný mechanismus, kterým by si zdroj dat mohl vynutit jejich odeslání ještě před zakončením řádky, je však ponechán na konkrétní implementaci.

Ostatní je na vzájemné dohodě

Pro správné pochopení smyslu a role virtuálního terminálu NVT je velmi důležité si uvědomit to, co jsme si již naznačili v 66. dílu - že totiž každý virtuální terminál vždy omezuje "individualitu" konkrétních terminálů, a redukuje jejich vlastnosti a schopnosti na takovou úroveň, která může být společná prakticky všem fyzicky existujícím terminálům. Nejinak je tomu i v případě virtuálního terminálu NVT, který si proto můžeme představit jako největší společný jmenovatel všech ještě použitelných terminálů. Protokol TELNET jej však chápe jen jako "povinné minimum" a připouští, aby se obě strany mohly v konkrétním případě dohodnout "na lepším" - tedy na tom, že mají a jsou schopny používat nějaká rozšíření vůči tomu, co požaduje NVT.

Přitom ale platí zásada, že použití rozšíření (anglicky: options) si nelze vynucovat - každá strana má právo vznášet návrhy na jejich použití, ale druhá strana má vždy právo je odmítnout. Díky tomu je možné vystačit i s "hloupými" terminály, jejichž skutečné schopnosti nepřesahují minimum, požadované virtuálním terminálem NVT, a na druhé straně je možné efektivně využít možnosti a schopnosti lépe vybavených terminálů.

Bezprostředně po navázání spojení tedy obě strany mohou používat právě a pouze to, co jim zaručuje virtuální terminál NVT. Mohou však kdykoli zahájit "licitaci", v rámci které se dohodnou na použití oboustranně přijatelných rozšíření. Vzájemné domlouvání na použití různých rozšíření obvykle probíhá okamžitě po navázání spojení, ale není to nutnou podmínkou. Stejně tak se mohou obě strany kdykoli dohodnout na tom, že přestanou určité rozšíření používat. Zajímavá je v tomto ohledu také zásada rovnoprávnosti - každá ze stran má stejné právo navrhnout používání určitého rozšíření, a stejně tak může požadovat i ukončení používání určitého rozšíření (žádosti tohoto typu přitom nesmí být druhou stranou odmítnuty).

Protokol TELNET samozřejmě musí definovat konkrétní způsob, jakým mají obě strany postupovat při vzájemné "licitaci" (anglicky: options negotiation). Příslušný mechanismus je ovšem koncipován jako otevřený - nemůže totiž anticipovat všechna budoucí rozšíření, která budou připadat v úvahu, a tak pro ně nemůže přesně předepisovat konkrétní formu "licitace". Místo toho ponechává otevřený prostor pro individuální postupy vzájemného dohadování, ale současně s tím je umožňuje jednoznačně detekovat, tak aby druhá strana měla vždy možnost rozpoznat, že jde o nabídku používání rozšíření, a i když jí nerozumí, mohla ji odmítnout.

Sedmibitové znaky v osmibitových bytech

Pro kódování jednotlivých znaků používá protokol TELNET znakový kód ASCII. Požaduje, aby tiskárna (resp. zobrazovací zařízení) virtuálního terminálu NVT byla schopna znázornit všech 95 alfanumerických znaků ASCII (s kódy 32 až 127), a z 33 řídících znaků povinně vyžaduje interpretaci znaků NULL, CR a LF. Kromě toho stanovuje přesný význam i pro řídící znaky BEL (Bell), BS (Back Space), HT (Horizontal Tab), VT (Vertical Tab) a FF (Form Feed), a to v souladu s jejich významem v kódu ASCII - ovšem s tím, že interpretace těchto znaků není povinná (tj. tiskárna je nemusí interpretovat vůbec, ale pokud ano, pak jen stanoveným způsobem). Pro ostatní řídící znaky kódu ASCII je stanoveno, že nebudou mít na tiskárnu žádný efekt.

Po klávesnici virtuálního terminálu NVT je naopak požadováno, aby byla schopna generovat všech 128 znaků kódu ASCII (i když některé nemají na tiskárnu žádný efekt). Kromě toho je požadováno, aby klávesnice NVT generovala ještě i několik dalších znaků, které mají význam řídících příkazů protokolu TELNET (o nich bude řeč příště).

Jednotlivé znaky sedmibitového kódu ASCII jsou ovšem přenášeny zásadně v osmi bitech. Díky tomu je pak možné k nim "přidat" ještě i právě naznačené řídící příkazy (odlišené nastavením nejvyššího bitu). Jako jedno z možných rozšíření se ale obě strany mohou dohodnout na tom, že si budou předávat osmibitové znaky (tj. znaky, kódované v osmi bitech). Pak je ovšem nutné zajistit potřebnou transparenci - umožňující jednoznačně odlišit příkazy od "užitečných dat" - jiným způsobem.