VyÜlo v t²denφku: COMPUTERWORLD
╚φslo:29/93
RoΦnφk:1993
Rubrika/kategorie: Co je Φφm ... v poΦφtaΦov²ch sφtφch
Dφl:69
zp∞t do archivu Φlßnk∙ | rejst°φk | p°edchozφ dφl | nßsledujφcφ dφl

Ji°φ Peterka: Co je Φφm ... v poΦφtaΦov²ch sφtφch (69):

TELNET - III.

V minulΘm dφlu jsme se zab²vali virtußlnφm terminßlem NVT protokolu TELNET. Dosp∞li jsme k p°edstav∞, ₧e jde jen o jistΘ "povinnΘ minimum", jeho₧ mo₧nosti a schopnosti si mohou ob∞ strany na zßklad∞ vzßjemnΘ dohody rozÜφ°it. Dnes se ji₧ dostaneme ke konkrΘtnφm mechanism∙m, kterΘ se p°itom pou₧φvajφ.

Na ·vod je vhodnΘ si znovu zd∙raznit, ₧e veÜkerß komunikace mezi klientskou a serverovou slo₧kou protokolu TELNET mß zßsadn∞ charakter p°enosu znak∙. Majφ-li pak b²t v takovΘmto prost°edφ implementovßny jakΘkoli °φdφcφ mechanismy a postupy, musφ mφt p°φsluÜnΘ °φdφcφ p°φkazy i veÜkerΘ reakce na n∞ op∞t povahu znak∙. Musφ vÜak b²t zajiÜt∞na takΘ pot°ebnß transparence dat - musφ b²t mo₧nΘ jednoznaΦn∞ rozliÜit, kterΘ znaky p°edstavujφ "u₧iteΦnß data" a kterΘ naopak p°edstavujφ °φdφcφ p°φkazy.

Tv∙rci protokolu TELNET m∞li v zßsad∞ dv∞ mo₧nosti, jak tohoto cφle dosßhnout. Jednou bylo p°isoudit v²znam °φdφcφch p°φkaz∙ n∞kter²m ASCII znak∙m. Tφm by se ale p°ipravili o mo₧nost pou₧φvat tytΘ₧ znaky v jejich p∙vodnφm v²znamu, kter² majφ v k≤du ASCII, a navφc by si tφm dosti omezili mo₧n² repertoßr vlastnφch °φdφcφch p°φkaz∙ (proto₧e takto vyu₧iteln²ch znak∙ ASCII je jen velmi omezen² poΦet). Proto se auto°i protokolu TELNET rad∞ji rozhodli pro druhou mo₧nost, kterou p°edstavuje samostatnΘ k≤dovßnφ °φdφcφch p°φkaz∙, nezßvislΘ na k≤du ASCII.

ZajiÜt∞nφ transparence

Jak jsme si ji₧ uvedli minule, protokol TELNET p°enßÜφ jednotlivΘ znaky v osmibitov²ch bytech. Znaky k≤du ASCII jsou vÜak jen sedmibitovΘ, a pro pot°eby p°enosu se dopl≥ujφ nejvyÜÜφm bitem, nastaven²m na nulu. Pro k≤dovßnφ sv²ch °φdφcφch p°φkaz∙ se pak tv∙rc∙m protokolu TELNET nabφzelo vÜech 128 mo₧n²ch 8-bitov²ch hodnot, s nejvyÜÜφm bitem nastaven²m na jedniΦku - a tuto mo₧nost takΘ skuteΦn∞ vyu₧ili. Zde je ovÜem d∙le₧itΘ si uv∞domit, ₧e virtußlnφ terminßl NVT sice p°edpoklßdß pouze p°enos sedmibitov²ch ASCII znak∙, ale ₧e jednou z mo₧nostφ rozÜφ°enφ je p°enos osmibitov²ch znak∙. Jakmile se ale toto rozÜφ°enφ pou₧ije, okam₧it∞ se tφm ztrßcφ automatickΘ rozliÜenφ mezi "u₧iteΦn²mi" znaky a °φdφcφmi p°φkazy podle hodnoty nejvyÜÜφho (p°esn∞ji: nejv²znamn∞jÜφho) bitu.

