Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1213-2225.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1213-2225.
Tak to dopadá, když autor článku píše o něčem, čemu vůbec nerozumí. Nakonec se z toho stane bezmyšlenkovité papouškování původní zprávy bez jakéhokoli vlastního úsudku.
K psaní o sítích je třeba nějakých znalostí. Bohužel, celkové vyznění článku a chyby v něm obsažené svědčí o tom, že sítě nejsou oborem pisatele tohoto článku.
Bohužel je to tak. Úpadek cdr s příchodem hromady autorů, kteří vlastně vůbec ničemu pořádně nerozumí je žalostný.
Nějak rozebírat to nebudu, ale autorovy doporučuji přečíst si alespoň něco o UDP ( User Datagram Protocol ) na wikipedii, který se používá např. v přenosech u těch mmorpg her nebo voip.
Bohužel, to není jediný zásek. U her, VoIP, streamovaného audia/videa, pro klientské požadavky na DNS resolver, pro NTP a mnoho dalšího se používá UDP. Tam žádné ACK nejsou a packetloss se nijak neřeší, alespoň tedy ne na transportní vrstvě. Pokud bude aplikace chtít, pošle si nový požadavek.
Docela úsměvné pak je, jak autor hovoří o "vysílači a přijímači".
Zcela mylná je také myšlenka o "příliš rychle jedoucím dopravním prostředku". Nevím, jestli měl autor na mysli zkreslení signálu dopplerovým jevem (autor asi zřejmě cestuje UFO talířem, že se pohybuje tak vysokými rychlostmi,že by skutečně signál zkreslily) a nebo myslel předávání mobilu mezi BTS (to se děje na hranicích dosahu vysílačů a je jedno, jak rychle se pohybujete, prostě vás to přehodí).
Všechno to už začíná bulvárním nadpisem. Původní zdroj říká "5-10 Times Faster", ale zde je pouze "až 10x rychlejší". Místo "lineárních rovnic" by bylo vhodnější napsat "lineární kódování".
V původním zdroji se vyskytují nesmysly o pořadí packetů. Tady se to naštěstí neobjevilo.
Dále by mě zajímalo, jak autor obhájí tvrzení (které doslova přeložil):
"Bohužel i přes jeho nesporné zásluhy na rozvoj internetu se nezdá být tento protokol nijak extra flexibilním a bezpečným."
Mám pocit, že slovo "bezpečný" nebylo interpretováno správně. Ale hlavně bych chtěl vysvětlit, proč není TCP/IP flexibilní.
Velice zavádějící je tvrzení o době vzniku TCP/IP. Ano, sice byl navržen v 70. letech, ale neustále se vyvíjí. V 80. letech - IPv4, v 90. letech IPv6, které se neustále vyvíjí. No a potom další "přílepky" CIDR, VLSM... A teď v poslední době Multipath TCP, o kterém se ve zdrojovém článku také mluvilo.
Pokud by se brala pouze čistě doba vzniku, tak se také musí říci, že lineární kódování je ještě starší než TCP/IP.
Ono to vlastně není nic nového pod sluncem. Jedná se o samoopravné kódy. Takové techniky se využívají i dnes.
Také by mě zajímalo, jak byla vypočítána ta údajná 10x větší rychlost. Tím je myšleno, že v případě nějaké sítě, kde se ztratí 90% pomůže tato technologie k lepšímu chodu?
Nebo že se zvýší linkové rychlosti, protože se navýší frekvence a modulace, jelikož bude větší fault tolerance?
Jestlipak pánové nezapomněli připočítat ten jistě ne zrovna malý overhead?
Plny souhlas s JP01.
Ja hlavne nechapu to zrychleni, kdyz k paketum pridam samoopravne kody. Tim naopak stavajici kapacitu snizim.
Mozna prisli s nejakym lepsim kodovanim, co oproti tem stavajicim usetri nejake ty bajty? Ale i tak bych v necem takovem nevidel 5-10 nasobne zrychleni.
Nebo je to mysleno tak, ze diky lepsi saopravotelnosti to umozni na stavajicich dratech zvysit presonou frekvenci, kdy sice vzroste chybovost, ale prave to lepsi kodovani to stiha opravit?
Nevím přesně, jak to je myšleno, ale myslím si, že jde o to, že se nebude muset čekat na acknowledge, popřípadě tu informaci znovu odesílat.
Jak se to bude řešit, pokud bude chybovost natolik veliká, že původní obsah nepůjde zrekonstruovat, to je mi záhadou.
řekl bych, že pání vědci došli k tomu, že by to TEORETICKY mohlo vést až 5-10x zrychlení.
Jistě jim to v matematickém modelu za určitých podmínek nádherně sedí, ale všichni víme, že v praxi jsou vždy dost odlišné výsledky ;-)
a opravdu hezký postřeh od JP01:
moc mě zajímá, jak se jejich systém bude chovat při velké ztrátovosti, kdy data nepůjdou obnovit :D
Hehe s tou 10x vyssi rychlosti me to taky napadlo, ze to bude na nejakych starych telekomackych rozezranych kablech, kde se ztrati 90% packetu .... vlastne takhle by museli zrekonstruovat komplet zbytek, coz se nestane, takze ta ztrata by musela byt jeste vetsi:)
To, ze TCP je bezztratovy stream je jasne, ze kdyz se zasekne prvni bajt, tak se sice dal cachuje, ale dal do systemu se to neposle nez je kompletni sekvence. Tohle, IMHO, pak resi nejaky "CRC" samoopravny algoritmus typu RAID, kdy se proste vynechany bajt v UDP streamu dopocita .... ale samozrejme se zvysi overhead. Troufnu si tvrdit, ze konkretne hry, ktere posilaji UDP pakety maji nejakou vrstvu primo v hernim API, ktera presne tohle dela zcela automaticky ... prijde mi to logicke a prakticky jedine rozumne reseni. Panove asi objevili ameriku nebo jde jen o typicky halohoax ....
A jeste k wifi, AFAIK, wifi ma snad uz na fyzicke vrstve implementovane algoritmy a TCP proste nevynechava .....
Cele mi to prijde jako naprosta blbost, uz jenom kdyz vidim bombasticky nadpis, ze neco je 10x, 100x, milionkrat rychlejsi mavnutim kouzelneho proutku (jako by vsichni ti matematici doted byli uplni kokoti), tak ze zkusenosi vim, ze pujde o jasnou blbost nebo podvod ....
Tak předně, tato technika zřejmě nemá navyšovat propustnost surových dat - "jedniček a nul" může pořád prolézt stejně. Jde jen o to, že by měl být přenos lépe řízen. Myšlenka je asi taková, že když půjde poškozený rámec opravit, tak se nebude muset čekat na nový.
Naposledy přišlo takové zázračné zrychlení v dřevních dobách Ethernetu při příchodu CSMA/CD.
Teď je ale potřeba uvést na pravou míru některé nesmysly z komentářů. TCP nemá žádné streamy, ale sessions.
CRC není žádný samoopravný algoritmus. CRC 32 je hashovací funkce, která pouze zkoumá integritu rámce.
Ztracená data se na L2 nijak nedopočítávají, k tomu opravdu FCS neslouží. Možná by stálo za to se podívat, jak vůbec vypadají režijní data rámce. Zjistil bys, že otisk dat z CRC 32 má pořád stejnou velikost (32 b), ať je rámec 64 B nebo 1500 B. Ono by se do těch 4 B moc opravného kódu nevešlo.
Z poškozených UDP (ani TCP) segmentů se rozhodně nic nedopočítává. Pokud je rámec poškozený, tak je zahozen už na linkové vrstvě a na transportní vůbec neproleze. Z L2 se do L4 dostane pouze informace, co se stalo a nechá se, ať se transportní vrstva rozmyslí, co dál.
S WiFi máš pravdu, že má FEC už na L1, ale to o TCP je blbost. TCP segment je na zcela jiné vrstvě.
Jediná vrstva, která má samoopravné kódy je fyzická vrstva. Na linkové se už jenom a pouze detekuje integrita rámce a samotná spolehlivost se řeší až na transportní vrstvě.
Pleteš si vrstvy a navíc si ještě pleteš zjišťování integrity rámce, samoopravné kódy a spolehlivost přenosu.
Zase dalsi co baziruje na stupidnich pojmech .... myslim, ze jsem to napsal zcela jasne ....
No jistě, CRC měl být samoopravný kód a ve skutečnosti je to pouze hashovací funkce. To není jenom nějaký stupidní pojem. CRC žádná poškozená data nedopočítává.
Uznávám, že slovíčkaření "stream" vs. "session" není pro technickou stránku tak důležité. OVšem jinak je správná terminologie nezbytná. Ale ty ostatní věci, to není jenom o nesprávném pojmenování, to je o nepochopení podstaty věci.
1) CRC (viz nahoře)
2) Z poškozených TCP a UDP segmentů se nic nedopočítává. Pokud jsou poškozené, tak už jsou se ty rámce zahodí na linkové vrstvě a na transportní vůbec nedejdou.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.