Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 68 reacties
Submitter: Neglacio

Bittorrents nieuwe p2p-protocol utp, dat niet op tcp maar op udp is gebaseerd, zou problemen voor voip-gebruikers en gamers opleveren. Volgens de makers komt de kritiek echter uit de koker van tegenstanders van netwerkneutraliteit.

utorrent logoDe ontwikkelaars van µTorrent, de populaire p2p-client van Bittorrent, hebben in alphaversie 1.9 voor de eerste maal het utp-protocol geïmplementeerd. Utp maakt gebruik van udp, een van de basisprotocollen van het internet. Udp is mede dankzij een lagere overhead weliswaar efficiënter dan tcp, maar kent ook een groot nadeel: er kunnen ongemerkt gegevens verloren gaan. Toch is een bittorrent-implementatie op basis van dit protocol volgens de makers efficiënter en sneller dan het huidige bittorrent-protocol, dat tcp gebruikt. Bovendien zijn volgens de ontwikkelaars de congestion controls van tcp onvoldoende, omdat het protocol alleen vertragingen signaleert wanneer er pakketten verloren gaan. Verder is tcp de basis voor het leeuwendeel van het internetverkeer, zodat optimalisaties uiterst traag doorgevoerd worden, stelt Simon Morris van Bittorrent. Een belangrijk nadeel van udp, het ontbreken van een foutcorrectiemechanisme, zou verder geen invloed hebben op p2p-verkeer, omdat het bittorrent-protocol ingebouwde foutcorrectie op basis van crc's heeft.

Netwerkdeskundige Richard Bennett stelt echter dat de komst van p2p-protocollen als utp het functioneren van het internet in gevaar kunnen brengen. P2p-applicaties zijn momenteel verantwoordelijk voor ruwweg de helft van het internetverkeer. Bennett redeneert dat een massale overstap naar udp voor grote problemen zal leiden, omdat netwerkbeheerders en isp's gedwongen zouden worden om ook dit protocol via netwerkmanagement aan banden te leggen. Met name gamers en voip-gebruikers die via udp communiceren zouden hierdoor worden getroffen, omdat isp's en internetexchanges udp-verkeer 'noodgedwongen' zouden afknijpen. Bennett stelt dat tcp het aangewezen protocol is voor het transport van grote hoeveelheden data, omdat dit verkeer beter te beheren is; udp zou alleen voor kleinere datastromen gebruikt mogen worden. Met een grootschalige invoering van utp zou Bittorrent zich niet alleen schuldig maken aan het schenden van deze fatsoensnorm, maar ook toepassingen als voip en online gaming benadelen.

Uitgaande p2p-verbindingen in torrentclientBittorrent stelt in reactie op de beschuldigingen van Bennett dat zijn utp-protocol juist voor alle partijen winst op zal leveren. De eindgebruiker zou dankzij de lagere latency van het utp-protocol in µTorrent minder last hebben van bijvoorbeeld een trage browser, en isp's zouden juist minder verkeer te verwerken krijgen. Verder wijst Bittorrent er op dat utp alleen gebruikt wordt voor communicatie tussen peers, terwijl de bulkdata nog steeds via tcp verstuurd wordt. Tegenover Torrentfreak stelt µTorrent-community manager 'Firon' verder dat Bennett zijn bezwaren nooit aan Bittorrent heeft voorgelegd. Bennett zou nu met een sensatieverhaal de publiciteit zoeken omdat hij een tegenstander van volledige netwerkneutraliteit is.

Het bezwaar dat het utp-protocol momenteel nog niet opensource is en daarom niet in andere bittorrentclients kan worden gebruikt, lijkt een tijdelijk probleem. Bittorrent heeft aangekondigd dat het de utp-code na de testfase openbaar zal maken. Het bedrijf heeft ook al zitting genomen in een Ietf-werkgroep, in de hoop dat utp uiteindelijk uitgroeit tot een volwaardig en breed ondersteund p2p-protocol.

Gerelateerde content

Alle gerelateerde content (30)
Moderatie-faq Wijzig weergave