Samotn² zp∙sob k≤dovßnφ °φdφcφch p°φkaz∙ tedy jeÜt∞ nemohl zajistit pot°ebnou transparenci dat, a proto tv∙rc∙m protokolu TELNET nezbylo ne₧ pou₧φt °eÜenφ, obvyklΘ nap°. u znakov∞ orientovan²ch linkov²ch protokol∙ Φi u °φdφcφch jazyk∙ pro ovlßdßnφ tiskßren a obdobn²ch znakov∞ orientovan²ch za°φzenφ: p°ed samotn² °φdφcφ znak za°adit specißlnφ znak, kter² zm∞nφ interpretaci jednoho, resp. n∞kolika nßsledujφcφch znak∙. V p°φpad∞ tiskßren jde o znak ESCAPE (s ASCII k≤dem 27, resp. 1B hexadecimßln∞), kter² uvozuje tzv. ESCAPE sekvence, zatφmco u linkov²ch protokol∙ jde o znak DLE (Data Link ESCAPE, s ASCII k≤dem 16, resp. 10 hexadecimßln∞), kter² prefixuje °φdφcφ znaky zaΦßtku a konce rßmce apod. V p°φpad∞ protokolu TELNET byl zvolen znak s Φφseln²ch k≤dem 255 (resp. FF hexadecimßln∞), oznaΦovan² jako IAC (Interpret As Command, dolova: interpretuj jako °φdφcφ p°φkaz), kter² povinn∞ uvozuje vÜechny °φdφcφ p°φkazy. Pokud by se Φφseln² k≤d tohoto znaku (tj. k≤d 255) vyskytl v "u₧iteΦn²ch" datech, musφ b²t zdvojen, Φφm se zamezφ jeho interpretaci jako uvozujφcφho znaku °φdφcφho p°φkazu.

P°φkazy protokolu TELNET

V∞tÜina °φdφcφch p°φkaz∙ protokolu TELNET je reprezentovßna jednφm °φdφcφm znakem, ke kterΘmu se p°idßvß povinn² prefix - znak IAC - tak₧e nekratÜφ p°φkaz je tvo°en dv∞ma osmibitov²mi byty. Existujφ ovÜem i p°φkazy, pro jejich₧ vyjßd°enφ jedin² °φdφcφ znak nestaΦφ, a je nutnΘ pou₧φt jeÜt∞ jeden dodateΦn² znak. I v tomto p°φpad∞ se ale pou₧φvß jedin² uvozujφcφ znak IAC, tak₧e v²sledn² p°φkaz je tvo°en t°emi byty. Pro jeÜt∞ "delÜφ" p°φkazy se pak ji₧ pou₧φvß pon∞kud odliÜn² mechanismus, se kter²m se seznßmφme poslΘze.

Podle svΘho v²znamu spadajφ °φdφcφ p°φkazy protokolu TELNET do t°φ skupin, mezi:

Na poslednφ skupinu se nynφ zam∞°φme podrobn∞ji.

Licitace o rozÜφ°enφ

Jak jsme si ji₧ naznaΦili minule, pou₧itφ nejr∙zn∞jÜφch rozÜφ°enφ oproti virtußlnφmu terminßlu NVT je nepovinnΘ. Ka₧dß ze stran mß prßvo navrhnout pou₧itφ takovΘho rozÜφ°enφ, jakΘ uznß za vhodnΘ, ale druhß strana mß plnΘ prßvo jej odmφtnout. V²razn² prvek demokratiΦnosti je pak i v tom, ₧e prßvo navrhovat pou₧itφ rozÜφ°enφ mß nejen slo₧ka v roli klienta, ale i slo₧ka v roli serveru - ob∞ strany majφ v tomto ohledu rovnoprßvnΘ postavenφ.

Zajφmav² je i konkrΘtnφ zp∙sob vzßjemnΘ "licitace". Ta strana, kterß chce iniciovat pou₧itφ urΦitΘho rozÜφ°enφ, mß dv∞ mo₧nosti: navrhnout, ₧e sama p°ijme n∞jakΘ opat°enφ (tj. sama zaΦne pou₧φvat p°φsluÜnΘ rozÜφ°enφ), a ptßt se druhΘ strany, zda s tφm souhlasφ, nebo naopak navrhnout druhΘ stran∞, aby ona p°ijala urΦitΘ opat°enφ. Uka₧me si na p°φkladu, v Φem m∙₧e spoΦφvat rozdφl, a proΦ je v∙bec nutnΘ jej uva₧ovat: virtußlnφ terminßl NVT p°edpoklßdß, ₧e ka₧dß strana bude pou₧φvat tzv. lokßlnφ echo (local echo) - tedy ₧e veÜkerΘ znaky, zadanΘ z klßvesnice, si bude sama ihned zobrazovat na svΘm displeji (resp. tisknout na tiskßrn∞, kterou p°edpoklßdß NVT), a souΦasn∞ s tφm je odesφlat druhΘ stran∞. Dφky tomu u₧ivatel okam₧it∞ vidφ, co vlastn∞ z klßvesnice zadal, a co se druhΘ stran∞ odeslalo. Alternativa je takovß, ₧e zadan² znak je pouze odeslßn druhΘ stran∞, a teprve ta jej zase poÜle zp∞t k zobrazenφ na displeji u₧ivatelova terminßlu. Pou₧φvßnφ tΘto techniky, oznaΦovanΘ jako tzv. vzdßlenΘ echo (remote echo), je jednφm z mo₧n²ch rozÜφ°enφ virtußlnφho terminßlu NVT. Je ovÜem zßsadnφ rozdφl mezi tφm, kdy jedna strana navrhne druhΘ, ₧e ona bude provßd∞t vzdßlenΘ echo (tj. ₧e bude posφlat zp∞t ka₧d² znak, kter² od druhΘ strany dostane), a kdy vzdßlenΘ echo po₧aduje na druhΘ stran∞.

