Új hozzászólás Aktív témák
-
Gregorius
őstag
Olyan álszent faszok vannak a világban, hogy az már szégyenletes, már bocsánat a kifejezésért.
„Ha az összes modem sebességét megnöveljük, de közben nincs még mögötte elégséges hálózati kapacitás, akkor könnyen torlódások alakulhatnak ki
Akkor nem kell megnövelni a modem sebességét és különösképpen nem a megnövelt sebességet kell reklámozni, különben megyünk a GVH-hoz.
a UPC a forgalom alkalmazásszintű priorizálásának bevezetésével a nemzetközi trendet követi.
Ja. Kövessük a nemzetközi trendet, legalizáljuk a fegyverviselést, tartsunk lövöldözőbulikat az iskolákban. Azt eszükbe sem jutott megnézni, hogy hány nemzetközi ISP-nél működik hatékonyan a sávszélmenedzsment, és hánynál lehet óvodás módszerekkel megkerülni? Mennyibe is kerültek a berendezések meg az infrastruktúra amúgy?
A T-Online kérdésünkre elmondta: jelenleg nem tervezik ilyen hálózatmenedzsment alkalmazását
Nem hittem, hogy a múltkori összebalhézásunk után ki fogom mondani, de nekik legalább egy kevés eszük maradt.
„Végül is a szolgáltató ugyanazt csinálja nagyban, mint a felhasználó kicsiben”
Aha, csak az az apró különbség, hogy a szolgáltató nem abból a sávszélből gazdálkodik, amit ő fizet, hanem abból, amit neki fizetnek.
[Szerkesztve] -
Gregorius
őstag
Ha jól van implementálva, akkor a szolgáltató nem tudja megkülönböztetni egy https request-től (pontosabban egy olyan ssl/tls csatornától, amit például a https is használ). Legfeljebb port alapján. De kicsit ciki lenne jogilag, ha bizonyos biznisz körökben nagyobb nevű oldalak bizonyos szolgáltatásai azért nem elérhetőek, mert a kérdéses ISP blokkolja a kérdéses portjukat. Versenyelőny, stb...
Mehetsz te akár hova, a felhasználók 90%-a észre sem fogja venni ezt az egészet, az a bevételkiesés amit meg a notórius letöltők átpártolása fog okozni irreleváns.
És innentől kezdve az egész forgalomszabályzó izébigyó, amit az előfizetők pénzéből szerveztek be elveszti értelmét, merthogy aki miatt bevezették, az ''már nincs a cégnél''.
Még ez jutott eszembe hirtelen a ''nemzetközi trendről'': [link]
the Act would make it unlawful for any broadband network provider to discriminate against any content, applications, or services
És ez a szabadságjogokat oly messzemenőleg ''tiszteletben tartó'' USÁban törvény. -
Gregorius
őstag
az nhh és a gvh mindent jogosnak talált
Ez azért nem egészen így volt. Az érintettet utólag kötelezték arra, hogy a megfelelő helyeken tűntesse fel a vonatkozó információkat az ÁSZF-ben és már ez is óriási különbség.
kapjon prioritást a ewb, meg a mail, meg az ftp... de ha ezeknek a forgalma kicsi
Miért kapjon? Hogy a web meg a mail meg az ftp szolgáltatást megvalósító termékeket forgalmazó cégek versenyelőnyhöz jussanak?
Nem, ezektol a felhasznaloktol akarnak az isp-k leginkabb megszabadulni, mert nem hozzak a penzt, hanem viszik...
És ez mindaddíg így lesz, amíg valami normálisabb ember a vezetésben nem jön rá, hogy forgalom alapján elszámolni hülyeség. Különösen akkor, ha ez a ''nagy'' forgalom pont csúcsidőn kívül esik és kihasználja az amúgy pangó kapacitásokat, amit a kedves szolgáltatónak inkább megköszönnie kellene a kedves felhasználó felé. Mert ugye a sávszél akkor értékes, amikor kevés van, vagyis csúcsidőszakban, amikor mindenki a neten lóg. Akkor viszont a hevijúzer is annyit fogyaszt, mint bárki más.
Hogy megnyerje a UPC a Nagy Magentaval szemben a kinek van nagyobb farka versenyt?
Ó, az üzleti élet más területeken is nagyjából erről szól.
[Szerkesztve] -
Gregorius
őstag
válasz
VladimirR
#35
üzenetére
ha nekem dolgozni kell a net, nem tud erdekelni, hogy te eppen hekkel windoze-t toltesz,
Ha nem tudsz dolgozni a dugó miatt, fizess be bérelt vonalra
Hogy is van ez a ''tartalomalapú priorizálás''? Pláne egy random forrás- és célporttal működő bittorrent-kapcsolatnál?
Valószínűleg protokollalapú prioritiziálásra gondolt. Vannak már eszközök, amelyek felismernek bizonyos protokollokat legyen az sima http, streaming, p2p vagy akármi. De mondtam korábban, hogy csak egy ssl csatornát kell az egész elé húzni és ennyi volt. -
Gregorius
őstag
válasz
VladimirR
#47
üzenetére
szoval elofordulhat, hogy alig 10 user ki tud nyirni egy olyan vonalat, amin tobb szaz felhasznalo csung
És szerinted abból a több 100-ból melyik lesz az a 10?
a szolgaltato nekem akar majd kedvezni, akibol penze van, nem annak az 1-2%-nak, akikre rafizet
Az apró pici probléma kérlekszépen az, hogy erre az 1-2%-ra azért fizet rá, mert forgalom alapon számol el a felettesével. Ha elszámol. Aki milliókért kihúzza a hűdesok kábelt, mert a kedves júzer hájdef sztrímingben akarja nézni a ValóVilág X-et, izzanak a vezetékek p2p nélkül is (vagy éppen a p2ps is visszahúzta a forgalmát, hogy internetezhessen). Elvégre a youtube meg hasonlók korszakát éljük vagy mi. Aztán amikor mindenki elment aludni, akkor ezek a milliókért behúzott kábelek csak egy dolgot csinálnak: villanyszámlát. És akkor is ugyanannyi kiadása volt a hálózat kiépítéséből illetve van a hálózat fenntartásából, ha egy bit forgalom nem megy át rajta, mintha csontra ki lenne terhelve (feltéve hogy a router nem kapcsol energiatakarékosba, márpedig ez tudtommal nem jellemző, és a kósza packetek is szépen meg tudják akadályozni). Most akkor miért is az a racionális, hogy az az 1-2% a ráfizetés, aki akkor is használja a rendszert, amikor annyi a szabad erőforrás, mint a szemét?
[Szerkesztve] -
Gregorius
őstag
válasz
VladimirR
#67
üzenetére
''És szerinted abból a több 100-ból melyik lesz az a 10?''
nem egyertelmu?
Valószínűleg azért tettem fel a kérdést, nem gondolod?
nem nezek vv x hd stream-et egesz nap es egesz ejjel, mint ahogyan jutub videokat sem toltok megallas nelkul
Helyetted megteszi öt másik. Tudod a családomban épp manapság kezd el terjedni az internetes csevegés, merthogy sokkal olcsóbb, meg webcam meg minden, és még a leganalfabétább műveletlen családtagjaim is erőfeszítés nélkül el tudnak indítani egy videóbeszélgetést MSN-ben, holott lehet, hogy egy szoftver letöltése és telepítése már gondot okozna.
viszont a p2p (foleg a torrent) igenis allando jellegel igenybe veszi a halozatot, mer' hulye pistike akkor is hagyja maxon futni, mikor mar vegzett, mer' kell a jo arany, kulonben kivagjak a tracker-rol, mint azt a bizonyos macskat
Nemteccikérteni, hogy az állandójellegű kihasználás csak akkor számít, amikor szűkében vagyunk a kihasználandó dolognak?
rendkivul egyszeru pelda kovetkezik: mikor elmesz dolgozni, vagy mikor pl alszol, megy melletted a hd-s videostream? nem? nalatod
A rendkívül egyszerű példád világít rá pontosan a lényegre: olyankor másnak se megy a hd-s videostream. Üresen pang a vonal. Az a maradék 10 júzer a százból meg ilyenkor már hadd kezdjen vele amit akar, a maradék alvó 100at úgyse fogja zavarni.
azt hiszem a hirben is le volt irva, hogy ha lesz love rendesen a priorizalas, s akkor lesz nagy orom es bodotta', egesz ejjel maxon tephet a p2p le- es/vagy feltoltesed, csak, hogy a szolgaltato ra ne b....fizessen
Mert éjjel nincs értelme prioritizálni, nappal meg diszkriminálod azt, aki más szoftverrel csinál ugyanolyan forgalmat, mint a többi. Ezt tényleg ilyen nehéz megérteni?
(komolyan mondom, teged ettol sokkal ertelmesebbnek ismertelek meg a forumon)
hogy mikor savszelesseg engedte keretek elfogytak, akkor a kevesbe fontos tartalmak hatterbe szoruljanak
És milyen alapon az ISP mondja meg, hogy nekem mi a fontos? Például én csak órák alatt tudom elküldeni levélben a hétvégi családi fotókat, mert Mancika két háztömbbel arrébb épp színes szélesvásznon bájcseveg a pasijával, és pont a streaming forgalomnak van prioritása, akkor az hol igazságos nekem?
Lehet, hogy a dinamikus prioritizálás nagyságrenddel jobb, mint egy statikus korlát, de még mindig messze van az igazságos használattól. -
Gregorius
őstag
válasz
VladimirR
#86
üzenetére
kezdelek nem erteni
az elobb az volt a baj, hogy a kihasznalatlan halozat ugyanolyan draga, mint a kihasznalt, most meg nem szamit?
A kihasználatlan hálózat az ISP-nek ugyanolyan drága, mint a kihasznált (most itt szigorúan a technikai üzemeltetésre gondolok, az elkefélt bérleti konstrukció nem ide tartozik), éppen ezért nem számít, hogy valamelyik felhasználója bonyolít-e forgalmat az üres kábelen, vagy nem. Akkor számítana, ha válogatni kellene, hogy melyik csomagot küldjük tovább és melyiket dobjuk el, de akkor meg az átlagjúzer az ahogy a csövön kifér sztrímingjeivel semmivel nem használ kevesebb sávszélt, mint a p2ps, így semmi alapja nincs a hátrányos megkülönböztetésnek.
nem. ez a diszkriminacio nekem tokeletesen megfelel. ha majd nem fog, keresek mas szolgaltatot
Szíved joga. Nekem nem. Többek között ezért nem vagyok csellós. Plusz még a hosszútávú világképemet is birizgálja, ha bevett precedens lesz, mert például a ''nem ismert'' protokollokat implicit besorolják az alacsonyabb prioritásúak közé, aminek következtében egy új innovatív fejlesztés, ami saját protokollt használ rögtön versenyhátrányból indul, mert nem tudja ugyanazt a minőséget elérni, mint a bevett protokollok, amiknek magasabb a prioritása.
Ritkán használok csak p2p-t, akkor is nagyrészt olyan dolgokat szedek le, amik ritkaságnak számítanak...így hiába áll rendelkezésemre akár 100mbit is, a kevés feltöltő miatt úgyse jön rendesen.
No igen, ez a másik, hogy hosszú távon a p2p letöltés nem nagyságrenddel nagyobb a feltöltésnél, az meg valahol a kínált letöltési sebességek tizede-huszada körül van mostanság.
[Szerkesztve] -
Gregorius
őstag
válasz
VladimirR
#109
üzenetére
Közben szerk volt, lemaradt egy mondat.
Ja, még valami. Ha ez bevett gyakorlattá válik, akkor mi akadályozza meg az ISP-t, hogy a saját maga által kínált sztríming kontentet (mert most már elég sokan csinálnak ilyet is) részesítse előnyben a mások által kínálttal szemben?
[Szerkesztve] -
Gregorius
őstag
válasz
VladimirR
#111
üzenetére
erre irtam korabban, hogy az atlaguser az eletben nem fog 7/24 online tv-zni
az meg, hogy megnez heti 1-2 filmet (mondjunk nagyot, mondjuk 2 mbps-os stream-bol) meg mindig sehol nincs az ejjel nappal p2p-ezokhoz kepest
De csúcsidőben fog. Van 100 júzer, ebből 10 csúcsidőben tévézik, 1 meg p2p-zik. Akkor miért a p2p-t kell lehúzni?
A másik meg, mint írtam a p2p a szimmetria okán hosszútávú átlagban sokkal közelebb van a tizedakkora feltöltési sebességhez, mint a letöltésihez (határesetben meg pontosan egyezik), még ha csak a csúcsidőt nézzük, akkor is.
nem is beszelve arrol, hogy a p2p lenyegesen nagyobb esellyel oli meg a feltoltest (is)
A feltöltésen is ugyanúgy lehet egálban osztozkodni, mint a letöltésen.
en olyan melysegekig nem etrtek hozza, de olvasd el bambano masik topic-ba irt post-jait => Bovebben: [link]
o helyenkent szamadatokat is hoz
És azok a számadatok arányaiban stimmelni fognak holnap is? Két hét múlva? Két hónap múlva? Két év múlva? Egy évtizede gyakorlatilag nulla volt a sztríming részesedése, mert nem létezett olyan hülye a világon, aki egy 56k-s vonalon képanyagot átpumpál (de még ha ez lett volna a cél, kínálat sem volt), manapság meg már trendi.
Az meg a másik probléma, hogy hogyan is tudja kiszorítani az egyik a másikat? Mintha a routert úgy kellene implementálni, hogy ha nem fér át mindkét forgalom, akkor egyszer az egyikből enged egy kicsit, egyszer a másikból. De nem úgy, hogy ötször az egyikből és egyszer a másikból. -
Gregorius
őstag
válasz
VladimirR
#120
üzenetére
Te még mindig ott toporogsz, hogy az a kis számú barom, aki dugót csinál mind p2pzik.
mert tobbnyire barmokrol van szo, akik orrba-szajba warez-t toltenek p2p-n, a kivetel szinte elhanyagolhato
És minden bizonnyal alá is tudod támasztani, hogy az összes barom mind orrba szájba p2p-zik, holnap is arról lehet megismerni a barmot, hogy p2p-zik, meg két hét múlva, meg két hónap múlva, meg két év múlva is.
priorizaljuk a forgalmat (ha ugy tetszik korlatozzik a p2p-t), hogy az a par barom ne tudja megfektetni a halozatot
Így meg papíron is a másik barom tudja megfektetni neki. Jobb?
mint ilyen jo esellyel talalkoznod kellett mar a priorizalassal, utemezessel, mint fogalommal, annak alkalmazasaival, szuksegessegenek okaival
És mint ilyen találkoztam az ütemezés fairségének kérdésével is. A kiéheztető ütemezésekről meg akkor ne is beszéljünk.
ilyenkor mindig hatterbe kell szoritani valamit, hogy a tobbiek annak karara haladhassanak fennakadas nelkul
De miért mindig ugyanazt az egyvalamit kell háttérbe szorítani?
ha az altalad oly sokat emlegetett streaming media okozna hasonlo problemat (megintcsak oszinten: ki hany orat tolt nagy felbontasu streaming videok (pl normalis meretu filmek) bamulasaval?)
És holnap hány fog, meg két hét múlva...
ha az altalad oly sokat emlegetett streaming media okozna hasonlo problemat valoszinuleg nem mernenek egy ilyen huzast megengedni maguknak (foleg, hogy ott nem 1-2 user-rol lenne szo)
Az csak egy példa volt. Itt egy másik: [link]
Olyan aszimmetrikus (ld. #123) a megoszlása a dolognak, hogy csúcsidőben a közönséges webes forgalom a linkelt angol ISP hálózatán volumenben eléri azt a szintet, amit holtidőben a korlátozatlan p2p (Csúcsidőben korlátozzák a p2p-t, úgyhogy az ottani adat nem releváns). (Gyanítom, hogy a streamingbe itt csak az mms/rtsp/hasonló dolgokat vettek bele protokoll alapján, pedig ilyet lehet http-n is művelni.) Tavalyi adat.
Közben találtam egy ideit is még durvább aránnyal: [link] (lap közepén)
(Lefotóztam, hogy ugyanazt nézzük, mert úgy tűnik, hogy automatikusan frissül a kép: [link])
Most vagy az van, hogy a p2p-sek leléptek nevezett szolgáltatótól (monjduk ezt nem nagyon hiszem, mert pl. 06:00-kor ugyanakkora a használt sávszél, mint előző évben), vagy a webes forgalomnak sikerült lelépnie a p2p-től csúcsidőben. Méghozzá komolyan.
aki mondjuk lehúzott már az adott hónapban X Gigabájt adatot, annak a p2p sebességét csökkentsük, kizárólag akkor, ha a sávszélesség valóban teljesen le van terhelve
Ez csak elvben hangzik jól, lévén a szabad sávszélesség ''megújuló'' erőforrás. A hónap első napjaiban ugyanúgy szarrá fogja terhelni a hálózatot, és a hónap végén, amikor a komáival együtt letiltották, kiürül a sztráda.
[Szerkesztve]
[Szerkesztve] -
Gregorius
őstag
Kicsit sántít az áramszolgáltatós példa, mert ott vannak a reaktorok az egész mögött, aminek a vonatkozó üzemanyagát teljesítményarányosan használják fel (vagyis X kWh rendszerbe táplálásához kell Y köbméter üzemanyag), ezért jobb a ''forgalomarányos'' díjszabás. Magának a hálózatnak a karbantartási költsége az viszonylag független a forgalomtól (a bővítésektől eltekintve), mint az internet esetén. Az interneten viszont az ''üzemanyagot'' nem a szolgáltató állítja elő, hanem a végpontok.
Az autópályás példához meg annyit, hogy a kamionokat sem kötelezik, hogy előreengedjék a többi autót a dugóban, pedig ők éjjel-nappal járják az utakat, pedig sokkal gyakrabban szolgálnak ki szürke ügyleteket, mint a többi autó.
az nagyon szar duma, hogy ugy akarod itt eladni a p2p-t, torrentet, mintha javatreszt (szinte kizarolag) nem warez menne rajta
Még egy gondolat, amit múltkor elfelejtettem. Ha le van korlátozva a p2p, akkor nem is fog menni semmi rajta, csak warez (vagy még az sem). Azon egyszerű oknál fogva, hogy a warezolók vannak annyira dörzsöltek, hogy megkerülik a hátrányos megkülönböztetést obfuszkálással meg hasonlókkal, és router legyen a talpán, aki egy p2p meg egy nem p2p (pl. https) SSL kapcsolat között különbséget tud tenni. A másik oldalon a kereskedelmi használók pedig választhatnak aközött, hogy magyarázkodhatnak, hogy miért játszák ki az ISP szabályzatát meg aközött, hogy lévén a lekorlátozott protokoll a célra használhatatlan, másik protokollt választanak.
Egy ilyen jellegű szabályozás a warez célú innovációt serkenti (a tettenérés nehezítésével) és a legális kereskedelmit gátolja.
[Szerkesztve] -
Gregorius
őstag
#397:
de igen. és? én speciel nem látok abban semmi kivetnivalót abban, hogy a saját hálózatán a saját szolgáltatását akarja kínálni.
Ezt hívják a GVH-nál árukapcsolásnak. Főleg ha a másik szolgáltató hasonló termékének a rovására csinálja.
#399:
ha a robogósokat nem korlátozzák, hogy csak akkor mehetnek, ha nincs a közelben kocsi, egyébként meg az út szélére kell lehúzódniuk, akkor igen kevés kocsi fog elmenni ott
Tudod régóta várom, hogy a kamionokat kitiltsák a Hungária körútról (különösen azokat, akik a Salgótarjáni út mellett hidat visznek - gy.k. beékelődnek a vasúti felüljáró alá), mégsem ez történik.
#404:
1. ugrik a reklámban az astra hátraszaltót? ugrik. Ha veszel egy astrát a valódi életben, az ugrik hátraszaltót? Nem ugrik. Bepereled ezért a General Motors EMEA részlegét? Nem pereled.
Magyar ember nem pereli. Viszont egy amerikai úgy megnyerne egy ilyen pert, mint a pinty.
#409:
Szerintem meg teljesen rendben van, hogy az upc magántulajdonába nem ugat bele senki.
De beleugat. A hírközlési főfelügyelet meg a gazdasági versenyhivatal is.
#411:
csakhogy a szervernek az adatfolyamot kapcsolatonként, csomagonként kell feldolgozni.
Tudtommal a routing IP rétegben megy, ott meg nincs olyan, hogy egy kapcsolat meg 100 kapcsolat. Viszont IP cím alapján lehet ütemezni, hogy az egyik júzer ne húzhassa le a másikat és így 50:50 arányban osztoznak a sávszélen. Protokolltól függetlenül.
#424:
de valszeg ha a torrent (bocs, a p2p) nem lenne aránytalanul magas a csomagok között, akkor nem lenne ez a nagy felhajtás.
Nemtom, itt csak én olvasok vonatkozó cikkeket?
Web Traffic Overtakes Peer-to-Peer (P2P) as Largest Percentage of Bandwidth on the Network
[link]
Megjegyzem a korábban linkelt UK-beli szolgáltató grafikonján is ez látszik.
#451:
C. Elnyomjuk a terhelt teruleten a p2p forgalmat. A nagy atlagnak ez jo, ok orulnek, lehet fel sem tunik nekik. Verpistike meg majd tolt ejjel, vagy lelep az ADSL-hez aminek meg a UPC orul.
Az ügyfelek két hónappal később lépnek le az ADSL-hez, mert akkorra már p2p nélkül is bedugul a net.
Nincs utkozes, a fejallomas majd jol beosztja a savszelesseget, hogy mindenkinek jusson. Felfele osztott kozeg, ha nagy a terheles, akkor a tul sok az utkozes, a fejallomasra el sem jutnak a csomagok, hogy sorrendezze oket.
Ennek nézz utána, a kábeltévés internet valóban osztott közeg, de szigorú időosztás van, vagyis az ütközés kizárt, ha minden eszköz jól működik (ld. még DOCSIS, [link]). Ütközés kizárólag akkor van, amikor saját időszeletet igényel egy modem, de az külön kontroll sávon megy. Akkor van gáz, ha egy kábelmodem megdöglik és nem a saját időrésében kezd adni, de az ilyet jobb esetben elég hamar lekapcsolják a rendszerről. -
Gregorius
őstag
Igazad van, csak adaskereskor lehet utkozes, de ugye nem mondod azt, hogy ez nem jelent problemat, akkor ha van par user aki csucson jaratna a feltolteset...
Nem egészen, mert egyrészt tök külön időszelet van csak erre fenntartva és a CMTS mondja meg, hogy mikor és hány darab (vagyis ha tényleg nagy a terhelés a kontroll csatornán - pl. a rendszer teljes újraindításakor, amikor mindenki egyszerre akar belépni - akkor a CMTS megszaporítja ezeket az időszeleteket - az adatcsomagok rovására), másrészt pedig ez az időrés-újraelosztás sokkal ritkábban történik meg, mint egy átlag csomagküldés, és olyankor többnyire csak a frissen belépő eszköz dumál a hálózaton. Azután pedig a CMTS drákói szigorral összeállítja az új mappinget (figyelembe véve az előfizetői csomagokat is), hogy ki mikor adhat, majd broadcasttal leküldi mindenkinek, és onnantól kezdve az a törvény. Akármit csinál a hevijúzer, ezt nemigen tudja megakadályozni anélkül, hogy a berhelt modemével együtt letiltanák a hálózatról.
#492:
Mintha ezt linkeltem volna fentebb... -
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).
-
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. -
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] -
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. -
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. -
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] -
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...).
Új hozzászólás Aktív témák
it Hazánkban először a UPC vezeti be az adatforgalom alkalmazásszintű menedzselését.
- Amlogic S905, S912 processzoros készülékek
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Milyen belső merevlemezt vegyek?
- Yettel topik
- Melyik tápegységet vegyem?
- Luck Dragon: Asszociációs játék. :)
- PlayStation 4
- Mesterséges Intelligencia topik
- Robotporszívók
- Garmin Forerunner 255 Music - nem csak futóknak
- További aktív témák...