Reacties (68)

UDP is een primitief protocol, en wordt gezien als tegenhanger van TCP.

UDP
* pakket wordt gestuurd op aanvraag, er wordt niet gewacht op een feedback (die is er niet)
- snel
- geen fout correctie (data kan verkeert aankomen->fout bestand)

UDP TCP
* pakket wordt gestuurd op aanvraag, er wordt gewacht op een feedback en indien nodig wordt het pakket opnieuw verstuurd
- traag/overhead
- wel fout correctie->pakketjes worden opnieuw aangevraagd totdat de ontvanger denkt dat het foutloos is getransporteerd (controlebits)

Voor torrent is UDP veel efficienter, want je kunt van verschillende peers hetzelfde pakketje vragen, dus je hoeft niet dezelde peer te belasten met een fout pakketje, als je het wel van een andere peer misschien wel meteen een goed pakketje kan krijgen.
Een pakketje kan foutjes oplopen door slechte kabels, malfunctioneren van router, of opzettelijk: het vergiftigen van een tracker. Als downloader krijg je dan veel poisened packets binnen. Gelukkig kan je bittorent client die er meteen uitfilteren, maar ondertussen wordt het netwek onnodig belast, en wordt het downloaden aanzienlijk vertraagd

Vergeet niet dat je in je router dan ook poorten moet openzetten voor UDP, of nog beter in combinatie: UDP/TCP

De implementatie van Bit torrent die gebruikt maak van UDP heet UTP (ik gok dat het een afkorting is van µ Torrent Protocol)

BTW een protocol kan niet opensource zijn, maar wel open.
Een implementatie van een protocol kan wel opensource zijn.

ook heb ik gehoord dat men torrents trackerless wil maken, ik juich de ontwikkelingen alleen maar toe, en so be it voor de auteurs-rechten-beschermende verenegingen.
Uiteraard kan men UDP heel makkelijk afknijpen, maar dan pest men wel meer dan alleen de downloader, die nog kunnen terugschakelen naar TCP.

Inderdaad, erg verwarrend...

[Reactie gewijzigd door g4wx3 op 2 december 2008 15:50]

Goede post, alleen 1 klein dingetje wat het minder goed leesbaar maakt: je hebt 2x UDP geschreven bij de UDP<->TCP vergelijking. Voor een sysadmin geek als ik is het goed leesbaar, die haalt het er automatisch uit, maar iemand die er niet zo veel van snapt, snapt er nu nog minder van :+

En nog 1 dingetje wat niet perse klopt: voor torrent hoef je niet perse poorten open te zetten. Torrent maakt zowel verbindingen naar buiten als dat het inkomende verbindingen toestaat. Zonder poorten open te zetten krijg je alleen verbindingen naar buiten, wat over het algemeen geen probleem is. De meeste torrent clients hebben een max aan het aantal verbindingen die ze opzetten, bv 100. Als je zelf die 100 verbindingen op zet maakt het niet uit of je inkomende verbinden accepteert, want je zit toch al aan de max. Het enige waar het mee kan helpen is voor de niet zo populaire torrents met weinig seeds, waarbij het voor extra verbindingen kan zorgen als anderen ook naar jou kunnen connecten. 2 clients achter een gesloten firewall/router kunnen namelijk nooit verbinding met elkaar maken.

[Reactie gewijzigd door kozue op 2 december 2008 13:17]

Je noemt in je vergelijking 2x UDP terwijl dat denk ik 1x tcp moet zijn...

Verder is het zo dat de applicatie met UDP zelf meer controleheeft over de foutcontrole en transport opties heeft, dit moet je als programmeur zelf regelen. Daardoor kan een protocol beter op maat gemaakt worden voor de applicatie.

[Reactie gewijzigd door E_E_F op 2 december 2008 15:15]

volgensmij gaat torrent en gamen sowieso lastig; slurpt je gehele netwerk dicht met die 100000 verschillende verbindingen.
Of wordt daar ook verschil tussen gemaakt met utp en tcp?
Daar zit hem juist de kneep: Met UDP gaat het aanleggen van 100.000 'verbindingen' juist veel sneller en makkelijker. De grootste vertraging die je krijgt zit in de overhead van TCP, omdat de client elke verbinding opnieuw op moet bouwen. Met UDP stuur je je packet gewoon weg (maar heb je geen garantie dat het aankomt). Vergelijk het met iemand opbellen of een SMS sturen, wat is sneller...

Ik denk juist dat het draaien van andere applicaties (gamen, ssh, whatever) juist een stuk vlotter gaat als dit UTP protocol een beetje doorzet. Zolang het maar niet uitvoerig gaat lopen broadcasten....
het probleem is als jij een multiplayer game speeld wil jij geen pakketjes verliezen want dan krijg je "Lagg" oftwel word het meschien onspeelbaar dacht ik zo,
utp is meschien wel leuk voor bittorrent bestanden kan je natuurlijk altijd weer repareren mits de gene par bestanden mee laat downloaden,
Bij het gamen wil je langs de ene kant geen pakketjes verloren laten gaan, langs de andere kant wil je ook niet meer opgezadeld worden met te late pakketjes.

Als er een pakket A na pakket B toekomt heeft pakket A al geen betekenis meer.
in dat opzicht heeft UDP weer de voorkeur.
het heeft ook geen zin dat er pas iets gebeurd nadat er bevestiging van het verzonden pakket gekomen is. dus weer een pro voor UDP.

Verder heb ik de indruk dat het protocol niet UTP maar uTP en eigenlijk maar µTP van micro transport protocol. maar omdat het µ symbool niet op mijn querty klavier staan heb, en soms eens voor problemen kan zorgen op het web, veronderstel ik dat ze liever u dan µ gebruiken.
What is in 1.9:
uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits.

[Reactie gewijzigd door bigbadbull op 2 december 2008 13:27]

Usenet gebruiker zo te horen? Die 'par' bestanden heb je niks mee te maken in bittorrent, daar wordt een ip pakketje dat niet goed aan komt gewoon opnieuw gestuurd, in plaats van de inefficiënte par oplossing waarbij je grote hoeveelheden extra data download voor het geval er misschien een bitje om is gevallen.
Bovendien zit er geen verband tussen het verliezen van pakketten en het protocol. Je verliest in TCP/IP ook pakketten, alleen worden die door je TCP stack opnieuw verzonden zonder dat je daar als applicatie iets van merkt. Verloren pakketten komen door netwerk issues, zoals bv de kwaliteit van de verbinding (wireless is daar berucht om), de afstand (lange afstanden zorgen voor storing op de lijn), router queues (routers gooien pakketten weg die ze niet kunnen verwerken), verkeerde routing, etc etc.
In TCP en UDP verlies je allebei net zo veel pakketten, alleen wordt het in UDP door het protocol afgehandelt en in TCP door je netwerk stack, wat dus tot gevolg heeft dat je meer overhead krijgt in je protocol implementatie als het protocol over UDP loopt, maar dat je flexibiliteit krijgt in hoe je om gaat met verloren pakketten. Voor file transfer wil je ieder pakket in goede staat binnen krijgen, voor gamen of VOIP is het vaak beter om het pakket gewoon weg te gooien, aangezien het realtime applicaties zijn en je dus vaak geen tijd hebt om lang te wachten op hertransmissie.
Usenet gebruiker zo te horen? Die 'par' bestanden heb je niks mee te maken in bittorrent, daar wordt een ip pakketje dat niet goed aan komt gewoon opnieuw gestuurd, in plaats van de inefficiënte par oplossing waarbij je grote hoeveelheden extra data download voor het geval er misschien een bitje om is gevallen.
Blijkbaar heb jij ook geen kaas gegeten van PAR2. niet zo haten op andere oplossingen als je zelf er weinig vanaf weet. een beetje newsreader download alleen par blocks wanneer en hoeveel die nodig zijn (mits goed geconfigureerd). dat zullen nooit grote hoeveelheden zijn, tenzij je ontzettend veel fouten hebt. Het is gewoon 1op1 per fout block. Dat vind ik niet inefficiënt. Torrents zijn inefficient in mijn mening gezien je ontzettend veel data genereerd voor het downloaden van je files.
voor allebei valt wat te zeggen:
valt er bij usenet een bitje om dan blijf je hetzelfde bestand gewoon downloaden en heb je aan het eind een par file nodig, indien goed gedaan dan is de overhead van de blocks minimaal
valt er bij torrents een bitje om dan wordt het blok gedropt en dat ene blokje opnieuw gedownload, ook hier is de overhead vrij klein.