N∞kterß rozÜφ°enφ virtußlnφho terminßlu NVT, jako prßv∞ naznaΦenΘ pou₧φvßnφ tzv. vzdßlenΘho echa, majφ asymetrick² charakter, a mohou b²t pou₧φvßny ob∞ma stranami souΦasn∞, ₧ßdnou z nich, nebo jen jednou ze z·Φastn∞n²ch stran. Naproti tomu jinß rozÜφ°enφ majφ symetrick² charakter, a musφ je pou₧φvat bu∩ ob∞ strany souΦasn∞, nebo ₧ßdnß.

Protokol TELNET nabφzφ celkem Φty°i p°φkazy, pomocφ kter²ch mohou ob∞ strany "licitovat" o pou₧itφ rozÜφ°enφ. Jsou to po p°φkazy:

P°φkazy WON'T a DON'T jsou tedy zßporn²mi odpov∞∩mi na v²zvu, vyjßd°enou po °ad∞ p°φkazy DO a WILL. JakΘ jsou ale kladnΘ odpov∞di? Kladnou odpov∞dφ na p°φkaz DO (v²zvu "d∞lej") je p°φkaz WILL (tj. "budu"), a naopak kladnou odpov∞dφ na p°φkaz WILL (nabφdku "budu") je p°φkaz DO (tj. "d∞lej").

Identifikace rozÜφ°enφ

P°φkazy WILL, DO, WON'T a DON'T samy o sob∞ jeÜt∞ neurΦujφ jednu velmi podstatnou v∞c - o jakΘ konkrΘtnφ rozÜφ°enφ se jednß. Toto je urΦeno a₧ dalÜφm rozliÜujφcφm parametrem (ve skuteΦnosti Φφseln²m k≤dem v rozsahu jednoho osmibitovΘho bytu), kter² nßsleduje bezprost°edn∞ za vlastnφmi p°φkazy. Tak₧e nap°φklad nabφdka jednΘ strany, ₧e bude druhΘ stran∞ zajiÜ¥ovat vzdßlenΘ echo, se symbolicky zapisuje jako 
IAC WILL ECHO
a ve skuteΦnosti se vysφlß jako trojice byt∙ s hodnotami po °ad∞ 255, 251 a 1 (kde 255 je k≤d uvozujφcφho znaku IAC, 251 je k≤d p°φkazu WILL, a 1 je k≤d rozÜφ°enφ o vzdßlenΘ echo). Druhß strana v p°φpad∞ souhlasu odpovφ sekvencφ 
IAC DO ECHO
(Φφseln∞: 255 253 1), a v p°φpad∞ nesouhlasu sekvencφ 
IAC DON'T ECHO
(Φφseln∞: 255 254 1).

Obdobn∞ po₧adavek jednΘ strany, aby pro ni druhß strana zajiÜ¥ovala vzdßlenΘ echo, by m∞l tvar 

IAC DO ECHO
(Φφseln∞: 255 253 1). Druhß strana akceptuje tuto v²zvu sekvencφ 
IAC WILL ECHO
(Φφseln∞: 255 251 1), resp. odmφtß ji pomocφ 
IAC WON'T ECHO
(Φφseln∞: 255 252 1). Aby se zabrßnilo mo₧nΘmu zacyklenφ, kdyby jedna strana pova₧ovala odpov∞∩ druhΘ strany za novou ₧ßdost, je zavedeno nßsledujφcφ pravidlo: na ₧ßdost o pou₧itφ takovΘho rozÜφ°enφ, kterΘ ji₧ je pou₧φvßno, se neodpovφdß nijak.

PoΦet a v²znam jednotliv²ch rozÜφ°enφ nenφ p°edem stanoven. Novß rozÜφ°enφ mohou vznikat a skuteΦn∞ vznikajφ na zßklad∞ skuteΦn²ch pot°eb a v²voje v²poΦetnφ techniky. Pro jejich koordinaci vÜak musφ existovat jedinß centrßlnφ autorita, kterß jim p°id∞luje jejich ΦφselnΘ k≤dy. Tou je pan John Postel z University of Southern California, autor mnoha standard∙ Internetu, vydßvan²ch ve form∞ tzv. RFC dokument∙.

