Új hozzászólás Aktív témák
-
[CS]Blade2
addikt
válasz nyaralasptt #493 üzenetére
Az a helyzet, hogy nem mi mondjuk meg nekik, hanem mi csak áldozatok lehetünk!
Remélem a nagy T bedobja reklámba hogy a chello az csúcsidős lett, meg csúcsidőn kivüli, hogy megtudja mindenki! -
shev7
veterán
válasz Gregorius #500 üzenetére
en ugy tudom, hogy nincs ''fix'' mapping, hanem minden CM kap a CMTS-tol egy slotot, amelyikben lefoglalhatja az adatatvitelhez szukseges slotokat, de ezek a slotok nem egyediek, a slotkeres kozben utkozes alakulhat ki. Miutan elkuldte a csomagot, es van tovabbi kuldendo adata, ahhoz kerhet slotot a kuldott csomag fejleceben, ha eppen nincs, akkor a kovetkezo csomag kuldesenel ujra el kell jatszani a slotkeros jatekot.
Es itt jon ki az, hogy a p2p forgalom jelentosen leterheli a halozatot, mert nagyon burstos, sokszor kell slotot kerni, ami utkozesekhez vezet, es az senkinek nem jo...''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
Gregorius
őstag
Valóban, én tudtam rosszul, nem kvázi-fix a map (pontosabban minden ütemhez van egy új, de hogy pontosan mit csinál az ütemező, az nem specifikált), valamint ha egy modem egy ideje már nem adott, akkor a kontroll csatornán fog magának rést kérni, viszont a p2p az pont nem burst-ös a http-vel ellentétben, mert a sok forrásból/-ba töltés viszonylag kiegyenlítődik, ugyanis mindig van kinek. Vagyis az esetek 99%-ában tud piggyback-elni. (Ha meg gyakran nincs, akkor valszeg a kevésbé elterjedt cuccokat tölti az emberünk, az viszont olyan lassan csorog, hogy nem sok vizet zavar).
-
shev7
veterán
válasz Gregorius #506 üzenetére
a burstoset ugy ertettem, hogy viszonylag kis meretu csomagok mennek, es nem er vissza olyan gyorsan az ACK csomag, hogy tudjon piggyback-elni.
De vitatkozhatunk itt az elmeletrol. Egy dolog biztos, akik a UPC-nel bevezettek ezt a rendszert gyakorlatban is talalkoztak a problemaval. Ha a p2p teljes ellehetetlenitese lenne a cel nem lennenek olyan teruletek, ahol meg csucsidoben is kozel maximalis sebesseggel megy a fel es letoltes, ebbol azert eleg egyertelmu, hogy ahol alkalmazzak a priorizalast/korlatozast ott valoszinuleg tenyleg szukseg van ra (gondolom aranyaiban ott tobb a hc p2p-es akiket vissza kell fogni), es nem viccbol vettek sokmillios eszkozoket..''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
-
shev7
veterán
az azert sulyos, hogy 500 hozzaszolas alatt sem sierult megertened a lenyeget...
valasz a gondolataidra:
1. a kisebb szolgaltatok is legalabb annyira szeretnenek ilyen modszereket bevetni koltsegeik csokkentese erdekeben, de az ugyfelek unszimpatiaja oket jobban erintene mint a nagyokat. Ha annyira tetszik a kisebb szolgaltatok hozzaallasa, nyugodtan lehet oket valasztani...
2-3. sokadszorra is, nem a letoltes a lenyeg. A letoltesi savszelesseget megfelelo modod karban tudja tartani a fejallomas, a problema a feltoltes, ami ftp eseten igen csekely.
Nettv-re: a 38 csatornabol 3 csatorna van ami 1000 kbit felett ad, a tobbiek 500kbit alatt vannak. Egyreszt ez meg savszelesseget sem igenyel olyan mertekben mint akar az ftp (meg ha 4-en hasznaljak egyszerre akkor sem) a streaming eseten a feltoltes pedig gyakorlatilag 0.''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
fifi_addict
tag
na ne, azért a tv downloadja is erősen leterheli az adott körzetet, ha az chello-s (szerintem; tv-zni nem szoktam a neten, elsősorban mert nem jön be). persze, valószínűleg az adó oldal is belassítja, ha nem tud elegendő szuflával nyomni streaming tartalmat (erre már volt példa...). ezt könnyíti meg/küszöböli ki a p2p tv/streaming, és már is ott vagyunk, amit Egon mondott (azért az természetes, hogy nem a 100 kb/s-es adást hivjuk netttv-nek szerintem, hanem amit ki lehet tenni tv-re)
a tonline-nál meg is mondják hogy 10 Mb ADSL-nél egyszerre max két csatornát nézhetsz, de inkább egyet, a szolgáltatás paraméterei miatt (Apu, kezdődik!)
a chellon letöltésnél 1 Mb fölé még csak sebességmérésnél mentem, elvileg 5 (vagy 10?) Mb-es csomagom van, elsősorban lustaságból (''classic''-ban ragadtam, amikor még csak az volt )...........................???
-
shev7
veterán
válasz fifi_addict #510 üzenetére
''na ne, azért a tv downloadja is erősen leterheli az adott körzetet, ha az chello-s szerintem''
a hagsuly a szerintemen van... tovabbra is feltoltesrol beszelunk es nem letoltesrol...
''ezt könnyíti meg/küszöböli ki a p2p tv/streaming, és már is ott vagyunk, amit Egon mondott''
ami gyakorlatilag annyira gyerekcipoben jar, hogy ugyanolyan vicces ra hivatkozni, mint a legalis p2p-re. Ha valos/altalanos igenykent fog jelentkezni akkor erdemes vele foglalkozni...
''azért az természetes, hogy nem a 100 kb/s-es adást hivjuk netttv-nek szerintem, hanem amit ki lehet tenni tv-re''
nem en jottem a 100kb/s-es adasokkal, hanem Egon...''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
fifi_addict
tag
ahogy írtam, a (mindenféle) letöltésem soha nem éri el az elméleti határt (nyilván sokan lógnak a körzetben a neten). a torrent letöltés sebessége nem érdekel: az sokkal jobban függ a túloldaltól (kevés). a feltöltés a beállítások szerinti max-al megy, ami kevesebb, mint az elméleti, na bumm.
vagyis valószínűleg számomra nagyobb gond az upc hálózatának alultervezettsége az adott körzetben, mint a protokollszűrés
tehát a letöltést nem befolyásolja a feltöltés sebessége? az azért furcsa lenne, elvileg mindkettőre szükség van...
és ha a torrent forgalmat a 80 portra irányítják, akkor mi lesz?...........................???
-
Gabás
addikt
válasz fifi_addict #512 üzenetére
semmi, a szűrés nem portok alapján történik
-
shev7
veterán
válasz fifi_addict #512 üzenetére
''tehát a letöltést nem befolyásolja a feltöltés sebessége? az azért furcsa lenne, elvileg mindkettőre szükség van...''
Nem emlekszem, hogy ilyet irtam volna
''és ha a torrent forgalmat a 80 portra irányítják, akkor mi lesz?''
Elvileg semmi, mert nem port alapjan szur, hanem protokoll szerint...''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
-
-
-
Ilyenekről még nem hallottam, de twollah is írta, hogy nála is az használt, ha átállította a kliensét a 80-as portra... De asszem benézek a hardveresszoftveres oldal fórumára is, ott is ment az anyázás rendesen, megnézem, ők mire jutottak.
https://www.coreinfinity.tech
-
Gregorius
őstag
a burstoset ugy ertettem, hogy viszonylag kis meretu csomagok mennek, es nem er vissza olyan gyorsan az ACK csomag, hogy tudjon piggyback-elni.
A viszonylag kis méretű csomagokat konkatenálja a CM az adatelérési rétegben - talán a DOCSIS 1.1 óta -, szóval nem különbözik lényegesen a terhelés a sok kisméretű illetve a kevés nagyméretű csomag esetén a réskiosztás oldaláról nézve, egyetlen résbe több packetet is bele lehet passzírozni. (A routingra nyilvánvalóan nagyobb terhelést ad.) Azt meg nem látom, hogy az ACK-nak mi köze van hozzá. A saját upstream lökettel megy vissza a piggyback, az meg pont azért ''zavaró'' egyesek szerint, mert nem csak ACK packetek vannak, sőt azok vannak kisebbségben.
#511:
''ezt könnyíti meg/küszöböli ki a p2p tv/streaming, és már is ott vagyunk, amit Egon mondott''
ami gyakorlatilag annyira gyerekcipoben jar, hogy ugyanolyan vicces ra hivatkozni, mint a legalis p2p-re. Ha valos/altalanos igenykent fog jelentkezni akkor erdemes vele foglalkozni...
De mint már volt róla szó, az UPC jelenlegi lépése pont ennek a valós/általános igénynek tesz keresztbe. -
shev7
veterán
válasz Gregorius #520 üzenetére
elkuldod a csomagot, arra varsz ack-ot. Amig nem jon nem kuldesz ujra. Ha nem jon meg idoben, nem tudsz piggybackelni, mert nincs kuldendo csomag. Vagy nem igy mukodik?
''De mint már volt róla szó, az UPC jelenlegi lépése pont ennek a valós/általános igénynek tesz keresztbe.''
Mivel jelenleg nem valos/altalanos igeny, nem tesz neki keresztbe, ha majd az lesz akkor lehet emiatt hoborogni, ha akkor lesz meg egyaltalan ilyen merteku p2p korlatozas...''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
válasz fifi_addict #522 üzenetére
UPC saját állítása szerint portot szűr...
https://www.coreinfinity.tech
-
shev7
veterán
az ugyfelszolgalatos szerint szur portot. Portszureshez nincs szukseg ''darabonként 25-50 ezer dolláros, a Cisco által szállított sávszélesség-menedzselő eszközök''-re.
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
-
shev7
veterán
ha abbol, hogy nehany embernel mukodik a portcsere azt a kovetkeztetest vonjuk le, hogy nincs protokoll szintu szures, akkor abbol, hogy nehany embernel csucsidoben is teljesen jol megy a chello miert nem vonjuk le azt a kovetkeztetest, hogy nincs is semmilyen korlatozast.
De nyugodtan keszithetsz felmerest is arrol, hogy hany emberen segitett, es hany emberen nem a portcsere.''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
Gregorius
őstag
elkuldod a csomagot, arra varsz ack-ot. Amig nem jon nem kuldesz ujra. Ha nem jon meg idoben, nem tudsz piggybackelni, mert nincs kuldendo csomag. Vagy nem igy mukodik?
Ez nem egészen így működik, mert TCP window van, vagyis anélkül, hogy megvárnád az ACK-ot rögtön küldöd a következő csomagokat (max amennyit a TCP stack implementációban beállított window size meghatároz), majd ha az ACK várható időn belül nem jött, akkor a vonatkozó csomagig vissza kell menni a streamben és megismételni az egészet. Ha minden csomag nyugtáját megvárnád, akkor az idő nagy részében a vonal használata helyett vársz az ACK csomagra, a túloldal meg az újabb adatcsomagra. Ehelyett az a feltételezés, hogy a vonal az esetek többségében stabil (különben elkellene egy kis karbantartás a kábeleken), és nyugodtan lehet küldeni a következő csomagot az előző ACK megvárása előtt. Ezen még jobban szoktak bonyolítani, pl. olyan ACK szerkezetek is vannak (SACK), amik egy csomag-range-et nyugtáznak, illetve szelektíven nyugtáznak bizonyos csomagokat (pl, 1,2,4,5 de a 3-as kimaradt), úgyhogy még újraküldeni is sokkal kevesebbet kell. Ha meg feltűnően sok ACK nem jön meg, akkor visszavesz a csomagküldés gyakoriságából, de továbbra sem fogja megvárni minden egyes csomaghoz a visszaigazolást. Így sokkal jobb a vonal kihasználtsága ill. az átviteli sebesség.
Mivel jelenleg nem valos/altalanos igeny, nem tesz neki keresztbe, ha majd az lesz akkor lehet emiatt hoborogni, ha akkor lesz meg egyaltalan ilyen merteku p2p korlatozas...
Azért tesz neki keresztbe, mert most ugyan nem igény (illetve ha volna is, nincs kiszolgálva), de később se lesz a korlátozás miatt. Mert nincs az az agyament a világon, aki hátrányosan megkülönböztetett protokoll köré épít szolgáltatást, ha van más alternatíva is. Ha meg nincs más alternatíva és adott technikai feltételek mellett nem létesíthető az adott szolgáltatás, akkor meg egyáltalán nem lesz. És ez mind a hátrányos megkülömböztetés miatt.
[Szerkesztve] -
shev7
veterán
válasz Gregorius #527 üzenetére
''max amennyit a TCP stack implementációban beállított window size meghatároz''
ugy erted amennyit a fogado oldal meghatarozott neki. Ha elkuldott ennyit varnia kell a visszaigazolasra. Es a tuloldal sem fog minden csomagra ACK-ot kuldeni, hogy csokkentse a halozati terhelest... de ha nem tudja, hogy mekkorara valtozott a tcp window size, mekkora slotot foglal a piggybackben?
''Mert nincs az az agyament a világon, aki hátrányosan megkülönböztetett protokoll köré épít szolgáltatást, ha van más alternatíva is.''
Kepzelem, a UPC miatt nem lesz p2p tv... szolj gyorsan a skypenak, hogy feleslegesen csinaljak a joostot, valasszanak masik aternativat...
[Szerkesztve]''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
Gregorius
őstag
de ha nem tudja, hogy mekkorara valtozott a tcp window size, mekkora slotot foglal a piggybackben?
Nem kellene keverni, a TCP/IP az TCP/IP, a CMTS-ig terjedő adatelérési rétegnek meg köze nincs hozzá, hogy ő most éppen IP protokollt utaztat vagy valami mást. Ha van adat a bufferben, akkor annak megfelelő szeletet kér, ha nincs, akkor meg nem kér.
Ráadásul átlag p2p emberke egyszerre rengeteg másik emberrel forgalmaz, úgyhogy ha az egyiknél nem jön az ack, akkor majd jön a másiktól.
Kepzelem, a UPC miatt nem lesz p2p tv... szolj gyorsan a skypenak, hogy feleslegesen csinaljak a joostot, valasszanak masik aternativat...
Az UPC a precedens. Aztán ha jönnek a többiek, akkor tényleg el fog gondolkodni a skype, vagy egyszerűen megy a versenyhivatalhoz. -
bambano
titán
válasz Gregorius #527 üzenetére
A tcp-ről való beszélgetést kezdjük rögtön azzal, hogy nincs csomag.
A tcp-vel kapcsolatos fejtegetésed ennek okán ment a levesbe.
Az meg különösen fájdalmas, hogy több heti fórumozás után még mindig arról kell beszélni (nem feltétlenül neked címezve), hogy p2p tv streaming a kábeltv technikai kialakítása miatt műszakilag ostobaság.
Szerk: még azt mondd meg légyszives, mi az az adatelérési réteg?
[Szerkesztve]Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
twollah
nagyúr
Nem erdemes a 1.7 Beta Build 2740et hasznalni, mert a hivatalos forumon paran, koztuk en is azt tapasztaltam, hogy a feltoltesi sebesseg nem eri el a kapcsolat maximumat, kb. 50k/secnel megall az egesz es azt stabilan tartja.
Remelhetoleg ez a hiba a kovetkezo betaban ki lesz javitva, addig a 2585os betat erdemes hasznalni.
Koszonom, leulok magamtol. -
Gregorius
őstag
A tcp-ről való beszélgetést kezdjük rögtön azzal, hogy nincs csomag.
A tcp-vel kapcsolatos fejtegetésed ennek okán ment a levesbe
Ezt légy oly kedves és fejtsd ki nekem bővebben, mielőtt szégyenemben még hülyén halok meg.
Szerk: még azt mondd meg légyszives, mi az az adatelérési réteg?
Ehh, fáradt vagyok. Adatkapcsolati réteget akartam írni (OSI layer 2), munkahelyi ártalom (főleg ha az ember adatbázis alkalmazásokat fejleszt). Jelen esetben a DOCSIS MAC.
Az meg különösen fájdalmas, hogy több heti fórumozás után még mindig arról kell beszélni (nem feltétlenül neked címezve), hogy p2p tv streaming a kábeltv technikai kialakítása miatt műszakilag ostobaság.
Ööö. Szerinted az, vagy szerinted nem az? Csak úgy kíváncsiságképpen. -
Flashcash
Közösségépítő
válasz Gregorius #533 üzenetére
Ha a 7 rétegű OSI modellre konvertálunk a 3. hálózati rétegben utaznak a csomagok, a hálózati réteg fölött van a 4. szállítási réteg ahol használhatjuk a TCP-t. A TCP a továbbítandó adatfolyamot szegmensekre bontja ezek kerülnek továbbításra csomagokban.
[link]
Az adási / vételi ablak is egész jól le van írva ezen az oldalon amiről korábban írtál. -
Tomika84
csendes tag
[Nem szoktam a legkisebb flame-re is ugrani, de ilyen szintű személyeskedést, főleg ilyen hangnemben nem tűrök. Cathfaern]
Egyebkent csatlakozok azoknak a taborahoz akik a ''priorizalas'' ellen vannak, aki csetelni, emailezni, bongeszni akar az hasznaljon dial-up-ot... nehogymar 10 megat bongeszesre kelljen hasznalnom... -
-
Tomika84
csendes tag
na ja. nem tiltja csak korlatozza kulonbseg
egyebkent en ebben az egesz szarban egyvalamit nem ertek. van olyan, mert biztos van, aki nonstop full savszellel huz httprol, ftprol stb. Azok nem terhelik a rendszert/nem veszik el az ertekes savszelt a tobbi usertol? Ugyanmar, parasztvakitas, semmi mas. -
shev7
veterán
válasz Tomika84 #537 üzenetére
jaj ne, kezdodik elorol... de sokadszorra is: a problemat nem a letoltes, hanem a feltoltes jelenti... ha erdekel a tema akkor olvasd vissza a topicot, nem szegyen. Ha meg csak flamelni akarsz, akkor abbol nem kerunk, volt mar eleg...
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
Tomika84
csendes tag
Aham, szoval ha en toltok fel 50 k-val akkor az bezavar herpeszes odonke csetelesenek. mennyire sajnalom hogy nem fel perc alatt toltodnek be a kepek neki hanem 2 perc alatt...
-
bambano
titán
válasz Gregorius #533 üzenetére
A tcp nem nyújt csomag jellegű szolgáltatást a felhasználó felé. A többiről az előbb ide beszúrt linken tájékozódhatsz.
Kábeltv-n a visszirány szűkös, drága erőforrás, sokkal szűkösebb, drágább, mint az előreirány. Emiatt kábeltv-n p2p jelleggel tv-t streamelni, hogy finoman fogalmazzak, nem hatékony. Kár, hogy ennyi vita és flame után ez még kérdés, mert ebből arra lehet következtetni, hogy sokan nem olvassák el a fórumot, mielőtt hozzászólnak.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Gregorius
őstag
Mivel az ip ''modell'' 5 rétegű és kb. 10 évvel korábban készült, mint az osi, nem lehet, ergo nem is érdemes ip hálózati technológiát osi ajánlás rendszerben elemezni.
Írhattam volna az IP adatkapcsolati réteget is, teljesen mindegy. A hálózati rétegig a két modell meglehetősen hasonló.
A tcp nem nyújt csomag jellegű szolgáltatást a felhasználó felé.
A TCP a csomagalapú IP igénybevételével nyújtja, amit nyújt, és a MAC réteg ezeket az IP csomagokat szállítja. Legyen az TCP, UDP, ICMP, ESP, GRE vagy úgy nagyjából akármi.
Kábeltv-n a visszirány szűkös, drága erőforrás, sokkal szűkösebb, drágább, mint az előreirány.
Javíts ki, ha tévednék, de ez azért van így, mert a sok végberendezés zaja akkumulálódik visszafelé a kábelen és nem azért, mert egy-egy eszköz túl sokat dumál.
Előreirányban meg mindig csak egy eszköz dumál, a CM pedig válogat, hogy mi vonatkozik rá.
Egyébként meg a koax nagyságrenddel nagyobb frekvenciatartományban használható, mint a csavart rézdrót.
[Szerkesztve] -
bambano
titán
válasz Gregorius #543 üzenetére
A két modell hasonló: eltekintve attól, hogy ip-t szoktunk látni, teljesen 100%-ban megvalósított osi szabvány szerinti hálózatról meg nem tudok. Részben megvalósított is csak kevés volt. Ergo egy szabványosítási szervezet álmaiban töredékesen létező rendszert próbáltok rendszeresen ráhúzni valamire, ami szerintem teljesen kézzelfogható.
Továbbra is forszíroznám: a tcp nem nyújt csomag alapú szolgáltatást. Ezért korábbi hsz-edben írt: x,y csomagokat ack-olja a tcp szöveg hibás. Bájtsorozatról szól a tcp és az ack szám mindig azt mondja meg, melyik a következő bájt, amit vár. Amivel implicite nyugtázza az ack-1 bájtig egyszerre az összeset.
Kijavítalak: tévedsz. Nem a sok végberendezés zaja a gond, mert azok elvileg csak akkor beszélnek, ha szabad nekik, a nem modem jellegű cuccokat meg illik szűrni rendes hálózaton, hanem azok a rövidhullámú zavarok okoznak gondot, amelyek a külvilágból bejutnak a kábelbe valamilyen árnyékolásban fellépő probléma miatt. Pl. illegálisan nagy teljesítménnyel adó török rádiók, ukrán rádióamatőrök jele bejuthat egy víz ellen rosszul szigetelt, kontakthibássá váló csatlakozón. Vagy rossz a bandázsolás és megfújja a szél a kábelt, akkor szakadozhat az árnyékolás folytonossága.
Az előreirány azért tisztább, mert a jobb minőségű, jobban karbantartható kábeldarabról megy a jel a rosszab felé. Az optikába vagy a föld alá dugott 8-as kábelbe nehezebben megy bele a zavar.
Egyébként meg ennyire általánosan megfogalmazva, hogy a koax nagyobb frekvencia tartományban használható, mint a réz, nem igaz. Távolság és csillapításfüggő. Milyen jeleket, milyen távolságra, milyen elvárt maximális csillapítás mellett akarsz továbbítani.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Az állítás egyik része az, hogy kevés a visszirányú kapacitás. Ennek az oka, hogy kevesebb frekvencia áll rendelkezésre, másféle kódolást kell használni. Ezt a kevés visszirányú kapacitást tovább rombolja, ha karbantartási vagy egyéb okok miatt a török rádió bejut a kábelbe és lerontja a jel/zaj viszonyt.
Ezt úgy kell elképzelni, hogy adott frekvencia mennyiség használható visszirányú adatátvitelre (egy jobb hálózaton elvileg 5-65MHz között), ebből az 5-18 vagy az 5-22 MHz közötti frekvenciák nem, mert a török rövidhullámú rádiók (meg a többi is nyilván) ide piszkol és gyakran nem elég jó a kábel ehhez. 45 MHz környékén van a légiforgalmi irányítók néhány sávja, ott megint tilos adni. 45-60MHz környékén van a régi oirt szabvány szerinti O1-O3 csatornák, ahol még elvileg működhetnek tv-k. Szóval abból a 60MHz-ből, amit elvileg tudhat a drót, kb. 25-44 között használható gyakorlatilag. Ide kell bepakolni a visszirányt. Ha végiggondolod, hogy nem jön be a török rádió, nincs oirt tv, lri-nek meg fityisz, mindjárt 3x akkora kapacitás lehetne. De ez a szabvány, ez az irányító hatóság döntése, nincs apelláta.
A p2p streamingen alapuló tv-k meg pont ezt a szűkös kapacitást sámfázzák ki, fullosan. Ezért kábeltv-n nem praktikus ilyet csinálni. Jobb, ha a központból jön multicast routinggal.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Gregorius
őstag
A két modell hasonló: eltekintve attól, hogy ip-t szoktunk látni, teljesen 100%-ban megvalósított osi szabvány szerinti hálózatról meg nem tudok. Részben megvalósított is csak kevés volt. Ergo egy szabványosítási szervezet álmaiban töredékesen létező rendszert próbáltok rendszeresen ráhúzni valamire, ami szerintem teljesen kézzelfogható.
Kössél már bele abba is légy szíves, hogy a kábelen IP elektronok rohangálnak és nem OSI elektronok Nem mondtam, hogy nagyvonalakban mindegy?
Továbbra is forszíroznám: a tcp nem nyújt csomag alapú szolgáltatást. Ezért korábbi hsz-edben írt: x,y csomagokat ack-olja a tcp szöveg hibás.
Továbbra is forszíroznám: a TCP az IP csomagalapú protokollt veszi igénybe. Figyelembe véve, hogy adat kétféleképpen nem érkehet meg - 1) a vonatkozó IP csomagban foglalt szegmens útközben elveszett packet drop miatt és 2) a CRC-ellenőrzésen nem megy át - csak egész szegmensek fognak elveszni, vagyis az esetek többségében mindegy, hogy most akkor oktettenként ack-olunk, vagy csomagonként, mert úgyis valamelyik IP csomagban foglalt szegmens seq#-e (plusz a payload hossza) a következő ACK tárgya. Akkor nem felel meg pontosan egy szegmens egy csomagnak, amikor durva fragmentálódás történik a hálózaton, de az egyrészt nem az indulási (upstream) oldalt rondítja el, hanem az érkezésit, ami esetünkben - kábeltévé - nem érdekel senkit, másrészt pedig az összeszerelés az IP rétegben történik, vagyis a TCP már az összerakott szegmenst fogja megkapni.
Kijavítalak: tévedsz. Nem a sok végberendezés zaja a gond, mert azok elvileg csak akkor beszélnek, ha szabad nekik
Az elvileg meg az ideális esetben az, amit ember még nem implementált.
A koaxnak sajnálatos tulajdonsága, hogy a környezeti viszonyoktól függő a késleltetése (és ez ráadásul frekvenciatartományonként különböző lehet, úgyhogy még a jel is szépen torzul). Namost a CM első dolga, hogy időt szinkronizál a CMTS-sel, hogy mindig pontosan az előírt időrésben tudjon adni (ez is csak bizonyos hibahatáron belül működik), de azt nem tudja kiszámolni, hogy a késleltetésingadozás miatt mennyit fog egyik vagy másik irányba csúszni (és így az előírt résből kicsúszni) az adása.
Másrészt akármilyen hűdeszuperjól csinálták meg az eszközt, a jelfelfutás/lefutások, visszaverődés, illesztések, stb miatt minimális zajterhelés akkor is van a kábelen, ha éppen nem dumál.
Egyébként meg ennyire általánosan megfogalmazva, hogy a koax nagyobb frekvencia tartományban használható, mint a réz, nem igaz. Távolság és csillapításfüggő. Milyen jeleket, milyen távolságra, milyen elvárt maximális csillapítás mellett akarsz továbbítani.
Figyelembe véve, hogy a Cat7 csavart réznek a felső határa ideális esetben olyan 600MHz, egy tisztességesebb szélessávú koax meg hasonló körülmények között olyan 50GHz-ig is elmegy, állításomat fenntartom. Speciális esetekben a csavart réz lehet az előnyösebb (pl. jóval olcsóbb, kevesebb helyet foglal, stb...). -
wwenigma
Jómunkásember
Erre én sem tudtam volna válaszolni... 1:0 oda?
Steam: http://bit.ly/1rRuf8p , Origin: wwenigma -- | -- Jiayu F1 / G3C / OT995 cuccok: http://bit.ly/1w44CI2 -- | -- ZTE V5 Red Bull -> http://bit.ly/1mgtfrd -- | -- Xiaomi RN3SE -> http://bit.ly/2r8DlV7 -- | -- Live Stream: twitch.tv/wwenigma
-
VINIKOR
senior tag
Na most aztán tényleg lassú lett az upload. Eddig 50 kBps-el úgy ahogy csordogált, most 30 alatt megy. Én nem is bánom. Éjjel és délelött megy maxon, bőven elég. Határozottam érzem, hogy kevésbé laggos a netes FPS játék és nekem ez napközben talán még fontosabb, mint az upload.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs