VyÜlo v t²denφku: | COMPUTERWORLD |
╚φslo: | 1/93 |
RoΦnφk: | 1993 |
Rubrika/kategorie: | Co je Φφm ... v poΦφtaΦov²ch sφtφch |
Dφl: | 55 |
A₧ doposud jsme v naÜich ·vahßch p°edpoklßdali, ₧e prvotnφmi odesilateli a koneΦn²mi p°φjemci nejr∙zn∞jÜφch dat v poΦφtaΦov²ch sφtφch jsou jednotlivΘ uzlovΘ poΦφtaΦe jako takovΘ. Nynφ si vÜak musφme tuto p°edstavu up°esnit: skuteΦn²mi odesilateli a p°φjemci jsou entity aplikaΦnφ vrstvy. Tyto mohou b²t oznaΦovßny r∙zn∞: jako procesy (processes), ·lohy (tasks), aplikaΦnφ programy (application programs) Φi jeÜt∞ jinak. PodstatnΘ ovÜem je, ₧e v prost°edφ vφce·lohov²ch operaΦnφch systΘm∙ takov²chto entit m∙₧e b²t (a takΘ b²vß) vφce. Oba protokoly transportnφ vrstvy pak pot°ebujφ podle n∞Φeho rozhodnout, kterΘ entit∞ aplikaΦnφ vrstvy majφ p°ijatß data p°edat.
Adresovat data konkrΘtnφm proces∙m tedy nenφ p°φliÜ rozumnΘ. JakΘ jsou ale alternativy?
Sφ¥ov² model TCP/IP pou₧φvß prßv∞ tento mechanismus, a p°φsluÜnΘ "p°echodovΘ body" oznaΦuje jako porty (ports).
Z pohledu procesu, kter² je prßv∞ p°ipojen k urΦitΘmu portu, se tento jevφ jako vyrovnßvacφ pam∞¥ s re₧imem fronty - entita transportnφ vrstvy uklßdß data do portu z jednΘ strany, a entita aplikaΦnφ vrstvy (tj. proces) si je ve stejnΘm po°adφ zase odebφrß - viz obr. 55.1. Analogicky i pro opaΦn² sm∞r p°enosu. Samotn² port s prßv∞ naznaΦen²mi vlastnostmi je sßm o sob∞ datovou strukturou, a jako takov² m∙₧e dynamicky vznikat i zanikat, obdobn∞ jako vlastnφ procesy.
Otßzkou ovÜem je, jak m∙₧e aplikaΦnφ proces na jednom hostitelskΘm poΦφtaΦi zjistit pot°ebnß Φφsla port∙ na jinΘm poΦφtaΦi, a¥ ji₧ chce vyu₧φt n∞kterou z jφm poskytovan²ch slu₧eb, nebo jinak komunikovat s n∞kter²m z aplikaΦnφch proces∙ na tomto jinΘm poΦφtaΦi.
K °eÜenφ tΘto otßzky jsou v zßsad∞ dva mo₧nΘ p°φstupy. Prvnφ z nich spoΦφvß v tom, ₧e Φφsla port∙ se na vÜech hostitelsk²ch poΦφtaΦφch p°id∞lφ jednou prov₧dy a stejn∞, a toto p°id∞lenφ se zve°ejnφ. Ka₧d² aplikaΦnφ proces pak mß k dispozici informaci o Φφslech p°φsluÜn²ch port∙ na vÜech uzlov²ch poΦφtaΦφch - t∞mto port∙m se pak takΘ °φkß dob°e znßmΘ porty (well-known ports). ProblΘm je ovÜem v tom, ₧e tato varianta statickΘho charakteru se dß pou₧φt jen pro zve°ejn∞nφ takov²ch slu₧eb, kterΘ jsou p°edem znßmy, a s jejich₧ existencφ lze p°edem poΦφtat.
Alternativou je umo₧nit proces∙m na jin²ch uzlov²ch poΦφtaΦφch zjistit si Φφslo portu na danΘm poΦφtaΦi - dotazem stylu: "na jakΘm portu je poskytovßna slu₧ba p°enosu soubor∙?" Tato varianta stßle vy₧aduje alespo≥ jeden "dob°e znßm² port" (p°es kter² by bylo mo₧nΘ vznΘst p°φsluÜn² dotaz), a je takΘ spojena s urΦitou re₧iφ. Na druhΘ stran∞ je ale mnohem pru₧n∞jÜφ, nebo¥ umo₧≥uje vytvß°et porty a p°id∞lovat jim Φφsla (adresy) podle okam₧itΘ pot°eby dynamicky vznikajφcφch a zanikajφcφch aplikaΦnφch proces∙, a nenφ vßzßna tφm, jak jsou obdobnß p°id∞lenφ realizovßna na jin²ch uzlov²ch poΦφtaΦφch.
Tv∙rci TCP/IP protokol∙ se rozhodli pro kombinaci obou variant - pro nejΦast∞ji pou₧φvanΘ slu₧by pou₧ili prvnφ mo₧nost, tedy pevnΘ p°id∞lenφ Φφsel "dob°e znßm²m port∙m", a zbylΘ adresy ponechali volnΘ pro dynamickΘ p°id∞lovßnφ podle okam₧it²ch pot°eb.
Multiplex a demultiplex datagram∙
Tato p°edstava velmi dob°e odpovφdß koncepci nespojovanΘ p°enosovΘ slu₧by, kterou poskytuje protokol UDP. Tento protokol se na ka₧d² port dφvß skuteΦn∞ jako na jeden logick² objekt - frontu, do kterΘ jsou postupn∞ uklßdßny vÜechny datagramy, adresovanΘ tomuto portu na danΘm poΦφtaΦi.
Protokol TCP vÜak vychßzφ z pon∞kud odliÜnΘ abstrakce.
Vzhledem ke svΘmu spojovanΘmu charakteru pracuje se
spojenφmi, kterß jsou definovßna dv∞ma koncov²mi body
- ka₧d² koncov² bod je p°itom urΦen dvojicφ