Podrobn∞jÜφ licitace

Z n∞kter²ch zajφmav²ch rozÜφ°enφ (kterΘ uvßdφ tabulka 69.1) stojφ za zmφnku nap°. mo₧nost dohodnout se na pou₧itφ konkrΘtnφho typu terminßlu (s v∞tÜφm repertoßrem schopnostφ a mo₧nostφ, ne₧ jakΘ nabφzφ "zßkladnφ NVT"). V souΦasnΘ dob∞, kdy je velkß Φßst terminßlov²ch relacφ zajiÜ¥ovßna prost°ednictvφm terminßlovΘ emulace (viz 65. dφl), a p°φsluÜnΘ emulßtory jsou Φasto schopny emulovat vφce r∙zn²ch terminßl∙, je dokonce ₧ßdoucφ, aby se ob∞ strany mohly dohodnout na pou₧itφ nejvhodn∞jÜφho terminßlu.

Pro tyto ·Φely vÜak ji₧ nenφ v²Üe naznaΦen² mechanismus dostateΦn². Umo₧≥uje pouze to, aby se ob∞ strany dohodly na tom, ₧e se v∙bec cht∞jφ (a um∞jφ) domlouvat na typu terminßlu. PotΘ musφ nßsledovat druhß fßze "licitace" (v angliΦtin∞ oznaΦovanß jako subnegotiation), v rßmci kterΘ se ji₧ mohou podrobn∞ji domlouvat na konkrΘtnφch parametrech. V p°φpad∞ volby typu terminßlu by v rßmci tΘto druhΘ fßze slo₧ka v roli klienta p°edklßdala slo₧ce v roli serveru jednotlivΘ typy terminßl∙, kterΘ je schopna emulovat, a server by si z nich vybφral tu, kterou pova₧uje ze svΘho pohledu za nejv²hodn∞jÜφ.

Obdobnß ·vaha platφ i pro jinß rozÜφ°enφ: nap°φklad pro stanovenφ velikosti displeje, kde se konkrΘtnφ poΦet °ßdek na strßnce a poΦet znak∙ na °ßdce sd∞luje op∞t v druhΘ fßzi (subnegotiation) "licitace".

KonkrΘtnφ forma tΘto druhΘ fßze nenφ p°edepsßna, nebo¥ je urΦena a₧ pot°ebami p°φsluÜnΘho rozÜφ°enφ. Zßvazn² je pouze zp∙sob zajiÜt∞nφ transparence: posloupnost znak∙, p°edßvan²ch v rßmci druhΘ fßze "licitace", musφ b²t uvozena °φdφcφm znakem SB (Start of Subnegotiation), a zakonΦena znakem SE (End of Subnegotiation). Oba tyto znaky p°itom musφ b²t samy prefixovßny znakem IAC.

Symb. oznaΦenφ Φφseln² k≤d v²znam
TRANSMIT-BINARY 0 p°enos 8-bitov²ch znak∙ (resp. binßrnφch dat)
ECHO 1 tzv. vzdßlenΘ echo (viz text)
STATUS 5 toto rozÜφ°enφ umo₧≥uje, aby jedna strana vysφlala druhΘ stran∞ informace o svΘmu stavu (tzv. status), resp. aby si jedna strana vy₧ßdala od druhΘ informace o jejφm stavu
TERMINAL-TYPE24dφky tomuto rozÜφ°enφ se z·Φastn∞nΘ strany mohou dohodnout na typu pou₧φvanΘho terminßlu
NAWS31 (Negotiate About Window Size), toto rozÜφ°enφ umo₧≥uje z·Φastn∞n²m stranßm dohodnout se na velikosti displeje terminßlu
TERMINAL-SPEED 32 obdobn∞, pro p°enosovou rychlost terminßlu
TOGGLE-FLOW-CONTROL 33 toto rozÜφ°enφ umo₧≥uje z·Φastn∞n²m stranßm dynamicky m∞nit zp∙sob °φzenφ toku
EXTENDED-OPTIONS-LIST 255 toto rozÜφ°enφ je ve skuteΦnosti mechanismem, pomocφ kterΘho lze zv²Üit poΦet mo₧n²ch rozÜφ°enφ nad 255
Tabulka 69.1: P°φklady rozÜφ°enφ virtußlnφho terminßlu NVT protokolu TELNET

zp∞t do archivu Φlßnk∙ | rejst°φk | p°edchozφ dφl | nßsledujφcφ dφl
Tento Φlßnek m∙₧e b²t voln∞ Üφ°en, pokud se tak d∞je pro studijnφ ·Φely, na nev²d∞leΦnΘm zßklad∞ a se zachovßnφm tohoto dov∞tku. Podrobnosti hledejte zde, resp. na adrese http://archiv.czech.net/copyleft.htm