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

FTP - I.

Nejprve si ale znovu zopakujme, v Φem je rozdφl mezi transparentnφm a netransparentnφm °eÜenφm: v p°φpad∞ netransparentnφho p°φstupu si u₧ivatel pln∞ uv∞domuje rozdφl mezi mφstnφmi soubory a soubory na vzdßlenΘm poΦφtaΦi, a musφ se sßm a explicitn∞ starat o jejich p°enos, zatφmco v p°φpad∞ netransparentnφho p°φstupu mφstnφ a vzdßlenΘ soubory spl²vajφ, pro u₧ivatele mezi nimi nenφ ₧ßdn² principißlnφ rozdφl, a veÜkerou agendu spojenou s p°edstφrßnφm tΘto iluze na sebe p°ebφrß sφ¥ov² software a operaΦnφ systΘm.

Minule jsme se ji₧ takΘ zmφnili o tom, ₧e sφ¥ov² model TCP/IP pamatuje na ob∞ varianty. Pro netransparentnφ variantu nabφzφ hned dva protokoly - protokol FTP (File Transfer Protocol, doslova: protokol pro p°enos soubor∙), kter² lze oznaΦit jako "plnohodnotn²", vybaven² mno₧stvφm r∙zn²ch schopnostφ a funkcφ, a dßle mnohem jednoduÜÜφ protokol TFTP (Trivial File Transfer Protocol), poskytujφcφ jen zßkladnφ funkce, ale zato implementaΦn∞ jednoduÜÜφ, a Φasto i rychlejÜφ. NaÜe povφdßnφ zaΦneme filosofiφ protokolu FTP.

FTP je starÜφ ne₧ TCP/IP

SprßvnΘ zasazenφ protokolu FTP do historickΘho rßmce nßm pom∙₧e snßze pochopit n∞kterΘ jeho koncepΦnφ rysy.

Jak se FTP vyrovnßvß s r∙znorodostφ

Protokol FTP se vyrovnßvß se vÜemi t∞mito odliÜnostmi v podstat∞ jedin²m mo₧n²m zp∙sobem: zavßdφ jednotn² tvar, ve kterΘm jsou data skuteΦn∞ p°enßÜena, a ponechßvß na obou koncov²ch ·Φastnφcφch, aby zajistili veÜkerΘ pot°ebnΘ p°evody z/do mφstnφch konvencφ.

Zßrove≥ ale protokol FTP vychßzφ vst°φc i p°φpad∙m, kdy by jedin² a nem∞nn² p°enosov² tvar byl neefektivnφ, a umo₧≥uje jej v urΦitΘm rozmezφ a po dohod∞ obou stran m∞nit. V podstat∞ lze °φci, ₧e tento p°enosov² tvar mß t°i stupn∞ volnosti: re₧im p°enosu, strukturu soubor∙ a reprezentaci dat.

Reprezentace dat

Protokol FTP implicitn∞ p°edpoklßdß, ₧e p°enßÜenß data p°edstavujφ ASCII text. Ten se pak skuteΦn∞ p°enßÜφ v tom formßtu, kter² pro ASCII text po₧aduje protokol Telnet (viz 68. dφl). JednotlivΘ znaky jsou tedy p°enßÜeny jako 8-bitovΘ, a °ßdky jsou odd∞lovßny dvojicφ znak∙ CRLF. Odesilatel proto musφ p°evßd∞t jednotlivΘ znaky z takovΘho k≤du a zp∙sobu zobrazenφ, jak² pou₧φvß jeho poΦφtaΦ, na prßv∞ popsan² p°enosov² tvar (tj. p°evßd∞t je do k≤du ASCII, uklßdat po jednom do osmi bit∙, a p°echody na novΘ °ßdky reprezentovat dvojicφ znak∙ CR a LF). Analogicky se musφ chovat i p°φjemce.

Protokol FTP vÜak umo₧≥uje, aby se ob∞ strany dohodly na jinΘm v²znamu p°enßÜen²ch dat. Mo₧nosti jsou nßsledujφcφ:

• text v k≤du EBCDIC (p°enßÜenß data jsou tvo°ena jednotliv²mi znaky, tyto jsou op∞t znßzorn∞ny v 8 bitech, ale pro jejich k≤dovßnφ je mφsto znakovΘho k≤du ASCII pou₧it znakov² k≤d EBCDIC). Tato varianta vychßzφ vst°φc p°enos∙m text∙ mezi st°ediskov²mi poΦφtaΦi IBM, kterΘ pou₧φvajφ prßv∞ znakov² k≤d EBCDIC, a eliminuje tak dvojφ konverzi ka₧dΘho znaku.
• binßrnφ data (tzv. image type). V tomto p°φpad∞ ob∞ strany chßpou p°enßÜenß data jako spojitou posloupnost bit∙, kterΘ jsou Φlen∞ny na 8-bitovΘ byty jen pro pot°eby vlastnφho p°enosu.
• byty nestandardnφ velikosti (tzv. local byte). V tomto p°φpad∞ m∙₧e odesilatel stanovit, jak velkΘ byty sßm pou₧φvß, a dßt p°φjemci mo₧nost se tomu p°izp∙sobit. Nap°φklad poΦφtaΦ, kter² pracuje s 36-bitov²mi slovy, m∙₧e na tuto skuteΦnost upozornit p°φjemce, a ten pak m∙₧e nap°φklad uklßdat jednotlivß 36-bitovß slova do dvou 32-bitov²ch slov apod. Zde je ovÜem t°eba si uv∞domit, ₧e jde jen o "logickou" velikost bytu, kterß slou₧φ ob∞ma stranßm jako vodφtko pro provßd∞nφ pot°ebn²ch konverzφ. Nastavenφ nestandardnφ velikosti bytu nemß ₧ßdn² vliv na skuteΦnost, ₧e vlastnφ data jsou doopravdy p°enßÜena v 8-bitov²ch bytech.

Struktura soubor∙

V tΘto souvislosti je op∞t t°eba mφt na pam∞ti, ₧e r∙znΘ systΘmy mohou pro jeden a tent²₧ druh souboru pou₧φvat jinou vnit°nφ strukturu - nap°φklad texty se na v∞tÜin∞ poΦφtaΦ∙ uchovßvajφ v textov²ch souborech, tvo°en²ch lineßrnφ posloupnostφ jednotliv²ch znak∙ (byt∙), ale nap°φklad na st°ediskov²ch poΦφtaΦφch IBM jsou textovΘ soubory organizovßny jako posloupnosti zßznam∙ pevnΘ dΘlky. I zde pak musφ nastoupit vhodnΘ konverze na jednΘ stran∞ Φi na obou souΦasn∞, ale op∞t platφ zßsada, ₧e ka₧d² musφ v∞d∞t, co se vlastn∞ p°enßÜφ.

Pokud nenφ °eΦeno jinak, protokol FTP implicitn∞ p°edpoklßdß, ₧e p°enßÜen² soubor nemß ₧ßdnou vnit°nφ strukturu, a je tvo°en lineßrnφ posloupnostφ jednotliv²ch datov²ch byt∙ (tato mo₧nost je oznaΦovßna jako file structure). DalÜφ mo₧nosti, na kter²ch se mohou z·Φastn∞nΘ strany dohodnout, je soubor Φlen∞n² na sekvenΦnφ zßznamy (record structure) a soubor, Φlen∞n² na strßnky (page structure).

Re₧im p°enosu

Implicitnφ re₧im p°enosu (oznaΦovan² jako stream mode) je takov², kdy p°enßÜenß data jsou chßpßna jen jako spojit² proud (stream) byt∙, a jako takovß jsou takΘ p°enßÜena.

Je ovÜem mo₧n∞ zvolit i jin² re₧im (blokov² re₧im, block mode), p°i kterΘm jsou p°enßÜenß data Φlen∞na do blok∙, a ka₧d² z nich je opat°en hlaviΦkou (kterß obsahuje mj. ·daj o dΘlce bloku, p°φznak poslednφho bloku apod.). V tomto re₧imu je pak mo₧nΘ vklßdat mezi bloky, obsahujφcφ vlastnφ data, i malΘ specißlnφ bloky (identifikovanΘ p°φznakem ve svΘ hlaviΦce), kterΘ ve skuteΦnosti slou₧φ jako zßlo₧ky (kontrolnφ body). Po v²padku spojenφ a jeho nßslednΘm obnovenφ je pak mo₧nΘ vyu₧φt existence t∞chto znaΦek k indikaci mφsta, odkud mß b²t p°eruÜen² p°enos opakovßn.

T°etφm mo₧n²m re₧imem p°enosu je tzv. zhuÜt∞n² re₧im (compressed mode), p°i kterΘm jsou p°enßÜenß data komprimovßna. Nejde vÜak o ₧ßdnou propracovanou a efektivnφ kompresnφ techniku, jakΘ znßme ze souΦasnΘ doby, ale jen o pouhou eliminaci znak∙, kterΘ se opakujφ n∞kolikrßt za sebou (typick²m p°φkladem jsou posloupnosti mezer v textov²ch souborech). Takovßto posloupnost stejn²ch znak∙ je pro pot°eby p°enosu nahrazena pouze jednφm exemplß°em p°φsluÜnΘho znaku a ·dajem o tom, kolikrßt se v originßle opakuje.