Vlákno názorů k článku Vyčmuchejte si svého hackera! od PaJaSoft - Prominte, ale ISO/OSI je prave o protokolove separaci...

Prominte, ale ISO/OSI je prave o protokolove separaci ve vrstvach... - nevim o tom, ze by v ISO/OSI bylo pripustne aby prezentacni vrstva kumunikovala se sitovou (validace a hlidani session proti IP adresam a MIM utokum) nebo relacni a linkovou (zamykani komunikace na portech - switche (link) proti autentizaci (relacni - certifikaty)) atd.

Naopak, pokud system policy rekne, ze pravidla jsou takova makova, tak bud aplikace pozaduje prostredky, ktere jsou dosazitelne v danem kontextu nebo nejsou a pak neni mozno tu aplikaci provozovat. A na abstraktni rovine si to klidne predstavte tak, ze se nejedna o protokoly, ruzny HW, ale o to, ze uzivatel A ziska takovy environment, ze neco muze a uzivatel B ziska jiny, kdy neco nemuze. Aplikace pouze o prostredek pozada a bud ho ziska nebo ne, jak kdo cim apod. to cele definuje je zcela mimo ramec teto aplikace (takze zpet poukazuji treba na to, ze aplikaci je kulovy po autentizaci, certifikatech atd.) a je to vec jinych vrstev. Zda-li je to obsah OS, sitoveho protokolu (kterym aplikace nekomunikuje, ale muze slouzit jako transportni pro jeji komunikacni protokol), knihovny vrstvy/tev pod aplikaci je zcela ukradene...

Tak jak znám OSPF, tak nevyžaduje žádné vlastnosti, které UDP nemá.

Ale uplne presne snad plati i to, ze OSPF nevyžaduje žádné vlastnosti které UDP má a plne vystaci s temi vlastnostmi, co ma IP. Dalo by se tedy klidne rict, ze uziti UDP je zbytecna komplikace.

S posledni vetou prispevku ovsem plne souhlasim.

> Takze v beznych aplikacich naprosto NIC neresi urcita funkcionalita dislokovana v knihovne

Proc? Ze neni dostatecne transparentni? Ano, treba openssl vas nuti misto read/write prejit na BIO_read/BIO_write. Tak se udela search&replace (pravdepodobne jen jeden), to je toho.

> kterou musi aplikace aktivne pouzivat a volat...

Pokud to API z knihovny presunete do protokoloveho stacku, bude to stale treba "aktivne" pouzivat. Pravdepodobne to bude o neco jednodussi, ale nijak drasticky.

No prezentacni mozna urcite (obcas), ale co treba takova relacni... proc by se aplikace sama mela starat o autentizaci, proc by mela jit treba az na transportni, pripadne vyse a operovat s pojmy jako certifikat, validace certifikatu atd... - vzdyt to tu aplikaci VUBEC nezajima, ta je uplne pro neco jineho. Uvedu analogii v IP svete - WWW aplikace, ktera funguje jak ma, vubec neresi, zda-li je tento GUI ksicht tunelovany via http nebo https, vubec neresi veci jako certifikaty apod. maximalne si vola servisni funkci isSecure(), ktera vrati true, pokud komunikujeme po zabezpecenem kanalu a dle toho muze upravit chovani... Takze v beznych aplikacich naprosto NIC neresi urcita funkcionalita dislokovana v knihovne, kterou musi aplikace aktivne pouzivat a volat...

> potom by se nestávalo, že každý protokol si znovu a znovu implementuje tu stejnou funkčnost (třeba prezentační vrstvu)...

Obvykle nikoliv, potřebné knihovny jsou dostatečně standartní (asn.1, xdr, ssl, sasl...). To že jsou občas děravé je jiná věc.

A že máme třeba BER parser/kodér v dynamické knihovně místo přímo v protokolovém stacku nikomu žíly netrhá, na výkon to má nulový vliv, a takhle se to aspoň líp udržuje. "prezentační vrstva" je výmysl který nikomu nechybí.

neznám samozřejmě síť, která by fungovala podle ISO/OSI. Co jsem chtěl říct, je to, že tento model dává návod, co do které vrstvy patří. a kde to tedy má implementovat. Potom by se nestávalo, že každý protokol si znovu a znovu implementuje tu stejnou funkčnost (třeba prezentační vrstvu)...

Do učebnic tento model tedy celkem oprávněně patří.

No stare je to, ze uz mu je docela dost, navic dost z nej je citit euro americky akademicky konflikt, ktery tu zname jiz taky dost dlouho. Po teoreticke rovine sice krasny, ale do dnes ani v akademickych podminkach ne zcela implementovany (Vy znate sit, ktera by se presne dle 7-dmi vrstveho ISO/OSI implementovala a chovala a zejmena byla tak striktne delena jak to rika ten model? Kde by se relace oddelovala od aplikacni vrstvy atd.?) Samozrejme mame spoustu hybridu od vseho mozneho, mame take ciste implementace (ROSE (?)) urcitych vrstev... Nerikam, ze ISO/OSI je na nic at zije vse okolo IP, naopak, kdyby to bylo rozsirene, jak krasne a docela jednoduse by se treba implemntoval replikacni FS s vlastnostmi Fail Over a High Availability... jak by bylo snadne vyuzit princip zasilani zprav pro mnoho aplikaci... Bohuzel realita je jina a mluvit o ISO/OSI v souvislosti s IP a vecmi okolo (kam radit ICMP nebo ARP? <g>) mi nidky neprislo jako dobry napad, bohuzel dostalo se to i do ucebnic...:-(

BGP je protokol běžící nad TCP.

Tak jak znám OSPF, tak nevyžaduje žádné vlastnosti, které UDP nemá. To, že nepoužívá UDP je prostě nekoncepční zjednodušení. Prostě si to navrhli tak, jak jim zrovna přišlo na mysl a považovali to za nejjednodušší.

OSPF je jedne z protokolu IP rodiny - tak jako je jim TCP, UDP, BGP ...

Zrejme od nej jeho autori vyzadovali vlastnosti, ktere maji protokoly IP rodiny, ovsem, nepotrebovaly od nej koncept "portu", ktery prinasi UDP. Tahle informace by tam pak byla naprosto nadbytecna a prinasela by zbytecny overhead. Nebo naopak potrebovali nejakou vlastnost, kterou UDP ve sve definici neobsahuje. Myslim, ze pri navrhu skoro kazdeho noveho protokolu stoji dotycny pred otazkou nad jakym protokolem onen svuj novy postavi. Jestli zvoli TCP, UDP, IP, IPX, NetBEUI - to zalezi od toho, co navrhuje a jake vlastnosti potrebuje ...

Co je na ISO/OSI starého? Je to logické rozdělení do vrstev vhodné pro poznání rozdílů mezi jednotlivými druhy komunikace. To, že některé reálně existující protokoly mají ty vrstvy splácnuté dohromady, případně je vůbec neimplementují je přece jiná věc. V matematice máme také komplexní čísla, ačkoliv je v reálném světě neimplementujeme (tedy ještě jsem neviděl, aby mi chtěla prodavačka vrátit nějaké to 0,2i :-)

V praxi se prostě občas sahá ke zjednodušením, která nevypadají tak elegantně jako teorie, na druhou stranu ovšem většinou fungují lépe :-)

Někdy jsou ty protokoly opravdu poněkud nelogické. Proč třeba OSPF neběží nad UDP a má své vlastní číslo protokolu?

já si ego nehoním, jen mě to prostě zmátlo
plácá tám paket přes rámec a je mu to evidentně jedno

dnes se už asi 10 let učí na školách TCP/IP + samozřejmě starý OSI, vím o čem mluvím, taky to do mě naštěstí "cpali" :)

Pochopte to, lidi na školách se kdysi horke těžko naučili model ISO/OSI a chtít po nich, aby si po revoluci přečetli již neembargované RFC-dokumenty přece nelze.
Proto si většina našich pedagogů myslí, že internet byl vytvořen jako 7-vrstevný.
Pokud se řekne, některé vrstvy v něm chybí, tak to ještě jde. Já ale vždy na akademiky zkouším otázku, kam ale patří SSL ? To je tak na neudělání zápočtu. A jen těm nejnadanějším z toho vyráží studený pot na čele. Třeba by na to nějaká agenturu mohla vypsat grant základního výzkumu a výsledky by se prezentovaly na mezinárdní konferenci, která by konečně dokumenovala, jak úspěšně doháníme svět.

Nejsem autor clanku, jen jsem se ho zastal, a poukazal na casty nesvar honit ego tim ze se z relativne jednoduchych zalezitosti delaji slozite, a baziruje se na nuancich v terminologii, tot vse. Pravdou ale je ze mel byt aspon konzistentni, takhle je to zmatene.

nejsem pedagog, jsem teď po škole a nemám toho ještě moc z praxe za sebou (tak rok a něco jako správce) a proto jsem chtěl ať to upřesníš, protože jsem z tvého článku měl prostě guláš

no u TCP/IP jsou sice jen 4 vrstvy ale rozhodně byjsi i tak neměl nesmyslně spojovat a zaměňovat v jednom odstavci za sebe pakety a rámce, protože rámce jsou na nejnižší vrstvě a pakety na předposlední IP vrstvě

mám pak z toho jak jsem říkal guláš, když tomu rozumíš, měl by jsi to psát tak, jak to je a ne to míchat :(, není to bazírování na nesmyslech, jen to vytváří zbytečný zmatek u lidí, kteří tomu až tak dokonale nerozumí (jako jsem já) a právě proto čtou tyto články (jinak bych je psal ;)

Prominte, nejste nahodou pedagog? Jde sice o rozdilne veci, viz http://www.earchiv.cz/a95/a519k130.php3 ale s vyjimkou nekolika dulezite se tvaricich paprdu u zkousky to nikoho nezajima, protoze alespon u ethernetu je mezi nema vazba 1:1, kazdemu frame na linkove vrstve odpovida packet na sitove vrstve a naopak, veci jako ARP i fragmentace se delaji az na sitove vrstve, nikoliv uvnitr te linkove. Bazirovat tedy na rozliseni je asi stejne dulezite jako mit pro "automobil" dva rozdilne terminy podle toho, jestli se na nej divam zepredu nebo zezadu.

Je to stejne jako rigorozni "vrstvovani" u protokoloveho stacku, ktere take nema valneho smyslu, s vyjimkou testovani schopnosti studentu nasprtat se kdejakou blbost. Ucit lidi o 7 vrstvach (a vyzadovat to po nich) je trestuhodna zvrhlost, kdyz realne vcetne "aplikacni" pseudovrstvy existuji maximalne 4.

aha, to byla jen taková maličkost, jsem se spíš zarazil na tom "míchání" paketů a rámcu v jednom odstavci, měl jsem pak z toho guláš, můžete to uvést na správnou míru?

Dobry den, 802.11 ma skutecne Vami zminovany format. Mnou uvazovany ramec se tyka 802.3, schema viz napr. zde.

"Prvních šest bytů ethernetového rámce obsahuje MAC adresu příjemce a dalších šest bytů pak MAC adresu odesílatele."

http://www.svetsiti.cz/technologie/2001/80211/image007.jpg

tohle je ethernetový rámec pro 802.11 a source/destination MAC adresy rozhodně nejsou na 1-12tém bajtu!
jak to tedy je, nemystifikujete nás tady trochu ;)?