Původně jsem chtěl použít slova mýtus. To by však nebylo přesné. Biblická řečtina označuje tímto slovem informace, o nichž víme, že jsou vymyšlené. Legendy jsou jiné. Ony události se opravdu staly. Nestaly se sice přesně tak, jak se to vypráví, ale přenechme historickou přenost historikům. Nám ostatním stačí, že se hezky poslouchají.
FSP protokol je jediný z Internet protokolů používaných v minulosti, o kterém se vyprávějí dodnes legendy. Internet protokolů, které již dnes nepoužíváme, je celá řada: gopher, gopher+, pop2, talk, telnet, rsh, rexec, rlogin, … O žádném z nich se však nevyprávějí takové příběhy, jako se vyprávějí o FSP. Ono by to ani moc dobře nešlo, na to jsou tyto protokoly příliš známé. FSP je však pro vyprávění legend ideální: Mladší ho neznají, starší si sice vzpomenou, že něco jako FSP kdysi existovalo, ale nikdo z publika (a většinou ani vypravěč) neví, jak to přesně pracovalo. Ostatně to nikoho ani moc nezajímá, vždyť legendy nikdo neposlouchá kvůli jejich historické či faktické přesnosti, že?
A tak se společně přenesme do dob ne tak dávno minulých, kdy byly linky pod psa, modemy pro kočku, telefoní linky na draka, místní hovory za korunu a mobil vážil dvě kila. Přenesme se do devadesátých let.
Skvělá 90. léta minulého století
V těchto letech se touha vzájemně propojovat počítače postupně přesunovala do větších dálek, směrem od LAN sítí k WAN sítím. Vždyť kdo by netoužil po komunikaci s lidmi z druhé strany zeměkoule. Říkalo se tomu tehdy informační superdálnice. U nás v Čechách jsme však místo slíbené dálnice neměli ani okresky, vypadalo to spíš jako polní cesta, sjízná pouze traktorem. To se však zdaleka netýkalo pouze WAN sítí.
V těchto dobách se považovalo za velký úspěch vůbec nějaká ta data modemem přenést. Telefoní linky se vyznačovaly takovou nespolehlivostí, že místo přenosu dat modemem se praktikoval tzv. „kabelový přenos“ – diskety se vložily do kabely a kabela se přemístila na druhý konec Prahy s pomocí automobilu. Bylo to tak mnohem rychlejší.
Modemy
Modemy se vyskytovaly nejčastěji ve dvou provedeních: 2400 a 9600 baudů. Modemy 2400 byly vynikající – spolehlivě pracovaly i na našich telefoních linkách. Slovo spolehlivě v tomto případě znamenalo, že se udržely on-line desítky minut. Pomalé, ale dobře držely. Pro budování WAN sítí založených na IP protokolu byly ovšem zcela nepoužitelné. Dobře se hodily pro komunikaci s BBS, pro uzly sítě Fidonet a sem tam pro UUCP.
Síť FidoNet byla neinteraktivní a nabízela několik služeb: Přenos soukromých zpráv – Netmailů, přenos konferencí – Echo mailů, přenos souborů – File Request a souborové konference – File echa. File echa dodnes nemají na Internetu žádný ekvivalent – alt.binaries bych s nimi rozhodně nesrovnával, což je docela škoda.
Unixový svět měl také neinteraktivní celosvětovou síť založenou na UUCP. Fidonet ji ale předčil, a to jak technologicky, tak co do spolehlivosti. Po Fidonetu jste si mohli posílat Netmaily do USA, což s UUCP šlo snad jen teoreticky, já jsem nikdy takové štěstí neměl. Mně se Fidonet velmi líbil a používal jsem ho cca do roku 1999.
WAN sítě
Ti šťastnější, kdož měli 9600 modem, kvalitní telefoní linku, která udržela modem on-line touto rychlostí alespoň desítky minut, a u někoho (načerno) zařízené připojení k Internetu, mohli s pomocí IP packetů objevovat země vzdálené. Zažívali podobně jako radioamatéři hezký pocit z navázaného spojení následovaný dotazem: Kam jsem se to až dostal? Německo? Švýcarsko? Francie? Amerika?
Pokuď jde o služby Internetem poskytované, není mezi současností a námi popisovanou dobou velký rozdíl: Odečtěte si WWW, MIME, SSH, CVS, peer to peer technologie, Google a přidejte archie, gopher, veronicu a … FSP!
Přenosy souborů
Nejzajímavější věcí, kterou Internet tehdy umožňoval, bylo přenášení souborů, které jsme tak dobře znali z BBS. Na BBS nás otravovaly různé download limity a zde se stačilo jen přihlásit na vzdálený počítač pomocí anonymního FTP a začít sosat. Vypadalo to velice slibně, ovšem v praxi se často ukázalo jednodušší si potřebné soubory raději stáhnout z BBS.
Úskalí FTP
Z předchozího textu je jasné, že Internet linky byly neskutečně pomalé. 9600 modemem byla často připojená celá lokální síť, tím pádem také neskutečně vytížené a jako následek toho všecho tu byl neskutečně vysoký packet loss, a když spadla telefoní linka, tak i několikaminutový lag, než se modem znovu spojil, pokud se vůbec spojil.
Zážitky s FTP začínaly snahou o navázání spojení. Předtím je ještě nutné resolvnout hostname, ale většina FTP archivů uváděla pro jistotu i IP adresu, protože v některých denních dobách pokus o spojení vyhučel už na resolvingu. Pokus o spojení byl následován zásadou pěti minut. Pokud se do pěti minut FTP server neozval bannerem, nemělo cenu dále čekat.
Další fází bylo přihlášení. Servery měly ve zvyku omezovat počet anonymních uživatelů obvykle na deset, např. u simtel20.army.mil, ale našly se i servery s nižším počtem. Pokud některý server povoloval více než dvacet, bylo to něco opravdu výjimečného. Osud nám obvykle nakloněn nebyl, pokud měl server vysoký limit, nestál jeho obsah ani za SYN packet.
Tím trable s přenosem dat neskončily. Potřebujete si totiž vypsat obsah aktuálního adresáře. FTP server k tomu potřebuje navázat nové TCP spojení, a pokud se nedostal na váš počítač v dostatečně rozumném čase, přičemž jeho názor na rozumný časový limit se lišil od vašeho, vykopnul vás. Tyhlety havárie byly nejfrustrující. Chtělo to omezit výpisy adresářů na nezbytné minimum.
Přenos souboru začal optimisticky – pokud linky úspěšně zvládly výpis adresáře, nastartování přenosu souboru jim nečinilo zvláštní problém. Jedna věc je přenos zahájit a úspěšné dokončení věc druhá. Na IP packety na jejich dlouhé cestě k vám čekala nebezpečí ve formě závalů na trati, lagů, vykopnuté šíťové kabeláže, retrainujících modemů, zlých telefoních linek. Mortalita se pohybovala těsně pod 50 procenty (pozn. red.: skoro jak CZFree ;) –Johanka).
TCP stack se po seznámení s touto situací rozhodl zasílat packety exponenciálně pomaleji, takže bylo jen otázkou času, kdy resend timeouty TCP stacku převýší 5minutový timeout serveru, po kterém se s námi FTP server pokusil o rozloučení, které se zmaterializovalo ve formě RST packetu jen zcela výjimečně. Přenos souboru tak hezky rychle začínal a tak neslavně končil.
Jistě jste z předchozího vyprávění vytušili, že rychlosti přenosu nebyly právě kosmické. Pokud se přenosovka do zahraničí přešvihla přes 100B/s, bylo to považováno za velmi rychlý přenos. Běžně se pohybovala okolo 50–80 B/s. Pokud klesla pod 50, tak si TCP stack vzal timeout a přenos odpískal. Přenos po Čechách byl rychlejší, řekněme tak 300B-1K/sec, a hlavně mnohem spolehlivější. Problém byl ten, že mirrorů v Čechách bylo pramálo, a to, co jste potřebovali, v nich většinou neměli.
Postupně se však situace s mirrory v Čechách zlepšovala, a tak se vyplácela jejich prohlídka před výletem do krajů vzdálených. Jedním z mých oblíbených byl ftp.vslib.cz, který kromě velice slušné přenosové rychlosti posílal při přihlášení i výhrůžky těm, kteří se pokusí stáhnout /etc/passwd. Neodolal jsem a již při druhém přihlášení jsem si pořídil jeho kopii, a to i přes protesty FTP serveru, který mi po cd /etc přidal ještě další dávku výhrůžek.
Funkci resume FTP klienti tehdy ještě neměli, s tou jsem se setkal poprvé u NCFTP o mnoho let později. V té době byly už linky CESNETu v takovém stavu, že jim nedělalo problém přenášet megabajtové soubory na jeden zátah přes den, a to i z takových problémových zemí jako bylo Německo. Kde bylo resume v době, kdy jsem ho nejvíc potřeboval? Když mohl mít resume ZMODEM, tak proč ho v té době nemělo FTP?
Vzhledem k výše uvedeným okolnostem je jasné, že dlouhé soubory se nedaly stáhnout vůbec. Podle délky jsme soubory dělili do několika kategorií: tutovky do 100 KB, normální do 300 KB, možná to vyjde 500–700 KB a na nedělní do 1200 KB. Na soubory větších velikostí jsme jen mlsně koukali při výpisu adresářů…
Tímto jsem vás dostatečně obeznámil s problémy spojenými s FTPčkováním v raných dobách, protože bez pochopení FTP a 90. let je nemožné pochopit FSP. FSP mělo totiž cosi do činění s přenášením souborů.
V dalším dílu uvidíte
Ne všem se tato situace líbila. Hrdina počítačové revoluce Wen-King Su tyto problémy úspěšně zanalyzoval a nakódoval řešení, které pustil ho do světa pod názvem FSP. Jeho vynikající dílo, FSP, se rychle rozšířilo a diplomaticky řečeno vyvolalo různé pocity na různých místech. O tom však přístě.
ČLÁNKY DO MAILU