- Aliexpress tapasztalatok
- Mobilinternet
- Rossz üzlet az EV-kölcsönzés
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Van, amit nehéz lett megtalálni a Google keresőjével
- Kínában túl sok az EV, fokozódik az árháború
- VMware
- TP-LINK routerek
- Joomla! topic
- Musk szerint már jövőre itt vannak a Tesla Optimus humanoid robotok
-
IT café
Új hozzászólás Aktív témák
-
#92251648
törölt tag
-
#8452
fehér_ember
addikt
dgyuri0123
#8450
fehér_ember
addikt
válasz
dgyuri0123
#8450
üzenetére
A munkahelyén, egy boltban, egy forgalmas út mellett lett kipróbálva. Akkora alapzaj mellett lehet nem tűnt fel; már persze ha ott is csinálta (amúgy ott valami cambridge hm erősítő játszotta a végfok szerepét).
Majd következő szabadnapomon játszogatok még mindenfajta összedugdosással is. Aztán legrosszabb esetben marad ahogy előtte is volt; dac közvetlen a végfokra.U.I.:
Végül nem pakoltam egymásra őket, mert a végfok és a polc között csak ~3cm légrés maradt volna.[ Szerkesztve ]
-
#8453
ozzy711
őstag
xtremetuning
#8430
ozzy711
őstag
válasz
xtremetuning
#8430
üzenetére
"Kicsit hekkeltem rajta"
Tettél alájuk passzív mély-ládát, ( vagy aktívat)?
-
#8454
xtremetuning
addikt
#92251648
#8451
xtremetuning
addikt
válasz
#92251648
#8451
üzenetére
"... mégis nagyon keveseknek jön össze. A siker nem a pénz mennyiségén múlik. Sőt minél több zsetont tolunk a gépbe, annál magasabbak lesznek az elvárásaink is, ezzel párhuzamosan csökken a boldogság esélye." - totál felesleges ide írnom. MINDENT leírsz helyettem/előttem.
Pakolok és megyek is haza.#8453ozzy711 : arra azért nincs szükségem szerencsére. 11" elég már bőven.
[ Szerkesztve ]
...ha belekezdtél a high-endbe, vess keresztet, mert sosem lesz vége.. :) ......... és ezt mástól nyúltam, de nagyon igaz : 'Tegnaptól őszinteséget fogadtam. Azóta nincsenek barátaim...'
-
-
#8457
ozzy711
őstag
xtremetuning
#8454
ozzy711
őstag
válasz
xtremetuning
#8454
üzenetére
Akkor azért nem lett olyan nagy a downgrade.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#8458
xtremetuning
addikt
ozzy711
#8457
-
#10726912
törölt tag
Én meg úgy látom a rendszerépítést, ahogy pl a Long Audio blogjában le van írva: kell egy alap rendszer, ami jó, hozza pl a Primare 22 szintjét (más eszközt nem említek, ez is csak példa, Long épp ezzel tette meg), és ezt a szintet kell hibátlanná tenni. Minnél tovább mentek feljebb erősítő, doboz, forrás szinten, annál kevesebb hiba van: annál jobb minőségű dugók, amik Nem szólnak bele a hangba, annál jobb építésű erősítők, dobozok (azokon belül hangváltó alkatrészek, driverek, stb), s ezáltal meghallhatod a rendszer hangját. Nem eszközömet kell cserélgetni, meglehet azt is tenni, de az eszement sok pénz, hanem a meglévő rendszert letisztítani a hibáktól, s utána megítélni a torzítások nélküli rendszer hangját, s ez a szint ott van, ahol a táp nem a nyák mellett van árnyékolotlanul, hanem Kirakod az erősítőn, dacon kívülre. Van olyan készülék, ahol erre nincs szükség, ez nem a százezres kategória, ezt kell elfogadni, ehhez mérten igazítani a tuningot, tisztogatást, jobbításokat, s ezek után lehet elcsodálkozni, hogy a hifi építése milyen utakon molyen eredményekre vezethet mennyiből.
-
#10726912
törölt tag
Szembesültem azzak, hogy amit alapkritériumoknak ítélek meg a saját rendszeremben, az másoknálvagy elenyésző hatású, vagy épp általuk nem is tapasztalt jelenség. Long azért példaértékű számomra, mert amiket én megcsináltam, azokat ő is megtette, egymásról nem tudva tettük meg, s egyformán ítéltük meg a hatásukat, jelentőségüket.
A kék gyöngyöknél, "patkányoknál" stb nem tartok, nem is igen fogok, tekintve jelentős árukat, én csak tisztogatok. Villanyóráról sem tudok nyilatkozni...🙂 -
#71562240
törölt tag
"Hát de mondom, hogy nem :)"
Hát de mondom, hogy de.
És mindig eggyel több de, mint nem, stipistopiegykettőháromipiapacs.Definíciót vitatsz - másról beszélvén "mélyvízként", mint amiről szó van. Az UDP definíció szerint arra készült, hogy ne legyen visszajelzés és újrakérés a vevő részéről a küldő felé. Ez a téma. Hogy egyirányú legyen, hogy ne legyen kapcsolat. Relatíve "megbízhatatlan" datagram típusú protokoll, amelyben a vevő nem képes a sérült vagy elveszett adatcsomagok újrakérésére, a fogadás sorrendjét se garantálja, gyorsabb, mint amennyire megbízható, nem garantálja a csomag megérkezését se. Mert nincs visszajelzés az adatfolyam megérkezéséről, a megérkezés sikerességéről. Lásd üzenetek, stream, broadcast... egyirányú protokollja - vagy lásd például DNS(!). Az UDP-ben a cél port (készüléke) nem jelez vissza arról a forrás portnak (készülékének), hogy az egyes adatcsomagok ellenőrző összegei megfelelőek-e, ergo nem is kéri a vevő a hibás adatcsomagok újraküldését, nem képes a sérült vagy elveszett adatcsomagok pótlására - mivelhogy "connectionless protocol", hajtogatom, hogy nincs kapcsolat. Egyirányú protokoll. Erre való az UDP. Erre készült. Definitíve. UDP esetén szándékosan nincs kontroll a transzmisszióban. Definitíve egyirányúnak készült, az adatfolyam adatcsomagjai újrakérésének elkerülése végett készült az UDP. Ha az UDP hibáit valamelyest korrigálni akarja adott streamszolgáltatás, akkor azt definitíve CSAK MAGASABB SZINTŰ PROTOKOLL tudja végezni, lásd vegyes, öszvér módszerek - még visszatérünk rá.
Hát persze, hogy fel van tüntetve a forrás port a fejlécben, hát már hogyne lenne feltüntetve. Betettél egy fejlécet a kétirányúság igazolására, de az természetesen nem mutat kétirányúságot, hiszen nem áll fenn ilyen kétirányúság az UDP-ben. Az ellenőrző összegeket a cél port készüléke látja, ha nézi (nem feltétlenül nézi, mert úgyse nyer a nézésével semmit, csak statisztikát - még visszatérünk rá). Nem mutat kétirányúságot az a fejléc, nem is mutathat - éppenséggel van rajta egy méretjelőlés, a fejléc adott méretét jelöli, ami alapból négy Byte. Az UDP fejlécének "folyamatábrája" nem mutat kétirányúságot - definitíve nem is mutathat. Azt írod, hogy "A kétirányúságát mutatja az is, hogy így néz ki egy UDP csomag fejléce:" - hát nem mutat kétirányúságot. A forrás port elküldi az adatfolyamot, a cél port vagy megkapja vagy nem, vagy jól kapja meg vagy nem, vagy ellenőrzi az ellenőrző összegeket vagy nem (sic!, még az se biztos, hogy a célkészülék ellenőrzi az ellenőrző összegeket, mert be lehet úgy állítva, hogy ne ellenőrizze, hiszen úgyse nyer vele semmit!).
Idézed az általad "a debreceni egyetem lapjának" nevezett Tanenbaum-Wetherallból, hogy "A forrás portjára elsősorban akkor van szükség, amikor választ kel küldeni a feladónak..." Azt már nem idézed ugyanonnan, hogy "...érdemes néhány olyan feladatot külön is megemlíteni, amit az UDP nem végez el. Az UDP nem végez forgalomszabályozást, torlódáskezelést vagy újraküldést egy rossz szegmens vétele esetén." Nem végez, mert egyirányú a protokoll, nincs kapcsolat az UDP-ben a küldő és fogadó között - erre is még visszatérünk. Az általad (részben) idézett dokumentum is ellentmond neked (természetesen, hiszen definíciót tagadsz), ha egy kicsit tovább olvasod - visszatérünk erre is.
Hozod a névfeloldást, DNS-t, de hát külön kitértem az amúgy nyilvánvalóra, hogy az UDP-n végzett stream valamelyest különbözik az UDP-n végzett broadcasttól - de még az UDP-n végzett broadcastban is van például a DNS által feloldandó feladó és címzett, nem itt van a különbség a streamingszolgáltatás és a broadcast között, de mindennek semmi köze a kétirányúsághoz, kétirányú akkor lenne, ha lenne """tértivevény""" arról, hogy a """felcímzett borítékban""" levő """levél""" minden betűje rendben megérkezett-e, vagy ellenkezőleg, szakadtan, darabokban, hiányosan, itt-ott elmosódott tintával érkezett, és ezért lenne kérés a jobb felső sarkát újraküldeni. De nincs ilyen """tértivevény""", alkalmasint arról sincs, hogy megérkezett-e egyáltalán a levél a cél port címére. Szélsőséges esetben UDP-n nem is tud a címzett arról, hogy levele kellett volna érkezzen, amely levél útközben kihullott a postás lyukas táskájából. (Azt hittem, hogy ősz van, a hulló levelekről... Pedig csak a postás hullott ki az emeletről.) Az UDP "postai rendszere" a "levelet" vagy kiszállítja vagy nem szállítja ki, vagy szakadozik vagy nem szakadozik, vagy mosódik a tinta vagy nem mosódik, de nem tud erről az UDP-n a feladó. Ha lenne erről "tértivevény", akkor már nem UDP lenne, hanem vagy TCP vagy egyéb magasabb szintű protokoll vagy vegyes protokoll, ahogy korábban leírtam - például QUIC. Az UDP definitíve attól UDP, hogy nem foglalkozik az ellenőrző összegek megfelelőségéről való viszontreferálással a feladó felé, ergo újrakéréssel sem foglalkozik. Datagram protocol. UDP-n definitíve nincs kapcsolat a feladó és a vevő között, nincs visszajelzés a potenciális fogadótól, azaz a cél címtől hogy pontosan megérkezett-e minden adatcsomag a címre, és ha nem érkezett pontosan, akkor mi a pontatlanság, mit kéne újraküldeni, ha lenne újraküldéskérés - nincs ilyen visszajelzés és újrakérés UDP-n, és éppen erről a "nincs ilyen"-ről szól az UDP, erre készült, hogy ne legyen visszajelzés az ellenőrző összegekről, ne legyen újraküldési kérés a vevő részéről. Definitíve nincs ilyen visszajelzés. Ha volna erről visszajelzés, ha volna újraküldési kérés, akkor már nem UDP volna, hanem például TCP, például öszvér QUIC, például egyéb fajta öszvér volna - MAGASABB SZINTŰ protokoll volna, ha a volna ott nem volna.
Datagram protocol versus transmission CONTROL protocol.Ha a streamingszolgáltató klasszikus UDP-t használ az adatfolyam küldésére, akkor definitíve nem garantálja az adatfolyam minden csomagja hibátlan megérkezését, nagyon szélsőséges esetben az adatfolyam egészének megérkezését sem, mert a forrás port nem lát utána, nem is néz utána, a cél port pedig nem referál vissza erről, mivel nincs kapcsolat UDP-n a küldő és a fogadó között - egyirányú hálózati protokoll. Csak megcímzett elküldés van. Elküldi a forrás port a megfelelő (alkalmasint DNS) fejléccel az adatfolyam csomagjait, oszt jónapot, lesz ami lesz, utánam az Özönvíz. Vagy odaér vagy nem, vagy tudomást szerez a küldeményről a cél port vagy nem, vagy helyesek bizonyos ellenőrző összegek vagy nem, ha nem helyesek, akkor az veszett fejsze nyele UDP-n. Definitíve.
Nézzük az általad forszírozott válasz kérdését. Ha UDP esetében a szóbanforgott vevő közölni akar valamit a szóbanforgott feladóval, akkor az egy ÚJ, az előzőtől független egyirányú és kapcsolatnélküli folyamat, lásd az idézeted második részét a Tanenbaum-Wetherallból, "a bejövő szegmens forrásport mezőjét átmásolja a kimenő szegmens célport mezőjébe.", - és bekerül a korábbi cél port mező az új forrás port mezőbe. Új folyamat, melyben a korábbihoz képest megfordul az egyirányúság iránya - mondom, az ÚJ egyirányú folyamatban. És akkor az új, a korábbi folyamattól független egyirányú folyamat új feladója (az előző folyamat vevője) nem fogja tudni, hogy a "válasza" megérkezett-e az új vevőhöz (a korábbi folyamat feladójához). Ha UDP-n valami okból valamiféle választ akar küldeni a cél port a forrás portnak, akkor az egy a korábbitól független, új egyirányú folyamat, a korábbihoz képest megcserélődő szerepekkel, lásd megcserélődnek a forrás és cél mezők a korábbihoz képest. Két külön, egymástól független egyirányú folyamat. A válaszhoz fel tudja használni a korábbi vevő a korábbi forrás címét, lásd megcserélődnek a fejléc mezői, megcserélődnek a szerepek az új, független egyirányú folyamatban. Persze, hogy szerepel a fejlécben a forrás port azonosítója, hogyne szerepelne, másképp nem tudná a DNS és a hálózat, hogy valahonnan valahova mennie kéne üzenetnek-adatnak, és hogy honnan hova kéne mennie az adatnak-adatfolyamnak. De az UDP-ben a cél port nem referálgat arról a küldő portnak, hogy az ellenőrző összegek stimmelnek-e az adatfolyamban. Ha valamilyen okból van válaszüzenet a cél port részéről UDP-n, akkor az egy külön, az előzőtől független egyirányú esemény, megcserélődő szerepekkel. Ettől alapvetően különböző módszer a kétirányú folyamat, amikor van kapcsolat a feladó és a vevő között (lásd TCP), ugyanis olyankor a választ küldő korábbi vevő a válaszban is vevő marad, tehát nem cserélődnek meg a szerepek, és a válasz ugyanabban a kétirányú, kapcsolat alapú kommunikációban történik, mint az eredeti üzenet-adat.Ha az ügyfelekkel ugyebár lehetőleg állandó sikeres hangminőséges kapcsolatot fenntartani akaró streamingszolgáltatók esetleg a szimpla egyirányú UDP-nél biztonságosabb módszert akarnak használni, de az UDP sávszélességi és időbeli folyamatossági előnyeit minél jobban megtartva, akkor próbálkoznak öszvér módszerrel, lásd például QUIC, vegyítve az UDP-t magasabb szintű protokollok módszereivel. Ilyenkor, ha az UDP bázis vegyítve van magasabb szintű protokollal, az már nem UDP, hanem vegyes megoldás, melynek része az UDP bázis - lásd például a QUIC-et -, ha pedig helyettesítve van magasabb szintű protokollal az UDP, akkor meg azért nem UDP, mert nem UDP, hanem például TCP.
Na de a spanyolviaszt magyarázom, definíciót vitatsz.
Ugyebár a streaminget akaró zenehallgató személy készülékéhez tartozó cél portnak meg kell találnia a szolgáltatónak a streamingkérés fogadására és a katalógusadatok mutatására szolgáló központját (vagy esetleg közvetlenül a médiumot tartalmazó szervert), mert el kell küldenie megfelelő helyre a kérést, hogy kér egy médiumot streamingelni, és mely médiumot kéri streamingelni, és milyen minőségben kéri streamingelni, és mely portra kéri streamingelni - történik mindez alkalmasint az application layerben, alkalmasint TCP-n, de akár történhetne UDP-n, akárhogy is, ez nem függ össze azzal, hogy amikor a szolgáltató elindítja a streamet, az milyen protokollon jön. Ha a streamingszolgáltató a streamet magát UDP-n küldi (mert azon küldeni költség- és idő- és termeléshatékony számára), akkor már a cél port részéről visszajelzés nem lesz a streamet UDP-n küldő szerver forrás port felé, hogy rendben érkezik-e a stream összes adatcsomagja, stimelnek-e az elllenőrző összegek, azaz a stream UDP (kvázi szállítási) layerében nincs kapcsolat a forrás port és a cél port között, csak egyirányú adatfolyam-küldés van a címre - ezért is van a bufferelés, hogy növelje a célhoz összevissza sorrendben érkező adatcsomagok sikeres streamelésének esélyét, és ezért is próbálják esetleg megvariálni a szolgáltatók, hogy ne tisztán UDP-n folyjon, ne egy szálon folyjon maga a streamelés. Alkalmasint más rétegekben a hálózati kapcsolat meglétének, zavartalanságának a figyelése is folyik, az UDP-n való streamelési folyamatról ellenben nincs kommunikáció, az csak címzett küldés, az adatfolyam csomagjai vagy megérkeznek vagy nem, vagy jól érkeznek vagy nem. Ha útközben valamiért eltéved az adatfolyam, a cél port nem is tud róla, hogy egyébként már rég elindult útjára a gyönyör, a küldő portnak pedig halvány segédfogalma sincs arról, hogy megérkezett-e a címre bármi is a küldeményből az UDP-n küldve. Egyirányú protokoll.
Sőt, amint említettem, ha a cél port stream készüléke úgy van beállítva, hogy ne ellenőrizze, akkor még csak nem is ellenőrzi saját magának az adatcsomagok ellenőrző összegeit, mert minek foglalkozzon vele, pusztába kiáltott szó, falra hányt borsó, ha talál hibás ellenőrző összeget, ugyanis UDP-n erről nem küld értesítést és újrakérést a forrás portnak, ugyanis az UDP definitíve arra való, hogy a cél port ne küldjön értesítést, ne kérjen újra adatcsomagot. Ez a definíciója az UDP-nek, ezért készült az UDP, hogy a cél port ne jelezzen vissza az ellenőrző összegekről, hogy ne kérjen újra hibás adatcsomagokat. Erre való az UDP. Definitíve.
Az UDP mint olyan, definitíve egyirányú protokol, nincs kapcsolat, nincs tértivevény. Az UDP-ben nincs. Amiben van ilyesmi, az már más mint az UDP, az már magasabb szintű protokoll, az UDP-től eltérő célokra készült protokoll. Az UDP egyirányú protokol, kapcsolat nélküli, adatújrakérés nélküli. Szándékosan ilyen, sőt éppen ez a szándéka. Definitíve. Erre készült. Az UDP.Definíciót vitatsz - másról beszélvén "mélyvízként", mint a miről szó van. Bár nem annyira másról beszélsz, mint a megintcsak tematikailag és formailag is józsefattilai Szabad-ötletek jegyzéke mintájú Disznész, aki megintcsak nem figyelte meg, hogy miről folyik a szó (ráadásul off-nak mondja a témát, aminél ebbe a topikba valóbb "on" témát keveset találhatni manapság), de te is másról beszélsz, amikor az UDP-re fogsz rá olyasmit, ami NEM az UDP.
Szerk.: Pazarlod a pindurka kis kvótácskámat - holnap már nem fogom erre használni, bármit válaszolsz, ha válaszolsz, úgy hagyom. :)
[ Szerkesztve ]
-
AMDFan
addikt
válasz
#71562240
#8464
üzenetére
Dícséretes, hogy rászántál ennyi időt arra, hogy megpróbáld ezt megmagyarázni, de hiábavaló volt
De akkor mégegyszer vegyük át miből indult ki a beszélgetés? Abból hogy feltetted a kérdő "UDP?" kérdést amire válaszoltam ezzel:"De a CRC check, és az újraküldés ettől független. Ha UDP akkor nem a network protokoll fogja megoldani hanem egy feljebb lévő."
Tehát én már itt, a beszélgetésünk legeslegelején pontosan azt írtam, hogy egy feljebb lévő protokoll fogja megoldani az adatintegritást, nyilvánvalóan nem az UDP.
Erre te ezt írtad:
"A streamingszolgáltatók egyelőre UDP-t használnak, alaplényege az egyirányú áramlás a szűkséges sávszélességgel takarékoskodás miatt. Amit sikerült átküldeni, azt sikerült, amit nem, azt nem, az pech. Nem nagy pech, hiszen nem archiválási célú az áramlás."
Ez nem igaz, mert az UDP alaplényege nem az egyirányú áramlás. Semilyen definíció nem mondja ezt ki, kérlek mutasd meg, hogy hol mondják ezt az UDP-ről. Nem attól lesz kétirányú egy adatáramlás hogy küldünk megerősítést az adatcsomag megérkezéséről. Attól lesz kétirányú, hogy maga az adatáramlás kétirányú (tehát nem a control csomagok, amiket te is említessz). DNS-nél is kétirányú, de mondok jobbat, az NFS korai verziói is UDP-t használnak, ahol az adatintegritás kötelező. És ez meg is van valósítva csak nem az UDP által.
De megmutatom neked egy DNS kérésen keresztül, hogy mennyire kétirányú az UDP. Lekértem az itthoni gépemről a prohardver.hu dns rekordját a google dns szerveréről (dig prohardver.hu @8.8.8.8) és futtattam közben egy hálózati monitorozást.
Ott van az első csomagban az IP-m, a port -> google dns, port, és hogy mit kérek le.
A válaszban ott van ahogy a google válaszol az eredménnyel (a PH! IP címe) az eredeti forrás portra. (nyilván itt az IP címem közben átesik a routeremen egy NAT címfordításon)
Tehát van egy kérés és egy válasz! Mi ez ha nem kétirányú kommunikáció?
Ugye hogy az. Amiről te írsz, és amibe kapaszkodsz hogy connectionless, az így van, ezt senki nem vitatta soha. De a kettőt nem szabad összemosni.És, hogy visszakanyarodjunk a kiindulóponthoz, az az, így végszóként, hogy UDP-n keresztül is megvalósítható a hibátlan átvitel, adatintegritás.
[ Szerkesztve ]
-
Mathiask
senior tag
válasz
#10726912
#8461
üzenetére
Ez azért elég rögös út. Sokak nincs meg hozzá egyrészt az erőforrásuk(pl idő), másrészt a technikai tudásuk(pl.: életében nem forrasztott még direktbe kábelt az erősítőbe). Illetve hát számolni kell azzal, hogy hiába van egy normálisabb alaprendszer, amit vagy szintén nagyon alaposan kell kiválasztani, tehát ugyanúgy van egy nem megspórolt "normál rendszerépítés", vagy pedig abból kell főzni, ami "épp adódott" és ez nem biztos hogy valaha eléri a célját. Lehet, hogy minden tuning megvan már és az alaprendszer miatt még se jön el a nirvána. Ilyenkor meg nagyon nehéz újrakezdeni egy másik rendszerrel, mert a tuningolt cuccok kb eladhatatlanok. Szóval amit mondasz, inkább a legeslegutolsó lépésnek gondolnám logikusnak.
Én ha javasolni kéne egy kezdőnek mihez kezdjen, akkor valószínűleg azt mondanám, hogy gyűjtse össze a szimpatikus készülékek márkáit és ezen márkák komplett rendszereit hallgassa meg, akár a drágábbakat is. És ha valamelyik márka, vagy hangzásvilág megragadja, akkor kössön ki annál, akár úgy, hogy az olcsóbb rendszert veszi meg, ami még pénztárcabarát számára.
Aztán idővel vagy az van, hogy elég lesz egy életre ez, mert nem is akar hifizni, csak zenét hallgatni, vagy ha hifizni akar, akkor gyűjt vele annyi tapasztalatot a saját zenehallgatási szokásairól, preferenciáiról, hogy vagy márkán belül lépked felfelé, ahogy pénztárcája és "hifi kedve" gondolja(ilyenkor az a jó, hogy nincs kérdés, ha jobbat akar, akkor megnézni mi a következő termék márkán belül, nem kell millió más terméket megnézni, mert megvan az út), vagy esetleg márkát vált és ott lépked felfelé, ha akar. A lényeg, hogy van kijelölt út, cél, ami kézzelfogható(akár meg is vehető) és nem kell gondolkozni, kutakodni ,cserélgetni, stb.
Szerintem. -
#10726912
törölt tag
-
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 ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
#92251648
törölt tag
válasz
#10726912
#8463
üzenetére
" Long azért példaértékű számomra, mert amiket én megcsináltam, azokat ő is megtette"
Long ténykedése valóban példaértékű, de számomra inkább elrettentő példa.
Természetesen hidegen hagy, hogy ki mivel tölti az otthoni idejét, de amikor a saját szubjektív tapasztalásaink mögé ideológiát is állítunk és ezt minden lehetséges felületen szentigeként osztjuk, nagyon sikamlóssá válik a történet. A HiFi fórumok, FB csoportok amúgy is sötét erdőt képeznek a gyanútlan hobbitársak számára. Ezt azzal fokozni, hogy a kezdők agyába folyamatosan kaparászó bogarakat ültetünk a csatlakozók cseréjével, villanyórával, színes gyöngyökkel kapcsolatban, szerintem rossz irány.A legszebb emlékem Long tevékenységével kapcsolatban, hogy miután lelkesen ellátogatott valami falusi bálba, ahol valamelyik Boney M. énekescsaj adott playback bulit, az ott tapasztalt, vélhetően nem éppen magasztos szintű hangzás alapján küldte a pokolba a komplett Pro Audio szakmát.
-
bkercso
nagyúr
válasz
#92251648
#8474
üzenetére
Pedig pont a pro audiósok terelhetnék értelmes irányba a kezdő hifistát, akik jó hangú, de megfizethető rendszert szeretne.
A villamosmérnökök szerint a méréseket kell nézni, valamint a fórumozók (legyen DiyAudio vagy Hobbielektronika) többsége azt is bevallja, hogy ő ugyan nem hall különbséget az elektronikák között.A gyári készülékek cserélgetését is leginkább az audio szakemberek tudják érthető módon megindokolni, úgy, hogy az ne tűnjön hablatyolásnak egy kezdő számára.
Megjelentek! : MFD3 és MFA3 || bkercso HiFi készülékek: https://hardverapro.hu/aprok/hirdeto/bkercso/keres.php?search_exac=0&search_title=0&usrid=341946&buying=0
-
#92251648
törölt tag
válasz
bkercso
#8475
üzenetére
"Pedig pont a pro audiósok terelhetnék értelmes irányba a kezdő hifistát..."
Ne kísértsd a sátánt!
Ez a HiFi üzletág összeomlásával járna.Ugyanakkor senki nem tudhatja, mi az értelmes irány. Maximum saját magunkra érvényes és számunkra élvezetes utat tudunk kijelölni, a többiekén meg csodálkozunk, botránkozunk, kuncogunk.
[ Szerkesztve ]
-
-
#10726912
törölt tag
válasz
#92251648
#8474
üzenetére
Ha kicsit tovább is idéztél volna...de akkor megkérdem: miért tapasztalom ugyan olyan hatásúnak a változtatásokat, mint pl Long, holott a változtatások elkezdése előtt nem is hallottam Long létezéséről? Sőt, tovább megyek: sehol nem találtam olyan szintű beszámolót, ami alapján elkezdhettem volna gondolkodni, csak a saját tapasztalataimra, kísérletező kedvemre támaszkodhattam..ez lenne a relevánsabb kérdés, nem az, hogy hol és hogyan lehet Long szakmai múltjába bele kötni...miképp lehet, hogy a dugók elhagyását találom a legjobb dolognak..?
Nem védem, nem ismerem Longot, nem olvastam róla szinte semmit, nem ismerem s múltját, de jelen esetben nem is lényeges dolog, a kérdés összesen az, hogy miért cseng össze Longgal a tapasztalatunk?
(Zárójelben jegyzem meg, hogy kammererrel beszéltünk arról, hogy ezeknek kis hatása van, de gyűszűvel a tengret, semmiképp ne tegyem, rca dugók elhagyását pedig egyenesen abszurdumnak tartotta, összességében mindenről lefelé beszélt). -
#92251648
törölt tag
válasz
#10726912
#8479
üzenetére
Sehol nincs előírva, hogy mit hallhatsz, mit nem. Mindenki másra érzékeny, ez a keresztünk. Van, aki meghallja, ha meg van tekeredve a kábel a szekrény mögött, más meg azt sem hallja, ha az egyik hangszórója néma. Melyikük élvezi jobban a zenehallgatást? Meg lehet ezt így mondani? Nem.
Sem okom, sem jogom nincs rá, hogy kétségbe vonjam bárki tapasztalását. Mást keresünk és kapunk ebben a hobbiban, ennek dacára nagyon jókat lehetne beszélgetni sok témában, ha nem kezdenétek el állandóan győzködni egymást.
-
#71562240
törölt tag
válasz
Mathiask
#8466
üzenetére
Szerk.: Félrecímeztem, nem Mathiasknak szól, hanem a #8465-ös AMDFan-nak válasz.-----------------
Eh..., segget csinálok a számból.
"De a CRC check, és az újraküldés ettől független. Ha UDP akkor nem a network protokoll fogja megoldani hanem egy feljebb lévő."
Tehát én már itt, a beszélgetésünk legeslegelején pontosan azt írtam, hogy egy feljebb lévő protokoll fogja megoldani az adatintegritást, nyilvánvalóan nem az UDP."
Erről van szó, hogy itt közvetve magad is megállapítod a definíciót, miszerint az UDP egyirányú protokoll. Ha ebben maradtál volna, nem lenne vita, mert akkor csak az lett volna a kérdés, hogy
1. adott, konkrét streamingszolgáltató szimpla UDP-t azaz datagramot használ-e a streamingre vagy pedig bonyolultabb rendszert - lásd az eredeti téma, a Tidal valószínűleg QUIC-et,
2. adott, UDP-n streamelő konkrét streamingszolgáltató csinál-e még valamit az egyirányú UDP streamelésen kívül a kétirányú kommunikáció érdekében az UDP szállítási réteg feletti rétegekben levő magasabb szintű protokollokban.
Itt prímán megállhattunk volna, hogy én utánanézvén annak amit akkor fejből nem tudtunk, hogy az eredeti szimpla UDP-s feltételezésemmel esetleg ellentétben például a Tidal feltehetőleg nem szimpla UDP-t használ a streameléshez, hanem feltehetőleg QUIC-et, amiben benne van az UDP bázis sajátos (például sajátosan többszálú) kezelése, és emellett a magasabb szintű rétegekben, magasabb szintű - TCP - protokollokban is feltehetőleg csinál ezt-azt a Tidal valamilyen célú kétirányú kommunikáció érdekében, amely kétirányú kommunikációt ugyebár az UDP-n belül nem tud megvalósítani. Ebben maradva nem lett volna vita.Azért lett vita, mert te önellentmondóan bizonygattad, hogy az UDP nem egyirányú protokoll, miközben nem vitattad, hogy kapcsolatnélküli protokoll, márpedig a témánkban az "egyirányú" és a "kapcsolatnélküli" terminusok ugyanazt a tartalmat fejezik ki, ezért önellentmondó, amikor elismered az UDP kapcsolatnélküliségét, egyúttal tagadod az egyirányúságát. És most is azt bizonygatod, hogy kétirányú protokoll az UDP, és ezzel ugyebár definíciót tagadsz. Ezért végül kifejtettem, hogy a típuspéldádban az az oda-vissza üzenetváltás UDP-n, amit te kétirányú kommunikációnak, azaz párbeszédnek akarsz beállítani, az nem egy darab kétirányú kommunikáció, azaz nem párbeszéd, hanem két darab, egymástól FÜGGETLEN ÖNÁLLÓ EGYIRÁNYÚ KÖZLÉS EGYMÁSUTÁNJA - azaz két független """broadcast""". Nem kétirányú párbeszéd, hanem két független, szuverén egyirányú közlés egymásutánja. Nem egy párbeszédi folyamat, hanem két független egyirányú közlési folyamat egymásutánja. Nem egy darab bilaterális kommunikáció, hanem két, egymástól független monolaterális kommunikáció, azaz két egyirányú KÖZLÉS - azaz két független """broadcast""" egymásutánja. Nem egy kétirányú kölcsönös interakció, hanem két szuverén egyirányú akció egymásutánja.
UDP-n elindul az adótól a megcímzett üzenet, és mivel nincs kapcsolat az adó és a vevő között, ez egyirányú protokoll. HA megérkezik a vevőhöz az üzenet, AKKOR tudomást szerez a vevő, hogy üzenetet küldött neki az adó - az adó ugyebár NEM szerez tudomást arról, hogy a vevő megkapta-e az üzenetet, és hogy hiánytalanul, torzítatlanul kapta-e meg, hiszen egyirányú a protokoll. Az adó csak reménykedik, hogy a vevő felé küldött üzenete célba ér, és hogy hiánytalanul ér célba - reménykedik, hogy a postásnak nem lyukas a táskája, hogy nincs a postás táskájában mobil könyvdarálógép, de csak reménykedik, mert tudni nem tudhatja az UDP protokollon belül, hogy odaért-e az üzenet - mert egyirányú az UDP protokoll. Kvázi """broadcast""" történik. Az egyirányú UDP protokollon belül maradva a """broadcastoló""" adó csak akkor szerezhet tudomást a levél megérkeztéről, ha a vevő valamilyen okból küld egy fordított irányú válaszüzenetet (például mert a vevőnek DNS szerverként feladata bizonyos lekérdezéseket megválaszolni...). Ha a vevő választ küld, akkor az egy fordított irányú új, szuverén """broadcast""", felcserélve a fogadott levél fejléce címzési mezőinek a szereplőit. A vevő által küldött válasz egy újabb egyirányú kommunikációs aktus, azaz nem párbeszéd történik, hanem újabb egyirányú közlés. Újabb """broadcast""", melyben a korábbi vevő már adó, és a korábbi adó már vevő. Ez az új """broadcast""" is befejeződik, amikor elküldetik az üzenet. Ekkor pedig a válaszoló nem fog tudni arról, hogy a válaszüzenete megérkezett-e, mivel ugyebár nincs a kapcsolatnélküli UDP protokollban visszajelzés, ergo egyirányú protokoll. Ezekből az önálló, és az elküldéskor befejeződő egyirányú """broadcastokból""" végtelen üzenetváltás alakulhat ki, amíg el nem vész valamelyik üzenet - például van egy postás, aki megeszi a leveleket. De informatikai szempontból ez nem kétirányú párbeszéd, hanem egyirányú """broadcastok""" egymásutánja - egyirányú protokoll, nincs kapcsolat az egyirányú közlők között. Lásd Disznész témábavágó és elég helytálló kifejtését a #8469 Dißnäëß első bekezdéseiben, amelynek ezirányú részét én úgy fogalmazom meg most, hogy az az oda-vissza egyirányú közlésváltás, azaz pro és kontra """broadcastolás""" az antropomorf gondolkodásodban képződik le kétirányú kommunikációs protokollként. De nem kétirányú a protokoll, informatikailag nem párbeszéd történik rajta, hanem két független egyirányú közlés egymásutánja. Lásd még a mozgóképpé összeálló másodpercenkénti 24 állókép akkor is autonóm-szuverén állóképek sorozata, ha mozgóképként látod, és tudok még hasonlatokat.
Tehát amikor többedszer visszakérdezel a webfejlesztőiskolai típuspéldát Training360 fokban újratervezni akarva, hogy "Tehát van egy kérés és egy válasz! Mi ez ha nem kétirányú kommunikáció? Ugye hogy az.", akkor sokadszor is az a válasz, hogy nem az, ha szimplán UDP-n belül történik, akkor nem az, hanem két darab autonóm egyirányú """broadcast""", amely az antropomorf látásmódodban tűnik fel kétirányú kommunikációs protokoll "mozgóképeként" - vagyis "optikai csalódás" kétirányú protokollnak látni. Kapcsolatnélküli protokoll lévén az UDP definitíve egyirányú protokoll, például ezért kell egy esetleges válaszüzenet új fejlécébe felcserélve bemásolni az eredeti fejléc eredeti címmezőit. Az UDP-n belül az inverz egyirányú szuverén """broadcastok""" egymásutánisága látszhat az antropomorf szemlélő számára párbeszédes protokollnak, kétirányú protokollnak - ez egy "optikai csalódás".
#8479Tiger.huhhhh
"(Zárójelben jegyzem meg, hogy kammererrel beszéltünk arról, hogy ezeknek kis hatása van, (...) rca dugók elhagyását pedig egyenesen abszurdumnak tartotta, összességében mindenről lefelé beszélt)."
Még hogy én lefelé beszéltelek?! Rágalom! Én azon a véleményen vagyok, hogy fűrészeld félbe a két csatorna között monoblokká a lejátszót is és az erősítőt is, ezeket építsd eggyé csatornánként, és az így tökéletesen integrált monoblokk elektronikákat tedd bele a hangdobozba, és akkor már csak a sztereó hanghordozót kell két monóvá különválasztva betáplálni a két fél lejátszóba a hangdobozok reflexnyílásán át benyúlva. Ezzel el lehetne érni, hogy se hangfal- se IC-kábelre ne legyen szükség, így azok dugóin se kell gondolkodni. És ha mindezt a Paks2 1-es turbinájára közvetlenül rákapcsolva valósítod meg, akkor még tápkábelre sincs szükség - és azok dugóira se. Csak semmi megalkuvás![ Szerkesztve ]
-
AMDFan
addikt
válasz
#71562240
#8483
üzenetére
Nézd, ha ennyire ki akarod sarkítani, akkor ám legyen, én nem állok az utadba (DE... majd később), hívd az UDP-t egyirányú protokollnak. Az alapvető kérdés amúgy sem ez volt, hanem az, hogy UDP-n is hibamentesen tud közlekedni a zene ha meg van valósítva alkalmazás szinten az ellenőrzés. És akkor ennek a végére pontot tehetünk. A következő részt kéretik kihagyni annak akit nem érdekel a téma
És akkor a DE: "a típuspéldádban az az oda-vissza üzenetváltás UDP-n, amit te kétirányú kommunikációnak, azaz párbeszédnek akarsz beállítani, az nem egy darab kétirányú kommunikáció, azaz nem párbeszéd, hanem két darab, egymástól FÜGGETLEN ÖNÁLLÓ EGYIRÁNYÚ KÖZLÉS EGYMÁSUTÁNJA - azaz két független """broadcast""""
Csak azért, hogy én se álljam meg szó nélkül ha helytelen kifejezést használsz
Tehát az ilyesfajta kommunikációt definítve nem hívhatjuk broadcastnak, még három idézőjelben sem, mivel a broadcast pont-multipont kommunikáció, tehát egy hálózaton kifejezetten broadcast címre küldött üzenet(eket) jelent. Ilyen pl. a DHCPOFFER, REQUEST, DISCOVER. Tehát nem adott IP címre van címezve (ezt nem hívjuk broadcastnak), hanem kifejezetten a broadcast címre (pl. 255.255.255.255).Az egy illetve kétirányúságról még annyit, hogy ilyen alapon egyirányú kommunikációnak hívhatsz egy emberi beszélgetést is. Hiszen az egyik fél csak úgy mond valamit, a másik fél pedig csak úgy válaszol, tök függetlenül. Annyit akarok ezzel mondani, hogy a hálózati kommunikáció egy vagy kétirányúsága az nem attól függ, hogy UDP vagy TCP, hanem attól hogy milyen mögöttes logika szerint használjuk őket. Az UDP-t lehet használni egyirányú kommunikációra (pl DHCPOFFER), de nem definitíve erre készült. Nem akartam, de itt boncolgatnám tovább a DNS-es példámat és NAT-olást. Ami úgy indul, hogy kiküldünk a belső hálózatból egy üzenetet a google DNS felé. Ez áthalad az otthoni kis routerünkön, ami NAT címfordítással jut el a google DNS felé. Képzeld el mi történne, hogy ha ezek a csomagok csak úgy szabadjára lennének engedve és mindenki megfeledkezne róluk, hogy el lettek küldve.
Jönne vissza a "független" válasz a google DNS-től, ami már a routernél elakadna, hiszen azt mondaná, hogy mégis mit akarsz itt te kis pondró UDP csomag, én nem kérdeztem a google DNS-t. Éppen ezért tartja nyilván a router a NAT tábláiban, hogy ha esetleg arra a forrásportra érkezik válasz amiről az előbb kiment a csomag, akkor azt NAT-olva vissza kell küldeni a belső hálózaton a gépünknek. OK tehát a router ezt a "kapcsolatot" nyilvántartja a kockásfüzetében, eljut a gépünkig a csomag.
Ott a gépünk, ha totálisan fire and forget elven küldené el az eredeti UDP csomagot, akkor azt mondaná, hogy mégis milyen csomag ez itt, nekem nincs semmilyen szolgáltatásom ezen a porton, "haggyábékén" és eldobná. DE nem ez történik, ugyanis a gépünk is nyilvántartja, hogy kiküldött egy UDP csomagot ezzel a forrásporttal, hiszen ott van mögötte a "dig" ami türelmetlenül várja a választ, és végülis meg is fogja kapni. További érdekes infók: UDP hole punching
Idézet: "UDP hole punching is a method for establishing bidirectional UDP connections between Internet hosts in private networks using network address translators."
A lényeg az, hogy megegyezhetünk abban amiből kiindult az egész, hogy a bitpontos streaming, UDP-n keresztül megvalósítható. PONT. Az irányokról meg ne vitatkozzunk, fogadjuk el egymás véleményét, más a nézőpontunk, és nem múlik rajta semmi, hogy ki hogy hívja.
-
#8485
fehér_ember
addikt
Dißnäëß
#8477
fehér_ember
addikt
válasz
Dißnäëß
#8477
üzenetére
Van már Hifi műszaki szemmel is. Ott is lehet bátran mindenféle hifis műszaki dolgot kérdezni. Én is majd alkalmanként élek a lehetőséggel.
#8486 dgyuri0123
Idővel lesz valami műszaki összefoglaló is (kapcsolási rajzok olvasása; hová milyen alkatrészeket; hibakeresések, dsp ...stb.)?#8487 Dißnäëß
"Nyugi" csak muszály volt átnevezniük a "hifiről általánosságban"-t.[ Szerkesztve ]
-
#8486
dgyuri0123
nagyúr
fehér_ember
#8485
dgyuri0123
nagyúr
-
#8487
Dißnäëß
veterán
fehér_ember
#8485
Dißnäëß
veterán
válasz
fehér_ember
#8485
üzenetére
Köszi. Megnézem a jövőben.
Amúgy én a hangjáról érdeklődtem, az nem műszaki - legalábbis oda már a szubjektivitás is kell, az pedig ez a topic (bkercso jól le is vette, velősen válaszolt egy szóban, ez nekem elég). Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
#8488
dgyuri0123
nagyúr
fehér_ember
#8485
dgyuri0123
nagyúr
válasz
fehér_ember
#8485
üzenetére
Aztán nehogy a ló túloldalán találjuk majd magunkat...
Én személy szerint nem preferálom a túlzó "mögöttes" tartalmakat. Sem a kapcsolási rajzok, sem a hibajavítás nem áll az érdeklődési köröm fókuszában. Ez megint inkább diy, vagy rosszul állok hozzá?
Neked mondjuk épp jól jönne, de a helyedben nem nyúlnék hozzá egy beteg nagy-vashoz, inkább megkérdezném pl. Bodor Ferit, hogy vállalja-e az átnézését, illetve javítását. Ő ért is hozzá és szerintem nem fog elutasítani."csak a zene van"
-
Mathiask
senior tag
Csak érdekességképp(, nem vita indítónak): Egy fórumon az Allo tervezője azt írta, hogy a nagyobb THD hatása ránk, hogy szélesebbnek érzékeljük a színpadot. Legalábbis ő és akikkel még teszteltette az elméletét ezt tapasztalta. Egy másik hozzászólásában a kinyílik a színpad jelenséget konkrétan a páros harmonikus torzításnak tudja be.
-
#8490
Dißnäëß
veterán
fehér_ember
#8485
Dißnäëß
veterán
válasz
fehér_ember
#8485
üzenetére
Ja hogy az az. Ok.
Látom van elég hsz. Mondjuk nemigen megyek már be egyhamar most. Tervezési fázis véget ért nálam pont tegnap este, rengeteg szempont mentén mérlegelve, indul a mandula. Hangszórórendelés, asztalost hívni, stb..@Mathiask: padló, mennyezet és fali reflexiók, az THD rendesen. De én inkább a fülünk-agyunk fáziseltérés-érzékenységére gyanakodnék. És ezt a színpad jelenséget süketszobába ülve próbálnám ki, ahol az álpadló alatt is csillapítás van, és körbe mindenhol. Biztosan fura érzet lenne elsőre, de egy sztereó párnak a két térbe vetített nyalábjának a metszete, amibe beülsz lényegében, így lenne "vegytiszta"-közeli, hogy utána érdemben nyilatkozzunk róla. Ez csak szerintem. Nem volt még alkalmam sztereót hallgatni süketszobában. Nem ideális hallgatózás úgy, sőt.. csak a kísérlet végett kipróbálnám egyszer, milyen két nyaláb metszetében ülni, ahol - elvileg - a színpad van. És utána abból mennyit fogok fel, szűknek érzem-e, satöbbi.
Ha szigorúan nézzük, nem csak a színpad, de szinte minden egyéb paraméter betudható a THD-nek, ami meg a szobának is, nem ?
[ Szerkesztve ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
#8491
fehér_ember
addikt
dgyuri0123
#8488
fehér_ember
addikt
válasz
dgyuri0123
#8488
üzenetére
Nem, az MF-ekhez biztos nem fogok hozzányúlni.
Ha kontárkodásra adnám fejem, akkor ott régi technics erősítőm, a linn proci vagy az arcam dac. A legutóbbiba már belepiszkáltam, de természetesen nem segített 
(meg amúgy a technics-be is). Majd veszek egy ilyet és ízekre szedem 
.[ Szerkesztve ]
-
vlaca2
tag
válasz
Mathiask
#8489
üzenetére
Hi! Hol lehet megtalálni ezeket a hozzászólásokat?
A diyaudio.com-on cdsgames néven van fent elvileg az allo tervezője.
(Nálam konkrétan szűkült a tér ahogy "fejlődött" az eszközpark .
Illetve a "tér szélességének átlaga" csökkent, mert vannak nagyon szélesre kevert felvételek továbbra is.)"I see the sound waves" Planar Speaker Asylum
-
bkercso
nagyúr
válasz
Mathiask
#8493
üzenetére
Érdekes!
Ebből is látszik, mennyire nem technikai sport a HiFi, hiszen az emberek jó része a torzat keresi.Bár ezt én eddig nem figyeltem meg (az ellenkezőjét sem), azt azonban igen, hogy a nagyobb torzítással valami mindig elveszik a zenéből. Finom akusztikai információ.
[ Szerkesztve ]
Megjelentek! : MFD3 és MFA3 || bkercso HiFi készülékek: https://hardverapro.hu/aprok/hirdeto/bkercso/keres.php?search_exac=0&search_title=0&usrid=341946&buying=0
-
tunerman
újonc
válasz
Mathiask
#8489
üzenetére
Röviden - ousider az az ember
Hosszabban - egy erősít ha szétépítünk két monoblokkra, akkor javul a térélmény a csatornaelválasztás javulása miatt. Ugyanez a jelenség elérhető alacsonyabb szinten, ha az egy dobozban lévő erősítő dual-monó kivitelű...de folytathatnám tovább is, dehát ez nem egy erősítő építő topik
TJ. -
bkercso
nagyúr
válasz
tunerman
#8496
üzenetére
Csillagpontos földelés és külön tápregulátor vagy kompozit felépítés is tudja ugyan eezt, még dal mono sem szükséges.
Megjelentek! : MFD3 és MFA3 || bkercso HiFi készülékek: https://hardverapro.hu/aprok/hirdeto/bkercso/keres.php?search_exac=0&search_title=0&usrid=341946&buying=0
Pakolok és megyek is haza.
Valahol én is nő vagyok, nálam ez mondjuk 2 mila határ![;]](http://cdn.rios.hu/dl/s/v1.gif)
És a fű meg illegális, pedig...
(meg amúgy a technics-be is). Majd 
Új hozzászólás Aktív témák
- Anime filmek és sorozatok
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Víz- gáz- és fűtésszerelés
- The First Descendant - Kizárólag PC-n lesz játszható a következő teszt
- Aliexpress tapasztalatok
- Sony MILC fényképezőgépcsalád
- Filmvilág
- Samsung Galaxy A54 - türelemjáték
- Motoros topic
- LEGO klub
- További aktív témák...
- ARCTIC Liquid Freezer 360 II A-RGB rev.3 ( Garancia )
- NAD M25 7Ch Master Series végfok végerősítő
- Sony 55-210mm f/4.5-6.3 OSS (Sony E)
- Eladó több mint 2 év garanciával - LG OLED48C21LA / 4K/UHD/2160P/120Hz/OLED
- Razer Blade 16 2023 (i9 13950HX,RTX 4090 16Gb, 32GB DDR5 5600Mhz, 2x 1TB, 16" Dual UHD+FHD+ MiniLED)
- Homage automata óra eladó
- Acer TravelMate P2 P253-M- Intel Core i3 i3-3120M Laptop (15.6") 4 GB
- Sony PS4 Slim 1TB,1 gyári kontrollerrel,hibátlan állapotban,kábeleivel,tökéletes működéssel!
- Fanatec ClubSport Shifter SQ V 1.5 váltó
- Apple watch ultra 2! 2 honapos, jotallasi jeggyel, 34 ho garancia, uj allapot!