Tesztet kérünk szépen (majd)
Sok helyen olvastam már ilyen kütyüről, nem egy embernek jutott eszébe ilyesmi; de, ha beválik és a licenszekkel sem lesz nagy probléma... akkor szerintem hamar el fog terjedni, idővel pedig valami beépített (routerbe, hálózati csatolókba) verziót is el tudnék képzelni.

www.theskynet.org - Hungary alliance

Aztán majd a tré-online ezt is betiltja, és a linksys weboldalát majd nem lehet elérni sem... kíváncsi vagyok, letöltés közben mennyi lenne egy ilyenne la pingem.
Egy másik kérdés pedig: ha ezt bekötöm mondjuk a gépem és a wifi access point közé, akkor elérhetem vele, hogy prioritást kapjak aznon a hálózaton, amire csatlakozok és ahonnan a netet is kapom?

A vér nem válik VAZZE!™

ne beszelj mar fas....ooo....butasagokat, miert tiltana be?
tudom, most jon az, hogy ''de bezzeg a cfos....'' - egen, par orat le volt tiltva, mert csak annyi latszott, hogy egy ip-re nagyon nagy forgalom megy, dos-nak veltek, levagtak
miutan kiderult, levettek a tiltast, azota egy parc kihagyas nem volt
azt aruld mar el, miert kell mindenbe belekeverni az esz nelkuli fikazast? nem volt gyerekszobad?

a kerdesed nem teljesen tiszta, de nem te kapsz prioritast, hanem bizonyos csomagtipusok - letolteni nem fogsz gyorsabban, de a game, es a a/v atvitel (elvileg) nem fog akadozni

engem inkabb az erdekelne, hogy mi alapjan ad ez kisebb/nagyobb prioritast a csmagoknak? port alapjan?

Gondolom a cikk egy az egyben átvett valami marketing anyagot, mert amit ide írt, az önmagában is ellentmondásos. Ha a nagyméretű letöltések melletti voipozáson akar segíteni azzal, hogy a forráshoz közel vizsgálja a forgalmat, akkor az nem az előfizetői adsl modemnél van, hanem ott, ahol a letöltés szervere van, esetleg az adsl carrier szolgáltató forgalomátadási routerében. A kimenő forgalom szabályozásának elvben lenne értelme, de egyrészt az nem a letöltéskor számít, másrészt azt ténylegesen a forrásnál, vagyis a pc-n futó oprendszerben kell/érdemes csinálni. Ennek az eszköznek a hasznossága szerintem egyenlő a dvd visszacsévélő gép hasznosságával.

A linksysnek meg további gondolkodásmentes jónapot kívánok.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

nincs ebben ellentmondás, hiszen a voip (váltakozó irányú adatforgalom) egyik forrása a felhasználónál van, és ott előnyt biztosít neki ez a szerkezet a letöltéssel szemben. tény, hogy az interneten még bármi megeshet a voip csomagokkal, de a felhasználó oldalán legalább rendben vannak. a voip-es pc-n hiába priorizálod a forgalmat, ha a letöltés egy másik gépen megy, és a router nem ismer qos-t.

szerintem arra celzott bambano, hogy ha vesz a user egy ilyet, attol neki nem lesz jobb
a beszelgetopartnerenek, aki az o bamba kepet bamulja a neten keresztul, annak igen, de a mi user-unknek nem (hacsak nincs a masik felnel is egy ilyen ketyere)

A letöltés a világból befelé, a gép felé jön és relatíve kevés ráhatással tudsz lenni. A letöltésnek az a része, amelyik kifelé megy, elenyésző méretű csomagokból áll. Ha elkezdel letölteni egy nagy állományt, akkor a kifelé menő irányban nincs torlódás, azon nincs mit szabályozni.

De ez természetesen csak a webes vagy ftp-s letöltésre igaz. Ha olyan hálózatot használsz, ahol a policy az, hogy neked is szolgáltatnod kell (köteles vagy te is megosztani, vagy a te géped is feeder lesz, mint pl. bittorent), akkor elvben lehet komoly kimenő forgalmat generálni. De minek veszel dobozt azon forgalom megregulázására, amit a bittorent kliensben egyébként is lehet korlátozni? Az mennyire életszerű feltételezés, hogy valaki profin voipol, letölt ezerrel és nincs ráhatása a gépekre?

Tehát ez a dobozka továbbra is a spanyolviasz kategória.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

A beszélgető partnernek se lesz jobb. A nagy állományok letöltése legrosszabb esetben is 9-10x annyi bejövő forgalmat generál, mint kimenőt. Tehát egy 768/256-os adsl-en csinál 768 bejövő és kb. 80 kbit/sec kimenő forgalmat. Ráadásul a kimenő csomagok rendszerint kicsik, csak tcp ack és hasonlók vannak benne. A 256-os sávszélesséből még marad 150-160 kilobit/sec üresen, a késleltetés se változik nagyon 80-100 byetos csomagok miatt. Egy majdnem üres dróton mit variál ez a doboz?

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

érteni vélem, de ha feltesszük, hogy a túloldalon minden rendben és az internet sem fogja meg a voip-csomagokat, akkor marad hibalehetőségként a saját lan, és ezen segít ez az eszköz. azt, hogy priorizálni a forrásnál célszerű, általános elvként írtam.

egyébként könnyen elbeszélhetünk egymás mellett, hiszen nem tudni pontosan, mi lakik a belsejében, egy egyszerű sávszélesség-menedzsment, vagy vmi komolyabb qos mechanizmus (azaz, hogy jelöli-e vmi módon a kimenő csomagokat, vagy csak magának állít fel egy fontossági sorrendet, illetve ha az előbbi, mi az esély rá, hogy a szolgáltató nem bírálja ezt felül csípőből)

miért ne tudnék hatással lenni a befelé jövő forgalomra? azt mondom például, hogy csak x sávszélességet kap, de csak akkor, ha nem gátolja a bármilyen irányú voip-forgalmat. ez esetben csökkentem a sávszélt, vagy ha van alkalmas eszközöm ideiglenesen várakoztatom a csomagjait, hiszen letöltésnél mindegy, mekkora a késleltetés/jitter

kishazankban a nagy sebessegu letoltes mell altalaban feltoltes is jar, es nem csak ack csomagok kepeben, mivel eleg nepszeruek a filemegoszto programok
szoval tobbnyire van ott kimeno forgalom, es ekkor igenis hasznos a qos
en cfosspeed-et hasznalok, elegge meg vagyok elegedve, nelkule nem igazan volt hasznalhato a net, ha beingitottam a dc-t

Úgy érted, hogy a 100 megás saját lan késleltetni fogja azt a forgalmat, ami bejött a néhány megabites adsl-en vagy csellón?

Tökéletesen igazad van abban, hogy priorizálni a forrásnál célszerű, ezt én még megtoldanám azzal a kitétellel, hogy akkor, ha szűkös, túlterhelt a sávszélesség. A letöltésnél a sávszélesség lehet szűkös, de annak a forrása a világvégén van, sőt, a letöltés és a voip forrása nem is feltétlenül egy helyen. Az első közös pont, ahol a két forgalom biztosan találkozik és reális esélye lenne a qos-nak vagy a korlátozásnak, az az ISP és az adsl carrier szolgáltató routerei közötti link (az ''adsl carrier szolgáltatás átadás-átvételi pontja''). Erre tudtommal nincs ráhatásod.

A kifelé menő forgalom forrását pedig el tudod kapni, mert az lakáson belül van, erre viszont a fenti példa alapján nem érvényes a szűkösség kitétel.

A szolgáltató szerintem nem foglalkozik azzal, hogy milyen kimenő forgalmad van, biztosan nem fogja csereberélni a csomagok sorrendjét, hanem ami felcsorgott tőled 256k-val, azt ő a sok tíz vagy száz vagy gigás gerincén villámgyorsan kitolja a világba.

Még mindig nem látom értelmét annak, hogy a kifelé menő irányon van ilyen egy csomag-nagy szünet-egy csomag-nagy szünet jellegű forgalom, azon mit kell macerálni drága dobozzal.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

Konkrétan senkinek nem lesz jobb, amíg nincs end-to-end diffserv támogatás a távoli szerver és a kliens között, vagy RSVP, ami méginkább nincs.
A csomag priorizálását az adatfolyam forrása képes megtenni, tehát az uplinket lehet befolyásolni. A letöltés helyén maximum a nagyforgalmú adatfolyam blokkolásával lehet sávszélességet felszabadítani (pl. delayed TCP acknowledge-ekkel lassítani a letöltést) de lényegében ez is az uplink forgalomba való beavatkozást jelent. Ha a szerver és a kliens végpont közötti downstream szolgáltatók (az összes!) nem támogatják az eltérő forgalmi osztályok szerinti csomagütemezést akkor a végén minden ugyanabba a traffic-classba fog tartozni, amit a szolgáltató szépen beönt ugyanabba a csőbe azt lesz ami lesz.

Mert a te bejövő forgalmadra csak az adsl modem után van hatásköröd. Annak meg sok értelme nincs, hogy bejön egy-két megabiten egy forgalom, amely drót konfigurálására nincs lehetőséget, majd utána kezdj el sávszélességet macerálni, amikor a két megabit átkerül a 100 megás helyi hálózatra.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

Tehát neked van egy szoftveres megoldásod a problémára, ami számodra jó. Vennél 15 ezer forintért egy dobozt, ami ugyanezt az eredményt produkálja?

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

igen, ez a tökéletes megfogalmazás

A befelé jövő forgalomra semmi hatásod nincs, csak az általad generált forgalmat tudod korlátozni és szabályozni. A befelé jövő forgalmat, ha már egyszer az ISP oldalán letorlódott, akkor a te eszközödben csak legfeljebb még jobban meg tudod nyomorgatni, pl azzal, hogy eldobálod a nagy nehezen beérkezett csomagokat vagy pedig nem küldesz acknoweldge-et a beérkezett csomagokra és a forrás majd valamikor később újraküldi. De ezzel nem nyersz plusz sávszélességet a ''fontos'' voip és egyéb forgalmad számára, mert azt a szűk keresztmetszet elején, vagyis az adsl/cable linked másik végén azaz az ISP oldalán az ISP-nek kéne külön forgalmi osztályok és prioritások szerint kezelnie. A mai ISP viszont ilyet nem csinál.

Ahhoz, hogy a doboz delayed ack-ot tudjon, értelmeznie kellene a teljes adatfolyamot. Ehhez ki kellene csomagolnia a ppp over ethernetet, azon belül az összes gép összes tcp kapcsolatát nyomon kellene követnie és minden tcp sessionra külön meg kellene ezt csinálni, majd az egyészet újra összerakni. Nem tudom fejből, hogy a ppp protokoll szükségképpen sorrendtartó protokoll-e, ennek utána kellene nézni, mert ha igen, akkor ez nem működik.

Ha leküzdöm a szkepticizmusomat, hogy egy kis dobozkában fillérekért mindezt megéri megcsinálni, akkor tudom mondani, hogy igazad van és érdemes ilyenbe beruházni. Egyéb esetben csak azt tudom mondani, hogy igazad van, spanyolviasz feltalálás esetét láttuk

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

Pontos. Apró korrekció, hogy a cselló mindezt, amit ideírtál, a saját voip szolgáltatása érdekében ténylegesen megcsinálja. Más kérdés, hogy abba a védett csatornába nem jutsz bele, amit magának csinált.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

most már kezdem magam kínosan érezni, mert nem akarom védelmembe venni ezt az eszközt, de nem sikerült felfognom azt sem, miért ne lenne abszolút semmi értelme. igaz, a bejövő forgalomra csak a modem után van hatásköröm. legegyszerűbb, ha szoftveresen, a pc-n megfogom, ha épp nem érdekem, hogy mind a 2 megabitet kitöltse. de teszem azt, hozzá nem értő felhasználó vagyok, vagy az öcsém bosszújának esem áldozatul, aki pofonmentesen lezárt szobájában bittorentezik etc. ilyenkor jó esetben átszabom a sávszélességét a routerben, de ha erre nincs mód, beteszek egy efféle eszközt. ha jól működik (nem tudom, ez konkrétan hogyan működik), és tudja, hogy nekem a voip-hoz mindkét irányban szükségem van x sávszélre, akkor időnként csomageldobálással megfoghatná a bejövő forgalmat is, így egy idő után (a windowing miatt) a szerver eleve lassabban öntené az adatokat. és ez az egész a 2 megabitről szól, utána a 100 megabites lanon már senkit nem érdekel, hogyan mennek az adatok, van helyük. nem?

Magyarul ez egy sima QoS adapter?

MCSE+M/S, MCITP, VCP5 - ''Soha ne becsüld le az autópályán száguldó DAT kazettákkal megrakott teherautó sávszélességét''

egen, ebbe akkor lehetne belemenni, ha tudnank, mi is van az eszkozben, es mire kepes

igen, az általam látott anyagok erről nem szólnak semmit

Egy ideális világban ugye elég lenne csak a DSCP mezőt kiolvasni az IP fejlécből, de ugye ez nem egy ideális világ...
Kicsit butább módon elég lehet, ha a tcp/udp portszámokból ''felismeri'' a high-priority forgalmat, minden más pedig best effort és lehet sanyargatni. Ez viszont erőforrás-igényes.
A PPP L2 protokoll és annyiban sorrendtartó, hogy soros vonalon nem szokás egymást előzgetni a csomagoknak. Viszont az IP szinten már lehet OOP ami nem lenne szabad, hogy gondot okozzon, mivel az IP connectionless protokoll. Persze, a felsőbb layereken ez már okozhat gondot, és tipikusan a voip ilyen, ami nem szereti, ha beelőzgetik egymást a csomagok. De lehet pl. selective discard-ot is csinálni a best-effort forgalomra, igaz, ezzel jól megszivatja csak magát az ember, viszont a szkájpin rezzenéstelen lesz a kép amíg a letöltés a háttérben 2x annyi ideig tart majd. Dehát valamit valamiért, ugye.

[Szerkesztve]

Arról szól ez a thread, hogy a befelé jövő forgalmat nem tudod szabályozni, nem csak ezzel az eszközzel hanem mással sem. Ez a dobozka a kifelé menő forgalmadat szabályozza. Itt a befelé jövő forgalom alatt nem azt kell érteni, hogy letöltés vagy webezés, hanem ip/ethernet csomagok szintjén a nyers forgalmat.

Ha elindítasz egy letöltést, az az egy darab letöltés, ami gyakorlatilag arról szól, hogy kintről, világvégéről bejön hozzád egy állomány, egyszerre generál bejövő és kimenő forgalmat is. Jön be az anyag, kisebb adagokra bontva, a te géped időnként szól a szervernek, hogy az eddigieket rendben megkapta, küldje a következőt. Ezen két forgalom aránya 1:10 vagy még rosszabb, vagyis egységnyi kimenő forgalomra legalább 10 egység bejövő forgalom jut.

Ha a szolgáltatód már beletolta abba az atm pvc-be a csomagot, ami neked szól, azzal te már semmit nem tudsz csinálni, mivel a szűk keresztmetszet a szolgáltatódtól az adsl modemedig terjedő drót. Ha már átjött az anyag a szűk keresztmetszeten, azt már kevéssé értelmes tovább babrálni.

Ha az öcséd kekeckedik veled és te hozzáférsz a routerhez, hogy rádugj egy ilyen dobozkát, akkor sokkal olcsóbb megoldás kihúzni a routerbe integrált switchből az öcséd ethernet drótját és hidd el, mindjárt megjavul a tárgyalási kézsége.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

Azt nem tudjuk, mi van az eszközben. Azt viszont pontosan tudjuk, az eszköz körül levő világban mi van és ez szerintem elég. Azt is lehet sejteni, hogy mit tudhat egy kis doboz ennyi pénzért.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

ne, fokent, hogy ezt a szoftveres megoldast megkaptam 3k-ert
de van, akinek ez nem megfelelo, mert mint janpotocki is irta, elofordulhat, hogy tobb gep van a ''haztartasban'' (irodaban, kinek mi), es ezesetben nem mukodik a szoftveres megoldas
mondjuk en ezesetben is inkabb osszedobnek egy p1-est routernek, ra meg valami kimondottan ilyen celra keszult os-t (pl a coyote linux nekem tetszett anno, mikor hasznaltam, es qos is van benne - legalabbis asszem a coyote volt az)

ok, ez mind világos, nyilván nem arra gondoltam, hogy a már dróton lévő adatok beömlését szabályoznám. de a csomageldobálás nagyon is hatékony megoldás lehet, mert (záros idő után) eleve kevesebb adat kerül a drótra. felemás, buhera megoldás, főleg a diffserv és társaihoz képest, de mentőöv lehet. abba egyáltalán nem szeretnék belemenni, hogy ez dollárban kifejezve mennyit érhet

szerk.: öcsém igazából nincs, így nem sokat

akkor sokkal olcsóbb megoldás kihúzni a routerbe integrált switchből az öcséd ethernet drótját

Igen, a L1 megoldásoknál nincs jobb

Két utat látok: precízen visszafejti, hogy a dugulást melyik tcp session okozta és azt az egyet fékezi meg ack delay-jel vagy agyatlanul minden tcp sessiont megfékez ezzel. Utóbbi esetben kockáztatja azt, hogy olyan sessiont is lefékez, amit egyébként nem kellene.

A ppp sorrendtartására vonatkozó kérdésemben azt akartam kérdezni, hogy a ppp a soros dróton nem változtatja meg a csomag sorrendjét. A kérdés az, hogy a protokollhoz tartozó állapottérben ezt ki is használják-e vagy sem. Ha azt alapértelmezem, hogy a csomagok sorrendje nem változhat, akkor csinálhatok olyan protokollt, amiben ellenőrzöm pl. sorszámmal a csomagokat és ha egy kimarad, akkor azt hibaként detektálom és megvárom az újraadást. Vagyis elvileg előfordulhat, hogy a ppp protokoll úgy van definiálva, hogy ha nem sorrendben érkeznek a csomagok, akkor az hibára utal és megpróbálja visszaállítani a sorrendet. Ebben az esetben ha a dobozka felcseréli a tcp ackok sorrendjét az ack-delay miatt, akkor felborulhat a gép-adsl modem kapcsolat. Ha nem cseréli fel, akkor meg maga a dobozka okozhat voipban késleltetést.

Lehet, hogy nem sikerült jól leírnom, amit mondani akkarok, sorry. Ehhez kellene pontosan ismerni a ppp-t.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

őszintén nem értem mi a bajotok a ketyerével.
van itthon 2 gép. nálam általában bentvan vmilyen filemegosztó progi (éppen emule, de sokat nem számít), bátyám szeret játszani (az egyébként híresen szar multiplayer-kódú mohaa-val).
ahhoz, hogy ő játszani tudjon, nekem irreálisan kicsire kell korlátoznom (a saját gépemen, software-esen) a feltöltésemet (egy pár k feltöltési sebesség felett már lagol az ő játéka), ugyanakkor nyilvánvaló, hogy ennél sokkal többet is meg lehetne reálisan oldani
pont erre való ez a kis szar. a mostani linksys routeremben is van qos, és nem kell semmi egetverő dolgora gondolni, semmi csomagelemzés,s tb, egyszerűen a küldő port alapján lehet beállítani a priorityket. igen valószínűnek tartom, h ez is pont uígy működik. az egy más kérdés, h a mostani routerem alap firmware-jével egyszerre csak egy portra leeht megadni a priorityt, összesen pedig 8ra, tehát egy ezres nagyságrendű porttartományt használó játéknál keveset segít a dolog, demajd átégetem a firmware-t, rem akkor már lehet porttartományokat definiálni
szóval sztem nem kell annyira fikázni a dolgot, soho/home eszköz, és arra nagyjából megfelelő

ezt a befele semmi beleszolasom nincs dolgot nem igazan ertem
nem ugy van (tanitottak valami ilyesmit), hogy ha nem kapja meg a kuldo az ack csomagot, akkor ujrakuldi ugyan, de ''lassabban'' (valami frame meret csokkentes remlik, de nem akarok hulyeseget mondani - be kellett volna jarni eloadasra)?
mert ha ez valoban igy van (es nem csak hulyesegeket beszelek), akkor megiscsak tudom szabalyozni a bejovo forgalmamat (megha kozvetve is, ugy, hogy a kuldo kimenojet szabalyzom...)

Az a sejtésem, hogy ezzel tönkretennéd a voip azon elvárását, hogy a csomagok késleltetése ne legyen nagy szórású és előre megjósolható legyen.