Het grote nadeel in torrents zit in het feit dat er ontiegelijk veel verbindingen nodig zijn om een bestand te downloaden (enkele honderden voor een groot bestand) tegenover zeer weinig voor usenet (afhankelijk van je server kan je met 8 verbindingen 20mbit halen)
Het grote nadeel in usenet zit erin dat je centrale servers nodig hebt die ziekelijke opslagcapaciteit moeten hebben en een ziekelijke dikke verbinding op je server wil je veel mensen kunnen serven waar bij torrent juist alles decentraal is en zodra het bestand redelijk verspreid is geraakt over de clients de initiele seeder onbelangrijk wordt en het (indien er eeuwig mensen zouden blijven downloaden) vrij goedkoop eeuwig gehost kan worden

Uiteindelijk is de overhead op het hele netwerk van torrents waarschijnlijk groter dan bij usenet door de vele verbindingen, maar is het ecomisch handiger voor bedrijven/open source initiatieven om grote bestanden relatief snel te verspreiden
De grootste vertraging die je krijgt zit in de overhead van TCP, omdat de client elke verbinding opnieuw op moet bouwen
En dat niet alleen, het feit dat er een verbinding is betekent dat er een state bijgehouden moet worden, waardoor het veel meer systeem resources verbruikt dan een stateless UDP verbinding.
TCP heeft verbindingen, UDP niet. BitTorrent maaktte nogal wat TCP verbindingen, en bspaart daarom relatief meer met het schrappen ervan. De voordelen die zo'n verbinding biedt (zoals in-order delivery en automatic retransmission) zijn voor BitTorrent overbodig.
Dat gaat nu misschien juist beter.
100.000 is onzin.. De gemiddelde client heeft standaard vaak een maximum van een paar honderd verbindingen in totaal, en bijvoorbeeld 100 per torrent.
100 per torrent... En de volgende persoon heeft ook 100 per torrent, en de volgende persoon... 100² ... En vaak staan de torrent clients ingesteld op 200+ mogelijk connecties op hetzelfde moment.

Het principe is dat deze nieuwe techniek de footprint van al deze connecties dusdanig vermindert, wat een grotere efficiëntie oplevert.
Als jij een degelijk routertje ertussen hangt (openbsd pf) kan jij en je torrents op unlimited zetten en lekker gamen/surfen/youtube kijken zonder problemen, je kan namelijk bepaalde verkeersstromen voorrang geven
In het artikel gebruikt met UTP en UDP nogal door elkaar. Kan iemand me het verschil uitleggen?

Ik dacht dat namelijk UTP een van de Media was waarover UDP (en andere protocol)stromen gestuurd kunnen worden. Uit het artikel lijkt het als UTP een protocol naast UDP is.
UDP (User Datagram Protocol) is een netwerk/internet protocol. UTP was altijd al een soort kabel (Unshielded Twisted Pair) en nu blijkbaar ook de naam van het nieuwe op UDP gebaseerde protocol van bittorrent. (zal wel iets van udp torrent protocol zijn ofzo?)

[Reactie gewijzigd door martijnve op 2 december 2008 12:01]

