Önszabályozást hoz az uTorrent újítása

Oldal 1 / 2Következő →

Jelentkezz be a hozzászóláshoz.

#71
sziasztok nekem lenne egy kerdesem vaiszatolt az utorrentem csak nagyon de nagyon lassanmit tegyek? kerlek segicsetek ja es amugy a netem nagyon jo eloreis koszonom bocsi akit zavartam
somdav95
#70
Elnézést a temérdek hozzászólásért, de most találtam. UPC-sek elleni petíció!!! Itt írható alá...

somdav95
#69
Hoppá, beállítottam a protokoltitkosítást "erõltetettre" és elkezdett szépen jönni lefele. De felfele még most se akar nagyon menni :/ Az 1.9-es verzió az milyen?? Valakinek tapasztalat?

somdav95
#68
Nekem is teljesen megállt a le-fel töltés UPC-s, 10mb-os le/ 2mb-os fel nettel... Egyszerûen max 40kb/s le, 15kb/s fel. Valami ötletetek nincs hogy mit lehetne vele csinálni?? Mert eddig tudtam letölteni 1mb/s-el meg többel is és felfele is ment 250kb/s-el vagy többel...

#67
Nézd..most tettem fel az 1.9-et. Gyors a le és feltöltés...de ha sok letöltésed van akkor párat megállít, ogy optimalizálja a sávszélességhez a letöltést..ha lejött a cumó akkor indítja a leállított torrentet. Szerintem érdemes kipróbálni..ja és mellette rendesen megy a net, nem lassulnak be a weboldal letöltések.

Szar játék az élet de qwa jó a grafikja!

Tsaba86
#66
Sziasztok. A kérdésem az lenne, hogy felraktam az új 1.9-est és akárhányszor elindítom létrehoz 2 fájlt az asztalon utp.log és socket.log névvel és egyfolytában írogat bele...Nagyon idegesítõ.
Hol tudom kikapcsolni,hogy ne hozza létre? Törlés nem segít, mert újra létrehozza...
Köszönöm élõre is!

#65
Most akkor mi legyen...? Váltsak, vagy ne váltsak 1.9 re?? :-O

Nekem pölö az elmúlt hét csütörtöke óta reggel 5-9 óra között a feltöltés lassul be a felére kb.
Valami ötlet, tapasztalat???
#64
#56-ban felvázolt esetre nincs vmi 72-es betûmérettel, vastagon leírható megoldásod?😛

#63
Vagy két hete dugult be errefelé is a upc-s torrentezés (megyeszékhely), de brutálisan.
Az upload 1 KB/s körül van peerenként. Van egy-két kivétel, de azok érdekes módon mind 1.9-es utorrentel nyomulnak.

¤¤¤¤o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤O3>

vajon kiki
#62
igenám, csakhogy minden netes stream packetekbõl, csomagokból tevõdik össze, semmi nem jön le egy 8 gigás packetként , ráadásul a lazy bitfields pont arrõl gondoskodik, hogy ne látszódjon folyamatos streamnek a brutálnagy adat letöltése, hanem mondjuk titkosított banki tranzakció packetjeinek látszódjon...

ezek után már kitárgyaltuk hogy itt csak bukó lehet , aki szembeszáll a torrentezõkkel

olyan szolgáltató pedig nem lesz aki bevállalja az összes titkosított adat globális, forsz szabotálását , lassítását, mert

ad1 lehúzhatja a rolót,
ad2 jön vagy 300ezer jogvédõ , hõzöngeni fognak - és joggal - hogy mire fel lassítanak szándékosan minden adat, jogellenes, alkotmányellenes stb... stb..

TomcatIVD TYAN board,2xP1 Tillamook 166MMX,48MB RAM,Matrox G550 32MB VGA, 4.3 IBM SCSI HDD,Hitachi SCSI DVDRW,SB16+Gravis Ultrasound,Realtek8019 LAN, Adaptec PCI2SCSI2 card,XP Pirate,bootup: 33s

#61
Eddig is ez volt a legjobb .torrent fájl letöltõ kliens, ezután már csak jobb lehet( ha jól kezeli a fent említett adatmozgást...)

Amd X2 5200+;2Gb DDR2 800;810Gb hdd;Ati X1650pro DDR3 Agp 😊
#60
Igen, csaképpen qrva nagy különbség van méretben egy pár KBytos titkosított adatlap és egy 8 Gigás duallayer között... <#zavart2><#rolleyes>
Aki az adatlapot tõlti annak nem gond, ha 2 mp helyett 5tel megy át..a 8 giga meg kicsit tovább tart akkor majd.. hihi

FX6300 4.5G " GTX1070 " DDR3 2000 CL9 " CTG 550W80P

vajon kiki
#59
egy nap , majd talán kitérnek rá, de túl azon, hogy akkor viszont minden titkosított stream kivétel nélkül lassú lesz, függetlenül attól hogy milyen program generálta (akár pl. online banki tranzakciók stb.) szóval túl azon addig is viszont kutya kötelességük a titkosított streameket a megállapodás értelmében a a minimálisan garantált sávszélben szolgáltatniuk, mert különben ejnye-bejnye, irgum-burgum és még talán dádá is lesz a következménye.

TomcatIVD TYAN board,2xP1 Tillamook 166MMX,48MB RAM,Matrox G550 32MB VGA, 4.3 IBM SCSI HDD,Hitachi SCSI DVDRW,SB16+Gravis Ultrasound,Realtek8019 LAN, Adaptec PCI2SCSI2 card,XP Pirate,bootup: 33s

#58
Akár rá is operálhatnánk 2 kereket...kisérletezõ kedvû német tudósoknak semmi sem lehetetlen <#eplus2><#eplus2><#eplus2>

Csak nehogy módosítsák a törvényt és kitérjen arra, hogy a szolgáltatók, korlátozhatják a titkos ADATFOLYAMOKAT LÓRI, mert akkor pipázgathatod a rubilkádat reggeltõl estig <#eplus2><#eplus2><#heureka>

FX6300 4.5G " GTX1070 " DDR3 2000 CL9 " CTG 550W80P

#57
Na várjatok valamit azért elflejtettek ám,vagy fél évig semmi korlátja nem volt az utorrentnek és mindenki vígan töltött, mégsem volt seholsem lassulás.
legalábbis a mi környékünkön a 8. kerületben.
Ebben a félévben pedig igencsak elterjedt volt már. Szóval szerintem ha bejön az új technika akkor se lesz semmi baj, úgy ahogy az elmúlt félévben sem...
#56
Marhaság amit terjesztenek itt páran, hogy titkosított csomagokkal, megfelelõen beállított peer-to-peer klienssel meg lehet kerülni a traffic shapinget. Nem tudom hogy az otthoni ISP-k egészen pontosan milyen koncepció szerint dolgoznak, de a gyakorlatban nem a packet tartalmát kell sniffelni...

Nyomon követhetõ, hogy kifelé adott IP címrõl hova mennek a csomagok. Mivel a legtöbb netes alkalmazás csak legfeljebb mondjuk 10 helyrõl fogad/helyre küld packetet (pl webportál ami átlinkel más lapokra, képeket más szervereken hostolja stb.), egyszerûen azt kell figyelni hogy a nem általános portokon (21, 80 stb.) kívül adott idõegység alatt az IP-rõl mennyi különbözõ hely között cserél gazdát a csomag. Ha ez meghalad egy elõre megadott értéket, a gép máris gyanússá válik és mehet a traffic shaping.

Titkosíthatsz akárhogy, azzal a tartalmat rejted csak el, a tényt nem hogy egyszerre mondjuk 40 peertõl fogadsz csomagot 5 sec alatt.

#55
Na közben elolvastam a kommenteket is, és az derült ki, hogy abban igaza van a pasinak, hogy akár ez is történhetne, ha nem tennének ellene az emlegetett önszabályozással. Legalábbis remélhetõleg jól fog mûködni a dolog.

#54
Hihi, miután elvolvastam, amit likeltél, és ránéztem a topik címére (ami éppen errõl szól), akkor jöttem rá, hogy ezt a cikket még nem is olvastam, csak az elõzõt. 😄

#53
Csak érdekesség:
Még a hét elején írt errõl a témáról a torrentfreak.com is. Abban a bejegyzésben is ugyanarról az emberrõl van szó, akirõl a HVG is írt.

http://torrentfreak.com/will-utorrent-really-kill-the-internet-081201/

https://twitter.com/foodlfg

#52
A user adatblokk-beli sorszámozás tiszta, de az nem oldja meg maguknak az adatcsomagoknak a késését, ami állandó szakadozásként jelentkezik a VOIP-es "vonalban".

Ha jól értelmezem, az UDP-s csomagok (amik ugye megkülönböztethetõk az egyéb TCP-s csomagoktól) eddig prioritást élveztek, és nem voltak (a user adatblokkba kukkantással) szûrve, mert nem volt túl nagy a forgalmuk. Viszont nem is lehet így szûrni, pontosabban ez a fajta belekukkantás törvényellenes. Marad a csomagok számának egyszerû korlátozása, ami viszont nem válogat.

#51
A csomagokat általában ellátják ún. sequence numberrel, ez alapján lehet megállapítani, hogy milyen sorrendben kell értelmezni õket. Ezért nem okoz gondot, ha egy csomag késik, illetve lehet tudni, ha kimarad. Ez tcp esetén automatikus, udp esetén azonban ISO/OSI layer 7-ben (alkalmazás szinten) szokás megvalósítani (ahogy pl a Skype is csinálja). Azért linkeltem az rfc-t, hogy lássátok, semmi köze az udp-nek a késlekedéshez, egész egyszerûen más szint.

"De azért furcsa (lenne), hogy egy állítólag neves (legalábbis szakértett pár netes szabvány létrejötténél) szakértõ így lejáratja/-ná magát."
Valóban, mégis így van. Bárki, aki írt már udp kezelést, egyet fog érteni velem. (Megjegyzem, az is furcsa, hogy a hvg lehoz ilyen cikket. Pénzszagot érzek mögötte. Hiába, k*rvul a méda <#szomoru1>)

#50
ehh, barbár

#49
Nos én nem vagyok hálózati szakértõ, de felmerül bennem pár gondolat, hasonlóan józan paraszti ésszel:

"Aki ilyent állít, az nem szakértõ. Ez úgy ahogy van, hülyeség. Ld. rfc."

Hát ebbõl neked spec nem derül ki, miért ne tenne be pl. a Skype-nak, ha 1-1 csomag mondjuk 10mp-ekkel késõbb érne célba.

"Ha nem tudnának mit kezdeni vele, akkor hogy lehetne már hálózaton belül védett?!?"

Ezt nem úgy értik esetleg, hogy egy kvóta fölött egyszerûen nem engednek be több csomagot a hálózatukba? (Ami eléggé "barmár" megoldás.)

#48
Hmm, az elõzõt még úgy írtam, hogy nem olvastam a te hsz-edet.
De azért furcsa (lenne), hogy egy állítólag neves (legalábbis szakértett pár netes szabvány létrejötténél) szakértõ így lejáratja/-ná magát.

#47
Hát nézd, az illetõ elõször is tényállításokat tett, és utána ezekbõl volt le logikusnak tûnõ következtetéseket.
A kedvedért:
- Az UPD kisebb adatcsomagok minnél gyorsabb célba juttatárása (volt) használatos.
- A legnagyobb csomagokat és forgalmat eddig itt a VOIP jelentette, pl. a Skype.
- Jelenleg nincs szûrve az UDP-s forgalom, mert az lassulást okoz, ami rontaná pl. a VOIP megoldások használhatóságát.
- A p2p rendszerek eddig csak egyeztetésre használták az UDP-t, ha (file-)adattovábbításra is használják, az az eddigi adatforgalom sokszorosát jelenti.

Akkor most ezeket adjuk össze. Lehetõségek: a. szûrés nélkül jól bedugul, VOIP használhatatlanná válik; b. szûrés lesz, ami a VOIP kapcsolatokat is lassítja, esetleg ebben az esetben is használhatatlanná válik. (Mivel a szûséshez elemezni kell az adatcsomagokat, ami idõ.)

Persze lehet, hogy van itt valami olyan plusz elem, amirõl a szakember nem tud, és ami által mégsem így lesz. Jöhetnek a tippek. 😊

#46
Én viszont hálózati szakértõ vagyok (vagy mifene), és azt mondom, hogy a hvg cikk egy nagy baromság. Tipikus pánikkeltés, tele dezinformációkkal. pl:

"Az ilyen típusú kommunikáció pedig nem tolerálja az adatok késlekedését"
Aki ilyent állít, az nem szakértõ. Ez úgy ahogy van, hülyeség. Ld.
rfc.

"Az internet jelenlegi struktúrája nem tud mit kezdeni az UDP-protokollon áramló adatok ugrásszerû növekedésével"
He? Mi ez a blama? Miért ne tudná?!? Mellesleg ha így lenne, akkor mi van ezzel a mondattal:
"Az internetszolgáltatók hálózataikon belül védve vannak az agresszív UDP-használattól"
Ha nem tudnának mit kezdeni vele, akkor hogy lehetne már hálózaton belül védett?!? Nem kell szakértõnek lenni, elég a józan paraszti ész, hogy belássuk: ez f@szság, úgy ahogy van.

pyrohun
#45
Azért nincs igazad, mert utorrent 1.8.x-et használva van korlátozás, majd UGYANABBAN A PERCBEN utorrent 1.9 beta-t indítva UGYANAZZAL A TORRENTTEL (tehát még egyszer: ugyanabban a percben, ugyanazazzal a torrenttel (tehát seeder szám, stb. minden egyezik)), NINCS korlátozás.

Akkor ha te olyan k*rva okos vagy, magyarázd már el ezt nekem, hogy ez hogyan lehetséges. TERMÉSZETESEN be van kapcsolva a titkosítás 1.8.x alatt is, még mielõtt ezzel jönnél...

LayerSlider, WeatherSlider, wpStickies - our famous plugins are available at CodeCanyon! More info @ http://kreaturamedia.com

#44
Nemhiszem el bazdmeg, hogy valaki ennyire retardált legyen. Leírták már páran, hogy http/ftp-n keresztül full sávszélességgel töltenek le, miközben torrenten nem.

Nightwish006
#43
Egyesek itt kibaszottul elvannak tévedve. Nem alkot itt semmit a csello, egyszerüen szar helyen laksz, levan terhelve a net, mint az állat.

Nézd meg, és regisztrálj! Nagyon jó oldal, nem átverés. Ha info kell pm me http://href.hu/x/7fiu

#42
Hát nemazér dez bátyó, de most egy embernek higgyek becsszóra (ott sem írnak túl sok konkrétumot), aki állítólag szakértõ.. oO?
Majd ha talán megkérdeznek többet is pl nagyobb cégektõl (cisco) és többen is ezt az elméletet fogják támogatni, miközben tényleg belassul a dolog, akkor majd elhiszem.
De kb azt mondja az arc a cikkben, hogy a utorrent készítõi direkt belassítják majd az egész internetet. Bizonyára ez a céljuk és nem az, hogy minél hatékonyabb fájlcserélést biztosítsanak a felhasználóknak. Mint valami összeesküvés elmélet.. ejha!

És mi történik ha tényleg rosszra fordulnak a dolgok, ki fog egyáltalán utorrentet használni ? Vajon ha látják a kialakuló negatív trendeket a utorrent fejlesztõi, akkor vajon mennyi idõbe telik majd nekik letiltani az új protokoll használatát ? Fél nap ?
Nem kell feleslegesen pánikot kelteni.

https://twitter.com/foodlfg

#41
Ha figyelmesen olvasol, nem a cikkíró találta ki ezeket, hanem egy ismert hálózati szakértõ mondja. Szóval ellenérveket, ha lehet. (De azt meg nem tudsz, mert nem vagy hálózati szakértõ... 😊 )

#40
Világvége hangulatú bulvárcikk (már a cím is az).
Nem vagyok hálózati szakértõ, de a cikk feltételezi, hogy az új protokoll tervezõi hülyék és azt sem tudják, hogy mit csinálnak.
Egyébként meg felesleges ezen malmozni, mert az új utorrent hamar el fog terjedni. Nemsokára meglátjuk, hogy eljön-e a WoW vége.
Én már elõre félek.
Mi lesz az éhezõ afrikaiakkal ?

https://twitter.com/foodlfg

Sanyix
#38
jaj, mingyá megsiratlak... és az ország 90%-ahol adsl van csak mitszóljon? Vagy pl bp egyes kerületei pl 3. ahol nagyrészt csak adsl meg trékábel van, ugyan az a fos sávszél mind2-n ugyanolyan kva drágán...

Vain ei kuulu terroristien käsiin! CS. N. T. K. K.! SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)

Sanyix
#37
már megint hülyeségeket írsz. Hasonlíts össze az adsl és a kábelnek technológiát, ne bullshitezzél...

Vain ei kuulu terroristien käsiin! CS. N. T. K. K.! SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)

Sanyix
#36
ez az udp-s dolog pont hogy jó... nincs ack így a letöltés nem generál feltöltést.

Vain ei kuulu terroristien käsiin! CS. N. T. K. K.! SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)

#35
Ebben azért nincs igazad (legalábbis nálam), mert ha utorrent-bõl csak 10-15-kvan jön a letöltés, ssh-val ugyanezt 2,4MB-al tudom szedni. Semmi baj nincs a hálózatukkal, egyszerûen szûrnek. (ajánlom a bix statisztikáját és egy traceroute-ot ilyenkor) És tényleg nem törik fel a kódolt csomagokat, mert nem lehet, máshogy csinálják, csak nem tom hogy.
#34
Sajnos el kell, hogy keserítselek titeket, UPC megoldotta a korlátozást. Legújabb 1.8-as kliensem van, force a titkosítás, még a bejövõ kapcsolatoknál sem engedélyezem a titkosítatlan kapcsolatokat, és random port minden indításnál. MAC-et megváltoztatom, tiszta új IP-m van, elindítom a utorrent-et, és 30-kval jön. Tiszta IP, tiszta port ,max enkódolással, és le vagyok korlátozva. Két hete vettem észre elõször, addig vígan jött 2,4MB-a mindig.

Nem a seederekkel van baj (amúgy aszfaltosról próbáltam), 100 megás szerveren ugyanez a torrent ugyanakkor jött 100mbit-el. Nekem meg 15k-val. Azt gyanítom, ez valami statisztikán alapuló szûrés lehet, mert ha 5 torrent-et elindítottam, és mindegyik kapcsolódott kb 20 seederhez, a 100 kapcsolatból volt 1-2, ami jött 2-300k-val, de a legtöbb peer csak 1-2kval. Szal nem 100%-os az új védelmük, de gyakorlatilag mûködik. Azóta megint ssh-val kell lehúznom a leszedett anyagot, ami nem lenne baj, csak hát ez plusz pénzbe kerül a havi díjon felül.

Amúgy szerintem azért nem találkozik mindenki ezzel a szûréssel, mert gondolom elõször a nagy csomópontokon vezetik be ezeket, ott éri meg, kurv@ drága hardverek ezek. Én Fehérvár belvárosában lakom amúgy.

Elõbb utóbb mindenki sorra kerül, még így is jobban megéri ezeket a cuccokat beszerezni, mint optikát bõvíteni.

Ez van sajnos 😞
#33
A garantált az igaz. (lásd ÁSZF)
De ahogy a upc mondta: "a garantált sebesség nem vonatkozik a p2p-re" Már hallom is a kérdést: "Akkor mire?" Hát jó kérdés.

Asus K53SC: Core i3 2,2Ghz, 6GB DDR3, 320GB HDD+ 500GB Sharkoon USB 3.0 Dock+ WD Elements 1,5TB, Intel HD 3000 & Geforce GT 520MX 1GB, Windows 10 Pro 64bit

vajon kiki
#32
hát igen.. túl ezen .. tulajdonképpen semmi de itt azon van a hangsúly hogy a t. kollegák váltig állítják, hogy a UPC (és kizárólag a UPC) valami új torrentszûrõ csodamódszert dolgozott ki , amely

1. feltöri a 128 bites titkosítást <#falbav><#falbav><#falbav>
2. majd beazonosítja a bittorrent fejlécet,
3. és ezután lekorlátozza az azt használó savszélességét ...

képtelenek a pici agyukkal felfogni, hogy senki nem tud ekkora kódokat feltörni,
és hogy azt sem értik meg hogy a UPC valós, fizikai háózata rogyik meg nap-mint-nap délután,
azért lehet nekik lassú a letõtés, bár én erre is rácáfolok, mert nekem ahogy mondtam máig , ebben a percben is 980 k-val jön a cucc uTorrenttel és UPC-vel (!!!) <#falbav><#falbav>

ha pedig ezek után is vitatkoznak és fõleg ASVA.INFO-s (!!) cikkekre hivatkozva akkor már tényleg csak egyetlen okuk lehet: elbátorolítani, a szerencsétlen jónépet a torrentezéstõl immár ilyen szar dumákat kitalálva, utolsó kétségbeesésükben.

TomcatIVD TYAN board,2xP1 Tillamook 166MMX,48MB RAM,Matrox G550 32MB VGA, 4.3 IBM SCSI HDD,Hitachi SCSI DVDRW,SB16+Gravis Ultrasound,Realtek8019 LAN, Adaptec PCI2SCSI2 card,XP Pirate,bootup: 33s

#31
És mégis milyen kár ért? Hogy nem 10 perc alatt jött le a legújabb 0day kecskepornó, hanem 1 óra alatt?

vajon kiki
#30
ha valaki, vagy bárki a UPC-nél a délutáni órákban lassulást tapasztalt, az kizárólag a hálózat FIZIKAI túlterheltségébõl adódó lehet, és nem szoftveres szûrés és egyéb rémhírek folyamánya, mivel lehetetlen a tudomány mai állása szerint a 128 bites titkosításokat feltörni, tehát semmilyen szinten nem lehet beletekinteni, hogy milyen program titkosította, milyen metódussal stb..

az egy dolog hogy a UPC többfelé értékseíti a hálózatát, mint ahányra valójában garantálni és BIZTOSÍTANI IS tudná bármely napszakban a minimálisan garantált sávszélt.

perelje be valaki ! vagy vajon kiki ! ha már a sokadik millió forint kártérítést fizeti a UPC akkor majd megjön a jobbik eszük ...

TomcatIVD TYAN board,2xP1 Tillamook 166MMX,48MB RAM,Matrox G550 32MB VGA, 4.3 IBM SCSI HDD,Hitachi SCSI DVDRW,SB16+Gravis Ultrasound,Realtek8019 LAN, Adaptec PCI2SCSI2 card,XP Pirate,bootup: 33s

vajon kiki
#29
ha pedig az öreganyámnak kereke lenne, akkor õ lenne a villamos..

koqsz:
sem a UPC sem más szolgáltató semmilyen szinten nem tudja a titkosított adatfolyamokat beazonosítani, ezért a titkosított torrentezést sem tudja se korlátozni, se beazonosítani sem semmit tenni vele, maximum nézegetni tudja, mint a boci. és ezt bármilyen szállítási protokollon egy laza csuklómozulattal bekapcsolhatod.

nekem konkrétan 10 megabites UPC csomagom van és folyamatosan , az utóbbi két hétben is, mindenféle híreszteléssel ellentétben átlag 980 kilobájt/szekkel töltöttem le bármely napszakban, csak azért mert betettem a pipát a titkosított adatátvitel rubrikába ( uTorrent 1.8.0-tól benne van)

TomcatIVD TYAN board,2xP1 Tillamook 166MMX,48MB RAM,Matrox G550 32MB VGA, 4.3 IBM SCSI HDD,Hitachi SCSI DVDRW,SB16+Gravis Ultrasound,Realtek8019 LAN, Adaptec PCI2SCSI2 card,XP Pirate,bootup: 33s

#28
Ez biztos? Mert néhányaknak(az elõzõ témában) ezeknél jóval lassabban ment a torrent.

Mellesleg nem hinném, hogy annyira "hülyék" lennének, hogy nem kapcsolják be a titkosítást.

https://twitter.com/foodlfg

#27
A UPC-nak sokkal fejlettebb a p2p szûrése mint ti azt álmaitokban is valaha elképzeltétek!

Ha UDP-n fog kommunikálni a torrent, azt lesz a legegyszerûbb megfogni! Köszönjük utorrent!!!! (a rendszergazdák nevében)

Amúgy meg hiába van 100/100-as neted, ha a szolgáltató a 10-ét se garantálja. Addig meg egy szava se lehet senkinek amíg a garantált sávszélt megkapja! Amúgy meg nem mindengy, hogy egy DVD 1.5 óra alatt jön le vagy 3 óra alatt?

Nightwish006
#26
Nem tudom miért kell szidni a UPC-t. Nem minden háztartásban elérhetõ a digi lannete... Persze, az a legjobb, ez tény. De ahol nem lehet digit köttetni, ott egyértelmüen a chello a nyerõ. Én tudom, 4évig ADSL eztem, és az a borzalmas, nem a chello. 8.5 ért kapom a 20/3-at, ált. megvan a max sebesség, torrentben is, csak bekell kapcsolni a kényszerített titkosítást. Persze a hülyéknek könnyebb károgni meg fikázni, mint gondolkodni... Jahésdiginetetmindenháztartásba!!!!444

Nézd meg, és regisztrálj! Nagyon jó oldal, nem átverés. Ha info kell pm me http://href.hu/x/7fiu

#25
koliban nekem olyan szinten van korlátozva a netem, hogy 2 oldalt nem tudok egyszerre frissíteni. shtml, ftp, smtp, torrent letiltva. de szerintem az UDP portok is, mert MSN-el és Skype-al sem lehet videó vagy hanghívást indítani.

mindezt azért, mert tavaj egy idióta seggfej nem bírta bekapcsolni a torrent kliensében az automatikus sebességlimitet és lefoglalta az egész hálózatot, emiatt pedig a rendszergazda volt zaklatva azzal, hogy senki másnak nem megy a net.

#24
szép napot <#wave>
Ha a világ vagyona, nem alig pár %-ember kezében lenne, hanem normálisan eloszlana, és a neten lehetne könnyedén vásárolgatni, 100ad ennyi torrentezés nem lenne.
Süt a nap, yeah <#vigyor2>

FX6300 4.5G " GTX1070 " DDR3 2000 CL9 " CTG 550W80P

#23
Amúgy 29.-én változott a upc-nél a garantált sebesség. Most minden csomagnál a fele a garantált. Azaz 10mbitnél 5mbit, 20mbitnél 10mbit
Ja és a upc ügyfélszolgálata elmondta, hogy jelenleg hálózat fejlesztés van, mert alig bírják tartani a mostani sebességet. Egy másik fórumban egy másik embernek is ezt mondták. 😊

Asus K53SC: Core i3 2,2Ghz, 6GB DDR3, 320GB HDD+ 500GB Sharkoon USB 3.0 Dock+ WD Elements 1,5TB, Intel HD 3000 & Geforce GT 520MX 1GB, Windows 10 Pro 64bit

#22
Tsaba86: Az nem a protokolltól függ! Éppen az a baj, hogy router mögött vagy. De attól még nem kellene feltétlen passzívnak is lenned. Egyszerû: beállítod a routert portforwarding-ra és azt a portot adod meg.

Mellesleg van egy sejtésem, hogy csak annál nem nyer a UPC korlát ellen a titkosítás, aki közvetlenül - router nélkül csatlakozik a netre. De ezt valaki megcáfolhatná, vagy utánajárhatna. Nem tudom, hogy mûködik egy router, hogy újracímezi e a csomagokat, vagy ilyesmi?

Oldal 1 / 2Következő →