Új hozzászólás Aktív témák

• #8469 Dißnäëß veterán

  Új Válasz 2020-11-25 12:28:49 #8469

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Dißnäëß

  veterán

  Az udp-be tett ellenőrzés a datagramok sértetlenségéről árulkodik kliens oldalra érve, de arról nem, hogy mind megérkezik-e oda. Szerver oldalon tehermentesít, fire and forget, nincs minden egyes elküldött csomag után adott ip címtől visszajelzésre várás, hogy "köszi megkaptam", mielőtt kiküldi az újabb csomagot. + broadcast + multicast. (TCP nem tud broadcast-ot, ezért működik a DHCP is udp-n és broadcast címmel, míg fel nem vette az eszköz a tényleges IP címét, DNS-nél pedig csak a kliens-szerver közötti szokásos névfeloldás üzenetek mennek udp-n, DNS zóna transzferek szerverek között már tcp).

  Viszont alkalmazás réteg függő, hiba esetén mit csinálnak: újraküldetik adott megkapott, udp datagramokkal szállított hibás blokkot a szervertől, vagy sem. Ugyanis a hibát lehet észlelni, udp esetén a szerver mit sem tud erről, de nem is kell tudnia, ezt kliens majd alkalmazás rétegben kezelni - ha kezeli. Ugyanis bármilyen jellegű magasabb szintű humán-logika alkalmazás rétegben nyilvánul meg.

  Lásd realtime vid-chat: nem állhat meg a live stream, ha TCP szinten várunk klienstől visszajelzésre, újraküldözgetünk, szétesik a kommunikáció. Inkább kihagyunk képkockát, hangot. Elvész egy vagy több udp datagram - naés. De ez a "naés" ez alkalmazás szinten eldőlő logika és viselkedés, tehát legmagasabb layer-ben. A kommunikáció egy irányú, ha én csak nézem, de nem küldök magamról képet. (Alkalmazás rétegben ezt értelmezzük iránynak).

  Ellentétben egy OpenVPN-el, ami szintén udp-n fut, mégis - természetesen - totál hibátlan a csőben ami történik, ezt viszont nem az udp maga garantálja, hanem itt is az alkalmazás rétegbe tett "hiba esetén újrakérés" lehetősége és ez is csak a tunnel-re vonatkozik, a cső fenntartására. Van egy X timeout beállítva, ha ezt túllépi a sztori és nem sikerül a cső integritását helyreállítani, megszakad a kapcsolat. De efölött az alkalmazás rétegben megintcsak más történik, mert ha az egy videkonferencia, akkor az is szakad, viszont ha streaming (youtube etc.) akkor az az előre feltöltött bufferből túlél annyi másodpercet, míg a VPN fel nem épül újra, de ennek a mechanizmusnak ilyen értelemben semmi de semmi köze UDP-hez, tehát az átvitel integritására sincs kihatással, simán lehet több VPN szakadással is hibamentesen stream-elni a bufferek miatt, bitperfect módon, ugyanúgy, mintha fájlt töltenék le, miközben udp rétegű datagramokkal történik az egész. Tehát a VPN kétirányú kommunikáció úgy, hogy udp viszi a szervertől is az adatot a klienshez és a klienstől is a szerverhez, de a logikai kapcsolat fogadott adat és küldött adat között (és hogy az jó-e nekem) alkalmazás rétegben valósul meg humán logika mentén, nem az egyes lentebbi rétegekben gépi mechanizmus mentén. Esetünkben alkalmazás réteg az OpenVPN szerver és kliens szoftverek. Amelyekkel másik réteget csomagolunk bele, réteg a rétegben, de ne bonyolítsuk. Tehát nem egy rossz vagy hiányzó udp datagramra szól vissza az alkalmazás (hiszen ő nem datagramokat lát), hogy kedves szerver, küldd újra, hanem az alkalmazás szintjén emiatt megjelenő hibára (esetünkben titkosítási szinten blokk hiba, amit nem tud már a hibajavító algoritmusaival korrigálni) és arra kér a VPN szoftver újraküldést, amit lentebbi rétegben figyelve több udp csomag formában küld el a szervernek és a szerver több udp csomag formában válaszol arra, továbbra is úgy, hogy nem elküldött udp-re jön válasz udp, hanem a vezérlő logika alkalmazás rétegbeli).

  És minket embereket ez sem érdekel, semmi sem érdekel onnantól, hogy nem realtime-iságú a dolog. Mi az alkalmazás rétegen keresztül kapcsolódunk az egész adatátvitelhez és ha az ebben a rétegben értelmezett felhasználáshoz az adat integritása 100% biztosítva van, akkor az úgy fasza. És hacsak nem realtime dologról beszélünk, ez mindig faszára van csinálva, máshogy nincs értelme. Se az online banking nem hibázik, se a Tidal, se semmi más, míg a kapcsolat egésze bizonyos időhatárokon belül "hibátlan" számunkra. (Online banking is kiléptet, humán logika mentén, X perc tétlenség után, ahogy Tidal-ről lejátszó szoftver buffere is véges, szintén humán logika mentén megállapítva, mekkora legyen ez az előre betöltős buffer).

  Audio streaming esetén hasonló van, nincs realtime-iság megkövetelve (kivéve Skype stb). így vagy az alkalmazásban implementálnak ellenőrzőket, vagy - még mindig alkalmazás rétegben - a kodekre bízzák: FLAC streaming-et használnak a mai szolgáltatók, ebben vannak ellenőrzők, blokkonként jön a stream-folyam, amit rengeteg udp datagram szállít. Ha egy udp datagram annyit késik, hogy az általa hozott kis adatcsomag hiánya miatt a felette lévő alkalmazásrétegbeli FLAC stream-ben egy teljes blokk hibás lesz, az ellenőrzője lévén felismerve ezt kérhet a szoftver újraküldést a szervertől (blokk újrakérés, nem udp újrakérés!!! tehát alkalmazásrétegben vagyunk), amit megint végeredményben udp hoz el lentebbi rétegben nézve, talán másodjára vagy sokadjára jól és ez így tök oké nekünk, amíg ugye az alkalmazásrétegi buffer bírja és szól a muzsika. Általában igen, különben kurvanagy cicergést vagy "kattanást" hallana az ember gyakran, velem ilyen még nem történt. Még a Trend FM-el sem, ami a Volumio-ról szinte egész nap megy, amikor nem fülesezek, nemhogy egy Tidal-nél. Ha a buffer kiürül és nem áll össze értelmes, ellenőrzés után is konzisztens adatmennyiség, amivel etethető legyen a DAC, leáll a stream, megakad. Olyan nincs, mint analógban, hogy "kicsit jobban zúg, de azért még elmegy", vagy sok lejátszás után kopott a szalag és zajosabb, dinamikátlanabb. Nincsen kicsit jó és majdnem jó. Vagy megy, vagy nem. És FLAC streamingnél öszvérek sincsenek, az ellenőrzők alapján azonnal tudja a szoftver, bibi van-e, és rajta áll innentől, mit kezd vele, ejti, vagy sem. Alkalmazás réteg beli logika. Skype-olni is lehetne a video stream-ben flac codec-el (csak minek) és ha milliszekundumok alatt nemkorrigálható hiba van, ejtené nyilván a hibát.

  Nem mindegy, melyik layer protokollja hogyan viselkedik, de önmagában nem mind felel a teljes átvitel integritásáért, viszont együttesen igen. Ha nem 1 layer-t nézünk, hanem "mint számítógépes hálózati adatátvitelt" a teljes OSI stack-et, akkor természetesen lehet garantált az adatintegritás nem-realtime esetben, akkor is, ha udp datagramok viszik az adatot. Hiszen mint korábban írtam, alkalmazásaink számára készültek ezek a hálózatok, az egyes rétegek csak a közvetlen felettük levő, ottani felhasználási logikának megfelelő réteg szerint vannak használva és tudják azt, amit, ahogy, de (U)egyenként magukban(/U) a teljes összkép átviteléről, ennek képességeiről nem árulkodnak a rétegek. Lásd információáramlás iránya a korábban linkelt képeken.

  Az udp flexibilitást ad, a tcp kötöttebb, de ez csak a hálózati szint. A teljes adattovábbítás minőségéről egyik sem árulkodik önmagában, az integritás megőrzésére szánt TCP faramuci módon egy kompromisszumosabb (pl. mobil internet) kapcsolaton azonnal elesik egy UDP-vel szemben egy Skype alatt - mert más az alkalmazásrétegbeli igény, a felhasználási logika, az analóg emberi agyunknak pedig így is kiváló egy video hívás, ha urambocsá, néha 1-1 képkocka kimarad.

  És fordítva: egyetlen hibakezelési módszer az alkalmazás rétegben tud olyan szintű lenni, hogy garantálja az alkalmazások közötti sértetlen kommunikációt, és ebbe a hibakezelési módszerbe beletartozik egy alkalmazás szinten definiált bármilyen adategység, blokk, újraküldése is, legyen az egy Tidal szerver kiszolgáló daemon backend alkalmazás az adatközpontban és egy Windows 10-es, vagy Volumio-s, vagy polcos asztali kütyüben lévő minihardveren futó akármilyen lejátszó szoftver. Mindenki máshol javít hibát, máshogyan, adott réteg képességei szerint, és ezek összejátéka adja ki azt, hogy optimálisan vigyünk át adatot, sértetlenül, A-ból B-be.

  Az a stream, ami úgy érkezik el hozzánk, hogy hibás néha és újraküldést kér a kliens a szervertől, az újraküldött lesz itt-ott, naés. Udp hozza lentebb, adatblokkok fentebb, naés. Ez nekünk így is kiváló mindaddig, míg a memória buffer ki nem ürül, a felhasználás szempontjából (alk. réteg) hibátlan és ami innen továbbmegy egy DAC fele, bitről bitre egyezni fog annak a fájlnak a tartalmával, amit a saját HDD/SSD-nk helyett a Tidal szervere adott nekünk. Hogy bithelyesen érkezik-e meg a legutolsó ponthoz, a DAC-hoz, az már más kérdés, USB Audio-nál elméletben nem, a gyakorlatban pedig annyira erősen konvergálunk az elmélethez, hogy megkérdőjelezem a vudukábelek szükségességét (más meg nem. Ez a baj az analóggal, hogy bizonyos határokon belüli eltérések nem egyértelműek és már szubjektivitás áldozatai lesznek, ami nem kis mennyiségű snake oil-nak ad teret és azonnal jönnek a hívők és nemhívők, megmosolyogva a másik oldal korlátoltságát, abszolút igazságot nem hozva a sztoriba).

  Fun fact:
  A digitális adattárolás megszületése óta minőségromlás nélkül képesek vagyunk megőrizni bármilyen digitalizált információt az utókornak, örökre.

  A digitálisan tárolt analóg transzferektől kezdve úgy nagyjából minden ... digi cucc ... annak az analóg rendszernek a "karakterét" őrzi meg mindaddig, míg él a fajunk, amivel átemelték digitális dimenzióba és a jelekből adatok lettek. Ez csodálatos dolog szerintem, ha belegondolunk. Rég el fognak porladni fizikailag a mesterszalagok, Elvis-től kezdve az összes, .. az anno átalakításért felelős ADC-k, a mai társadalom, civilizáció, minden...

  Miközben egy űrszondán simán utazik a végtelen semmiben az információ rólunk, akár "CD-n", akár gyémántkristályban vagy addigra ki tudja min, olyan mennyiségű több darabban, ami többszázezer évre garantálja matek és hibajavítások segítségével az információ tisztaságát egyik-másik hordozó sérülése, sugárzás, mikrometeoritok, anyag puszta változása esetén is. Vagy lézeres fény formában, vagy rádióhullámként, űrszonda helyett - ez most is történik.

  Csak mivel az egész világunk analóg, a digitálisról is gondoskodni kell, ahogy a fizikai hordozója folyamatosan változik alatta, és amíg az őt hordozó analóg dimenzió folyamatos módosulásai matekkal 100%-ban korrigálhatók, addig az arra tárolt adat nem tekinthető sérültnek, mert értelmezhető és eredetivel 100% identikusra előállítható, másolható stb.

  És bár útközben a fény is szennyeződik, a rádió jel is, mert hát analóg az univerzumunk, ha kellő mennyiségű analóg többszöröse áll elő ezeknek és vannak elküldve egy vagy több pontra, simán lehet olyan szitu a jövőben, hogy mielőtt a Föld felrobbanna egy halálcsillag miatt, az utolsó lázadó gyorsan az emberiség összes információját tartalmazó adatot fellövi több lézeres rendszerről is az űrbe, megvan pár másodperc alatt, több különböző pontra irányítva, majd beugrik az X-Wing-be, hiperűrsebességre ugrik és a túlolalt az unokái egyszercsak a szennyezett lézernyalábokat befogva azt visszadigitalizálják, mindegyik különböző csillagrendszeren, ahova anno céloztam, más és más minták mentén sérült fényem lesz, de ha végül (mint egy torrent darabkái) mindből ki tudok menteni ellenőrzőkkel bizonyítottan jó blokkokat, akkor egy "jóblokkos" végső adatom összeállhat és több millió év múlva hallgatom a huszadik századi Elvis-t. Ha pedig már nincs fülem, mert egy Terminator lettem a technológiai fejlődésnek köszönhetően és elfelejtettem jókat dugni, bekötöm az agyamba a stream-et "wifin" és elcsodálkozok az analóg világ tökéletlenségén.

  Ez azért elég állat, nem ?

  [ Szerkesztve ]

  POKE 16017,44 ..... SYS 2077

Új hozzászólás Aktív témák