Lees het anders als µTP: micro transport protocol. Zo wordt het immers bedoeld. Het probleem is dat niet op alle toetsenborden makkelijk de µ te vinden is (Ctrl + Alt + m overigens) en µTorrent (micro-torrent) vandaag de dag als uTorrent bekend staat.
Het is dan beter als uTP te schrijven. :)
Op US International layout is Alt + m voldoende, als men teminste de rechter Alt (Alt Gr) gebruikt.
Op een Azerty toetsenbord layout staat de µ zelfs gewoon als volwaardige toets. (2 toetsen rechts van de 'm'). Op dezelde toets staat overigens ook de < £ > en de < ` >.
Ik moet echter eerlijk toegeven dat ik eerder geneigd ben om uTorrent te schrijven dan de µ te gebruiken.
FTP betekende ook al zowel File Transfer Protocol als Foiled Twisted Pair, dus de link tussen kabels en protocollen wordt alleen maar versterkt ;)
Wat soms voor verwarring kan leveren. ;-)
Ik heb een hekel aan m'n kabels in de war :(
hmmm twisted en in de war ..... untwisted en door de war.... toch afdoende shielding ;)))
In het artikel gebruikt met UTP en UDP nogal door elkaar. Kan iemand me het verschil uitleggen?
Ik gok dat UTP in dit geval voor UDP Torrent Protocol staat. UDP/IP is het standaard protocol.
uTorrent Transfer Protocol, kijk maar op Torrentfreak ;)

De u is een micro teken maar geen flauw idee hoe die te typen op mijn tobo..
en belangrijk nadeel van udp, het ontbreken van een foutcorrectiemechanisme, zou verder geen invloed hebben op p2p-verkeer, omdat het bittorrent-protocol ingebouwde foutcorrectie op basis van crc's heeft.
Dit is niet geheel waar. Torrent gebruikt hashes over blokken van bv. 512kb of 1 mb. Een UDP pakketje is niet groter dan 1500 bytes. Dus als er 1 UDP pakketje verloren gaat komt de torrent check daar vanzelf achter en gaat de GEHELE 512kb of 1mb opnieuw downloaden. Mocht je dus een UDP packet loss rate van een paar procent hebben komt je torrent bijna nooit geheel over.
Een UDP-pakket kan tot 65507 bytes aan data bevatten (met daarvoor een header).

Met je 1500 bytes bedoel je de maximale "payload" van een (normaal) ethernet-pakket, vermoed ik.
Ik heb de specificatie van UTP niet gezien, maar ik neem aan dat de makers van dit protocol hier wel rekening mee hebben gehouden. :+
Ja, dat heet TCP :P
Ik was ook even in verwarring: hebben ze UTP met UDP verwisseld, maar het is toch echt uTP, maar dan wel met kleine u, zie dit bericht:


uTP is a UDP based communications protocol that helps BitTorrent clients detect network congestion by reacting to latency.
Het probleem hiermee is dat UDP juist vanwege het connectionless karakter moeilijk in te dammen is en dus ook voor een flood kan zorgen. Stel je hebt torrents gehad die over UDP zijn binnengehaald, je zet de client uit, soms kan dan nog een uur tot zelfs 24 uur later nog een stroom UDP-verkeer binnenkomen. Waar die bitjes zitten kunnen geen nuttige bitjes zitten en kan je bijvoorbeeld niet bellen via je Voip-lijn.

Dat is allemaal te ondervangen, maar zal dan wel weer nieuwe apparatuur vergen, terwijl het tot op heden gewoon goed gewerkt heeft. Gezien de populariteit van Bittorrent vind ik de opmerkingen van meneer Bennet, zij het wat cru, wel hout snijden.
Dit zou je dus in het protocol (dat hier utp genoemd wordt) kunnen regelen. Zoiets dat je toch 1x per (minuut) een pakketje terug verwacht en anders niet meer stuurt tot er een nieuwe aanvraag is geweest.
Ik wordt uren nadat ik eMule gestopt heb ook nog bestookt door pakketjes van Mediasentry (die allemaal geblockt worden door Peerguardian).
Maakt inderdaad niet uit wat ze voor torrent gaan gebruiken

Als je flinke zware game wil runnen zonder legg dan heb je ook met tcp/ip al problemen met je torrent draaid er naast.

En als je problemen hebt kan je altijd zoeken naar een bandbreedte manage programma om dit allemaal netjes naast elkaar te draaien
Op het moment maakt het wel degelijk uit wat voor torrent protocol ze gebruiken. Zolang het protocol nog niet open is, blijft het proprietary rommel waar het internet niet beter van wordt. Het gesloten zijn is eigenlijk de grootste issue hier, niet het gezeur van ISP's die het af willen knijpen en het niet meer kunnen als ze op UDP over stappen. Terwijl de wereld langzaam aan limiterende gesloten formaten zoals .doc er uit aan het werken is, komen zij vrolijk met nieuwe gesloten rommel. Dan kunnen ze best beloven om over een tijdje met specs te komen, maar hoe groot is die tijd dan? Ik zie nergens een deadline. "Na de testfase" kan van alles betekenen. Volgens mij was Gmail ook officieel nog beta, en daarmee in testfase...
Zolang de specs er nog niet zijn blijft dit voor mij een sneue poging om meer gebruikers naar hun closed source windows-only progje te trekken. Ik hou het lekker op het originele protocol, die werkt ook prima!

offtopic:
Overigens moet ik toch echt even iets anders kwijt. Iemand hierboven was de draad al kwijt door "lag" met 2 g's te spellen, maar jij maakt het wel heel erg bont...
[quote]game wil runnen zonder legg[/quote]
Zonder benen (leg) kun je inderdaad niet goed hardlopen (runnen)!

[Reactie gewijzigd door kozue op 2 december 2008 13:07]

Ze willen het open sourcen. Ik kan me best voorstellen dat ze het in de ontwikkelingsfase closed houden, om te voorkomen dat er straks allerlei halfgare implementaties rondzwerven die de interconnectiviteit om zeep helpen. Ik ben zelf een sterk voorstander van open source maar als ze het pas open maken zodra het protocol niet (snel) meer veranderd heb ik daar wel begrip voor.
En dat is dus precies wat MS heeft gedaan: de specs van hun oude office formaten pas openbaar maken toen ze toch niet meer gingen veranderen. Dat was namelijk op het moment dat ze er zelf van af wilden en ze iedereen aan de ooxml wilden hebben. Oftewel ongeveer 10 jaar te laat. Heb je er nu nog steeds begrip voor?
Zoals ik in mijn post al aan gaf: wanneer "verandert het niet meer"? Over een maand? Over een jaar? 10 jaar? Tot aan de dag dat ze het hun protocol specs komen mogen ze van mij opzouten met hun MS-tactieken. Ze krijgen mij echt niet aan de utorrent op zo'n manier.
Dat over die "halfgare implementaties" is ook onzin. Hoeveel halfgare implementaties heb je op het moment van het standaard torrent protocol? Ik denk niet dat jij er een op kan noemen. Zie je zelf ook niet in dat als er een client tussen zit die niet lekker werkt, dat dat een probleem is voor die ene client, en dat de rest daar niks mee te maken heeft?
En verwar 'open source' trouwens niet met 'open standaard'. Source gaat over code, oftewel de implementatie in 1 specifiek stuk software. Wat we nodig hebben is niet zo zeer open code, maar de volledige specificatie, zodat andere clients code kunnen schrijven die aan de specificatie voldoet. Open source code is daarbij handig, omdat het direct over te nemen is, als de licentie dit toe laat, maar is geen vereiste.

[Reactie gewijzigd door kozue op 2 december 2008 17:55]

Het gaat niet om het tegelijk draaien, het gaat om het afknijpen van een protocol omdat daar bittorrent verkeer overheen gaat. Als bittorrent dan wisselt van het protocol wat normaal voor websites gebruikt wordt naar het protocol dat gebruikt wordt voor games en voip, betekend dat dus dat ze games en voip zullen afknijpen.
En daar is meneer Bennelt boos over, terwijl je eigenlijk boos zou moeten zijn op de Isp's (lijkt mij dan).
Dus als ik het goed begrijp vind ie dus dat UDP afgeknepen moet gaan worden zodra bittorrent overstapt?

Wat is daar de logica achter?
De logica erachter is, is dat TCP op het moment bij sommige providers al geknepen wordt voor bit torrent, aangezien het grootste deel van het internet verkeer door torrent gegenereerd wordt tegenwoordig, en providers eigenlijk helemaal niet willen dat jij al je bandbreedte gebruikt (o.a. door overbooking).
Nee dat vind hij niet, goed lezen. Hij denkt dat de isp's de torrents af willen blijven knijpen.
Nu kan dat niet volledig omdat er ook normaal html etc. verkeer over de TCP gaat, maar als ze overschakelen op UDP (wat voor "onbelangrijke" dingen als voip en games word gebruikt (volgens de isp's dan he)) gaan ze dat natuurlijk meteen helemaal afknijpen. Waardoor voip gebruikers en gamers dus de lul zijn.

Imo. moeten isp's eens hun kop houden met afknijpen, stiekeme data-limieten (fair use bs dus) etc. en gewoon eens leveren waar men voor betaalt, het is toch te gek voor woorden dat je ergens voor betaalt en dan wanneer je het volledig gebruikt (je volle recht) je dan afgeknepen word?:S 8)7 :(
Het TCP protocol heeft congestion control, dat zorgt ervoor dat als er een hoop pakketjes niet of laat aankomen aan de overkant er op een lagere snelheid verstuurd wordt. UDP heeft dit niet en een programma dat UDP gebruikt zal dus op maximale snelheid pakketjes blijven versturen (tenzij het programma hier zelf rekening mee houdt) waardoor er nog meer verstopping optreed en alles nog langzamer wordt enz.

Als programma's die UDP gebruiken altijd maar pakketjes blijven sturen terwijl TCP netjes minder pakketjes stuurt zal UDP een steeds groter deel van de capaciteit gebruiken. Omdat de meeste programma's op TCP werken zal het internet voor een hoop mensen langzamer worden, om dit te verkomen kunnen providers UDP verkeer maar een beperkt deel van de capaciteit geven.

Omdat spellen en voip ook gebruik maken van UDP en omdat bittorrent nog steeds een hoop pakketjes verstuurt zullen steeds minder van de spel en voip pakketjes (op tijd) aankomen.
In Azureus/Vuze zit dit toch al een tijdje in gebakken? Bij voorkeuren kan je namelijk aankruisen: UTP verbindigen prefereren. werkt top :)
Het bezwaar dat het utp-protocol momenteel nog niet opensource is en daarom niet in andere bittorrentclients kan worden gebruikt, lijkt een tijdelijk probleem. Bittorrent heeft aangekondigd dat het de utp-code na de testfase openbaar zal maken. Het bedrijf heeft ook al zitting genomen in een Ietf-werkgroep, in de hoop dat utp uiteindelijk uitgroeit tot een volwaardig en breed ondersteund p2p-protocol.
Beetje vreemd bezwaar. Met een specificatie kan je dit nieuwe protocol toch prima ondersteunen? Wat heeft "opensource" (whatever dat betekent) daar nu helemaal mee te maken?
Knap dat je op T.net zit en niet weet wat Open source is. Geeft niet, je moet het een keer leren :), zie hier: http://nl.wikipedia.org/wiki/Opensource .
Maar het komt er ruwweg op neer dat de implementatie (code) open/beschikbaar is, wat voor de andere clients makkelijker is, omdat deze dan niet zelf de implementatie hoeven te maken n.a.v. de specificaties, maar direct code kunnen gebruiken waarvan bekend is dat het werkt (hoop je ;)) en voldoet aan de specificatie.
Ik lees op die pagina:
Critici wijzen erop dat de term "open source" dubbelzinnig is en dat het verwarring schept over de volledige beschikbaarheid van de bronnen met de vrijheid van gebruik, modificatie en herverspreiding. Softwareontwikkelaars gebruiken daarom liever de term Free/Open Source Software (FOSS), of Free/Libre/Open Source Software (FLOSS) om opensourcesoftware te beschrijven die vrij en gratis beschikbaar is.
Is de code nodig zodat het gratis hergebruikt kan worden (a la Free Software) of is de code nodig om te zien hoe het protocol werkt (niet per se gratis/vrij, dit is "open source" in mijn visie)?

Ik denk dat een specificatie handiger is dan iemand anders' code om eigen code te schrijven. Je hebt Bittorrent inc. code alleen nodig om die implementatie te controleren en eventueel te verbeteren.
Je hebt Bittorrent inc. code alleen nodig om die implementatie te controleren en eventueel te verbeteren.
en dat is dus het hele idee achter open source, stel jij maakt een programmatje, en ik merk dat met hardware x of instelling y dat niet werkt dan kan ik het aanpassen, of mischien wil ik juist wel een knopje hebben om bepaalde dingen gelogd te zien.

Juist door open source heeft software de kans persoonlijker te worden (als je weet wat je doet kan je het aanpassen aan je wensen) en kan het theoretisch sneller verlost worden van bugs (iedereen kan beta tester zijn en programmeur om ontdekte foutjes te herstellen)

-edit-

Waarom zou je een protocol en de implenmentatie daarvan open source maken ?:
in mijn ogen is de main reason hier dat het ervoor zorgt dat mensen niet voor iedere client het wiel opnieuw moeten uitvinden (de code van utp kan dan geporteerd worden naar andere clients en waar nodig aangepast worden)
Als het niet open source wordt zijn die dingen niet mogelijk waarschijnlijk, ofwel het makkelijk porteren ofwel het aanpassen ervan waar nodig
Dit is natuurlijk weer handig om de velen verschillende bittorrent clients die er zijn goed met elkaar te kunnen laten praten

[Reactie gewijzigd door terror538 op 2 december 2008 21:19]

Knap dat je op T.net zit en niet weet wat Open source is.
Nee, hij geeft helemaal niet aan dat hij niet weet wat open source is. Jij hebt z'n punt niet begrepen. Het gaat er om dat het niet perse nodig is om open code van het protocol vrij te geven, zolang de specificaties maar open en volledig zijn. Dan kan iedereen zelf een implementatie bouwen als dat nodig is. De meeste standaarden werken zo, onder andere de standaard die je nu gebruikt om deze pagina te bekijken, zoals http, html en css.
Ik kan bv prima open source code schrijven waar niemand wat mee kan. Dan kan het wel open zijn, maar heb je er niets aan. Zo kan die code van utorrent bv helemaal doorweekt zijn van de win32 specifieke rommel, aangezien de client zelf alleen daarop hoeft te werken, maar heeft een java client als Azureus of een linux client als Ktorrent helemaal niks aan. Specificaties heeft iedereen iets aan.

@Sendy: wat op die pagina staat is onzin. "free" toevoegen aan "open source" maakt het alleen nog maar erger, gezien de dubbele betekenis van het woord "free" in het engels, die niet perse "vrij" maar ook "gratis" betekend. Een programma als winamp is gratis, maar niet vrij, en zeker niet open source. De term "open source" voldoet prima voor z'n doel, aangezien het precies aan geeft wat het is. De officiële definitie van open source staat namelijk gewoon beschreven op internet.

[Reactie gewijzigd door kozue op 2 december 2008 18:06]

Utp maakt gebruik van udp, een van de basisprotocollen van het internet. Udp is mede dankzij een lagere overhead weliswaar sneller dan tcp/ip, maar kent ook een groot nadeel: er kunnen ongemerkt gegevens verloren gaan.
UDP wordt eigenlijk altijd voor games gebruikt daar werkt het goed, hoewel een missend pakketje tussen in inderdaad voor problemen kan zorgen, bij programma's als bittorrent lijkt me dit nog minder een probleem, omdat torrents toch niet in volgorde binnen komen en het programma op zijn gemak kan kijken wat er allemaal nog nodig is om het af te maken.

Dit lijkt me dus ook een logische stap voor bittorrent. Veel andere p2p clients kende dit al lang (Kazaa, emule etc.)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True