Ha eldobsz egy csomagot, az csak a tcp window size kitöltése után fogja megállítani a feladó gépet, aki várakozni fog a tcp ack-ra, de az nem jön meg, de addigra a teljes window size mennyiségű adatot beletolta már a hálózatba. Majd időzítés lejárása után újraküldi azt az egy csomagot, mire te ezt már elfogadod. A fogadó gép tcp szoftvere pedig az egész window size-t le fogja nyugtázni, mert addigra minden adat megjött, a feladó pedig megörül, hogy minden odaért, újabb adag window size méretű adatot tol a drótba. Ami szépen ki fogja sámfázni az adsl-t. Vagyis úgy fog kinézni a nagy letöltésed, hogy minden másodpercben kb. 1/3 másodpercre kisámfázod ezerrel a drótot, ekkor a voipod recsegni fog, majd egy darabig üres lesz. (300kbyte/sec letöltési sebességgel és 128k window mérettel saccolva).

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

Én úgy tudom, hogy ha elveszett egy csomag, akkor a timeout idejét növeli a feladó.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

...vagy pedig agyatlanul megfékez minden olyan tcp sessiont, ami nem high-priority, voip, streaming, stb.

PPP kapcsolat nélkülö protokoll, nincs semmiféle sorrend-vizsgálat. Tehát akár meg is előzhetik egymást a frame-ek, bár ez egy soros vonalon tipikusan nem jellemző. Ettől függetlenül nincs erre megkötés.

...és csökkenti a send-window size-t. Ha az ablakméret alacsony értéken marad a folyamatos retransmission miatt, akkor lényegében lecsökken a sávszélesség, mert windowsize=bandwidth*delay

ez logikus, sok hibánál viszont csökkenti az ablakméretet

szerk.: bocs, csiga997 megelőzött

Micsoda káromkodás folyik itt!

Eladó cuccaim: http://href.hu/x/h62i

Nem tudom te hogy vagy vele, de igenis lehet a letöltést korlátozni, amióta feltalálták a TCP protokollt.. Persze messze nem olyan fokú irányítással, mintha te töltenél fel, de lehet.

részletesebben?

Fortyogás ON
Annyira imádom az Informatikát.. 25 000 problémát felvet, ami Informatika nélkül nem lenne.. Pl ha végre kitalálnának valami QoS-t nyújtani képes Transport Layer-t, akkor nyilván ilyen eszközökre nem lenne szükség.. De ezt nagyon régóta képtelenek megtenni, úgyhogy elterjedt ez a Remek Ethernet.. Ami aztán sokmindenre innentől kezdve csak erőteljes megerőszakolás után alkalmans.. Ez az eszköz egy ékes példája.. ..
Fortyogás OFF

Amúgy szoftveresen 1 gép esetén Win alatt lehet valahogy csomagoptimalizálást csinálni?

Parker - Waterman - Rotring golyós és töltőtollak nagykerár alatt!! http://href.hu/x/7mi9

nekem úgy rémlik h a server verziókkal igen, de sok részletet nem tudok elárulni..

[Szerkesztve]

szamitogeppel sokkal gyorsabban tudjuk megoldani azokat a problemakat, amik szamitogep nelkul fel sem merultek volna

Bovebben: [link]

Kitalálták, használod is. A neve: ATM.

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html

Szép levezetés, de mi van azokkal, akiknek 1024/128 vagy 2048/192 vonaluk van?

Először szomjan halunk, azután éhen halunk, végül mind meghalunk!

Az hagyján, de mi van azokkal, akik pl E-Mule t használnak?? Ott ez az arány nagyon nincs így
Szegény csacsizók mindig megszívják.

Amúgy meg az ATM szép meg jó, de az is egy megerőszkolása a technológiának, amikor te ATM-be belecsomagolsz meg kicsomagolsz pl a TCP/IP szintig. Az sem egy triviális művelet drága kapcsolókkal..... Szóval még mindig elemi szinten vannak a gondok SzvSz...

Parker - Waterman - Rotring golyós és töltőtollak nagykerár alatt!! http://href.hu/x/7mi9

Sírjuk vissza az arcnetet meg a tokenringet

a PH! kedvenc ISP-trollja (C) Tyberius | http://itcafe.hu/tema/a_nagy_openwrt_topic/friss.html