Toevoeging aan bittorrentprotocol moet serverlast verlagen
Het ontwikkelteam van BitTorrent heeft het gelijknamige p2p-protocol uitgebreid waardoor het dataverkeer naar trackers gereduceerd kan worden. De uitbreiding is er gekomen na protest van de trackers OpenBitTorrent en PublicBitTorrent.
Enkele weken geleden gingen de publieke trackers OpenBitTorrent en PublicBitTorrent, die draaien op Opentracker-software, uit protest uit de lucht. De trackers deden dit omdat zij van mening waren dat BitTorrent Inc, het bedrijf dat de basis legt voor het bittorrentprotocol, niets deed met voorgestelde uitbreidingen op het protocol.
De voorgestelde uitbreidingen op het torrentprotocol zijn afkomstig van Frederik Neij, medeoprichter van The Pirate Bay, en waren enige tijd geleden al geplaatst op het forum van de torrentclient μTorrent. De protocoluitbreidingen bieden beheerders van publieke trackers de mogelijkheid om met behulp van extra dns-entries aan te geven welk type dataverkeer zij accepteren, zoals udp of tcp.
OpenBitTorrent en PublicBitTorrent reageerden enthousiast op Neij's voorstellen, omdat beide sites het dataverkeer naar de trackerservers zouden kunnen reduceren en de serverload kunnen verlichten. Om dezelfde reden stapten beide trackers al eerder over op het udp-protocol. BitTorrent deed echter lange tijd niets met de voorstellen, met een staking van de twee publieke trackers tot gevolg.
De staking lijkt effect te hebben gesorteerd: inmiddels heeft BitTorrent toch actie ondernomen en de voorstellen opgenomen in een protocol enhancement draft, zo meldt TorrentFreak. De aankomende alfa-versie van μTorrent zou de nieuwe functionaliteit al standaard geactiveerd hebben. Ook andere ontwikkelaars van torrentclients hebben aangegeven dat zij de protocoluitbreidingen zullen implementeren.
Reacties (34)
betekend dit dat ze voortaan dan gaan draaien op udp in plaats van tcp? en dat het dus vaker fouten in de gedownloaden bestanden kan zitten aangezien er geen controle meer plaats vind of die goed binnen komt?
Nee natuurlijk niet. Data-integriteit wordt gegarandeerd door de hashes van de files: dat zit nog een paar lagen hoger...
Nee, het gaat puur om de tracker informatie en dus niet het downloaden van files.
Bittorrent kan al veel langer UDP gebruiken, dit wordt gedaan omdat het veel minder belastend is voor het netwerk. Vervolgens zorgt de applicatie dat incorrect of niet aangekomen stukken bestand opnieuw gedownload worden. Dus je downloads zullen correct blijven.
Nee. Dit gaat alleen over de trackers, niet over het verkeer tussen verschillende gebruikers onderling (de daadwerkelijke data voor je files dus)
TCP Bittorrent trackers gebruiken het HTTP protocol. UDP trackers gebruiken een volledig eigen protocol, wat veel efficienter is in de hoeveel over te sturen informatie. Hierin zit ook logica om data opnieuw te sturen als het verkeerd overgekomen is, dus ook hierbij gaat niets verloren.
TCP Bittorrent trackers gebruiken het HTTP protocol. UDP trackers gebruiken een volledig eigen protocol, wat veel efficienter is in de hoeveel over te sturen informatie. Hierin zit ook logica om data opnieuw te sturen als het verkeerd overgekomen is, dus ook hierbij gaat niets verloren.
[Reactie gewijzigd door brama op dinsdag 31 juli 2012 14:50]
TCP garandeert alleen maar dat een pakketje (dat heel klein is) precies binnenkomt zoals het verstuurd is. Het garandeert niets over de integriteit van de uiteindelijke bestanden die uit duizenden van die pakketjes kunnen bestaan.
De pakketjes moeten in beginsel natuurlijk correct verstuurd worden, en dat gebeurt niet altijd. Bij "normaal" internetverkeer kun je de server hiervoor verantwoordelijk stellen, maar van normale gebruikers kun je een dergelijke eis niet stellen. Bovendien kunnen er dingen kapot gaan waar ze geen controle over hebben - de ISP kan bijv dingen verminken. Het protocol is dus zo ingericht, dan ondanks het gebruik van TCP er toch controles op integriteit gedaan worden.
Wat dat betreft kun je voor dataverbindingen dus net zo goedUDP gebruiken...
En dat gebeurt ook
De pakketjes moeten in beginsel natuurlijk correct verstuurd worden, en dat gebeurt niet altijd. Bij "normaal" internetverkeer kun je de server hiervoor verantwoordelijk stellen, maar van normale gebruikers kun je een dergelijke eis niet stellen. Bovendien kunnen er dingen kapot gaan waar ze geen controle over hebben - de ISP kan bijv dingen verminken. Het protocol is dus zo ingericht, dan ondanks het gebruik van TCP er toch controles op integriteit gedaan worden.
Wat dat betreft kun je voor dataverbindingen dus net zo goedUDP gebruiken...
En dat gebeurt ook
TCP gaat voornamelijk om dàt ze aankomen en de volgorde. TCP bevat niet meer checksums dan UDP.
Nee. TCP garandeert de integriteit van een complete datastroom -- als er pakketten verloren gaan worden ze opnieuw verstuurd, en er zit een volgorde in de pakketstroom. Dat, althans, is de theorie, waar in de praktijk natuurlijk wel dingen mee mis gaan -- maar dat zijn dus altijd gevallen waarin de verbinding niet goed gewerkt heeft, want het protocol garandeert het wel degelijk.TCP garandeert alleen maar dat een pakketje (dat heel klein is) precies binnenkomt zoals het verstuurd is. Het garandeert niets over de integriteit van de uiteindelijke bestanden die uit duizenden van die pakketjes kunnen bestaan.
UDP garandeert ook al integriteit van het pakket met checksums, op dezelfde manier als TCP. Het garandeert alleen niets over de aankomst of volgorde van pakketten. Veel mensen die met UDP beginnen wegens "minder overhead" doen uiteindelijk TCP dunnetjes over. Er zijn specifieke toepassingen waar UDP nut heeft, maar het is zeker niet zo dat je "net zo goed" UDP kunt gebruiken omdat TCP niets toe zou voegen.
Wat ik probeer te zeggen, is dat TCP geen reet uitmaakt als een pakket verkeerd verstuurd was. Dan kun je er nog zoveel checksums omgeen vouwen, die gaan niet helpen als de brongegevens niet werken. En er zijn nou eenmaal heel wat BT-clients, en ze hebben allemaal wel bugs. En ze draaien allemaal op een OS dat bugs kan hebben. En die draaien allemaal weer op hardware die niet van enterprise-niveau is.
Dus wat *dat* betreft, kun je net zo goed UDP gebruiken. Helemaal als er al TCP-achtige functionaliteit in het protocol zit.
Dus wat *dat* betreft, kun je net zo goed UDP gebruiken. Helemaal als er al TCP-achtige functionaliteit in het protocol zit.
Hier de technische informatie:
http://bittorrent.org/beps/bep_0034.html
Ik begrijp niet helemaal dat hier een staking voor nodig was
http://bittorrent.org/beps/bep_0034.html
Ik begrijp niet helemaal dat hier een staking voor nodig was
Stel dat je 10.000.000 packets per seconde hebt, en je dat kan reduceren tot 5.000.000, dan heb je toch wel wat winst...
Men wil in het DNS record meer informatie toevoegen, zodat de torrent client al onmiddelijk weet of een bepaalde host al dan niet één of meerdere trackers heeft. Hiervoor wil men het 'TXT record' gebruiken. Dit is een soort van free text veld zoals beschreven in RFC 1035:
Mocht de tracker gezocht worden op bv. een verkeerde poort of met een ander protocol (tcp ipv udp) dan zal de torrent client automatisch switchen naar de juiste poort / protocol. Het 'TEXT record' bepaalde deze door bv.:3.3.14. TXT RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ TXT-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
TXT-DATA One or more <character-string>s.
TXT RRs are used to hold descriptive text. The semantics of the text
depends on the domain where it is found.
"BITTORRENT UDP:1337 TCP:80" - The host is running two trackers, one on UDP port 1337 and one on TCP port 80. The UDP tracker is prefered.
[Reactie gewijzigd door Ravefiend op dinsdag 31 juli 2012 15:07]
Developers van uTorrent lijken vooral geinteresseerd in geld verdienen.Ik begrijp niet helemaal dat hier een staking voor nodig was
Dit soort features zijn jaren geleden al aangevraagd maar tot nu toe niet geimplementeerd.
Na het lezen van de Abstract van de link: http://bittorrent.org/beps/bep_0034.html
begreep ik het volledig.
Abstract
Sometimes when users create torrents they mistakingly add website URLs as trackers. This results in those websites getting flooded with unwanted HTTP traffic.
To prevent this flooding, trackers and websites can declare via DNS TXT record which ports (if any) on which they are running trackers.
If a torrent contains a URL that according to this record does not have a tracker running on it, the client should attempt to fix the URL by trying connections on one or more of the ports in the TXT record.
This will also be helpful for example when a tracker switches from HTTP to UDP service, to prevent the tracker from being flooded with obsolete HTTP requests. This would direct the client to use UDP instead of HTTP in a old torrent where only the previous service are listed.
It's worth noting that this could potentially allow ISPs to prevent trackers from operating by injecting entries into DNS records.
begreep ik het volledig.
Abstract
Sometimes when users create torrents they mistakingly add website URLs as trackers. This results in those websites getting flooded with unwanted HTTP traffic.
To prevent this flooding, trackers and websites can declare via DNS TXT record which ports (if any) on which they are running trackers.
If a torrent contains a URL that according to this record does not have a tracker running on it, the client should attempt to fix the URL by trying connections on one or more of the ports in the TXT record.
This will also be helpful for example when a tracker switches from HTTP to UDP service, to prevent the tracker from being flooded with obsolete HTTP requests. This would direct the client to use UDP instead of HTTP in a old torrent where only the previous service are listed.
It's worth noting that this could potentially allow ISPs to prevent trackers from operating by injecting entries into DNS records.
Het is handig, maar het probleem is dat er vaak op BT geshaped wordt. Net zoals in Belgie (Telenet), hier haal je vaak zelfs snelheden van 1Mbps op BT-protocol, terwijl de HTTP aan 120MBps nog steeds werkt.
Lang leve de netneutraliteit in NL.
Die we pas op 1 januari aanstaande hebben....
Edit, en nadat het artikel van kracht is geworden kan er nog steeds geshaped worden:
Edit, en nadat het artikel van kracht is geworden kan er nog steeds geshaped worden:
P2P kan dus een trapje lager worden gezet.Artikel 7.4a [Treedt in werking per 01-01-2013]
1. Aanbieders van openbare elektronische communicatienetwerken waarover internettoegangsdiensten worden geleverd en aanbieders van internettoegangsdiensten belemmeren of vertragen geen diensten of toepassingen op het internet, tenzij en voor zover de betreffende maatregel waarmee diensten of toepassingen worden belemmerd of vertraagd noodzakelijk is:
a. om de gevolgen van congestie te beperken, waarbij gelijke soorten verkeer gelijk worden behandeld;
[Reactie gewijzigd door ADQ op dinsdag 31 juli 2012 15:22]
maar alleen als hier technische noodzaak (namelijk congestie) toe is...
... als een provider ongeoorloofd zal gaan filteren lopen ze gewoon stuk bij een rechtbank...
... als een provider ongeoorloofd zal gaan filteren lopen ze gewoon stuk bij een rechtbank...
Jamaar meneer de rechter, we kopen x gb bandbreedte in, meer kunnen we niet betalen. En we willen wel al onze klanten bedienen, en niet alleen die paar bittorrenters die toch alleen maar porno downloaden.
En de rechter kan niet anders doen dan de provider gelijk geven.
En de rechter kan niet anders doen dan de provider gelijk geven.
Dat is een commerciële beperking en geen technische. Het staat je immers vrij om te investeren (en die investering terug te verdienen door prijzen te verhogen). En providers kunnen ook de good-old datalimieten weer van stal halen.
Als $klant betaalt voor een verbinding van 50Mbps down, en 5Mbps up, zonder datalimiet, en $klant gebruikt die verbinding om 24*7 torrents te downloaden met 50Mbps en te seeden met 5Mbps is er niets dat de provider daartegen kan doen.
Als de provider kennelijk zijn service verkeerd aangepakt heeft waardoor hij niet kosten-efficiënt de beloofde dienst kan leveren, wil dat nog niet zeggen dat jij als klant dan maar afgeknepen moet worden; of het nu om BT of HTTP verkeer gaat.
Als $klant betaalt voor een verbinding van 50Mbps down, en 5Mbps up, zonder datalimiet, en $klant gebruikt die verbinding om 24*7 torrents te downloaden met 50Mbps en te seeden met 5Mbps is er niets dat de provider daartegen kan doen.
Als de provider kennelijk zijn service verkeerd aangepakt heeft waardoor hij niet kosten-efficiënt de beloofde dienst kan leveren, wil dat nog niet zeggen dat jij als klant dan maar afgeknepen moet worden; of het nu om BT of HTTP verkeer gaat.
Lang leve encryptie (tot netneutraliteit).
Trackers die UDP accepteren, hebben meestal een url die met "udp://" begint. Dat is op zich niet onlogisch, gezien http *altijd* over tcp moet, volgens de standaard.
Dus ik begrijp nog niet helemaal wat nou precies de uitbreiding moet inhouden.
Dus ik begrijp nog niet helemaal wat nou precies de uitbreiding moet inhouden.
[Reactie gewijzigd door _Thanatos_ op dinsdag 31 juli 2012 14:51]
De uitbreiding is het propageren van de beschikbare servers van een tracker aan een client.
Als een client geconnect is met een TCP server van een tracker, en de tracker bekend maakt dat het ook een UDP server heeft, kan de client er voor kiezen om te switchen naar het UDP protocol. Zo besparen zowel client als tracker bandbreedte en requests.
@hieronder:
Je communiceert ook later met de tracker, niet alleen bij het initialiseren van de download. Wellicht maar een of twee keer per uur per torrent, maar als een openbare tracker duizenden of miljoenen torrents trackt dan tikt dat aan.
En het probleem is dat mensen die gebruik maken van publieke trackers een hele lijst plakken van TCP en UDP trackers. Je client weet niet welke de voorkeur heeft en of er duplicates tussen zitten, die gaat vrolijk naar alle servers connecten.
Als een client geconnect is met een TCP server van een tracker, en de tracker bekend maakt dat het ook een UDP server heeft, kan de client er voor kiezen om te switchen naar het UDP protocol. Zo besparen zowel client als tracker bandbreedte en requests.
@hieronder:
Je communiceert ook later met de tracker, niet alleen bij het initialiseren van de download. Wellicht maar een of twee keer per uur per torrent, maar als een openbare tracker duizenden of miljoenen torrents trackt dan tikt dat aan.
En het probleem is dat mensen die gebruik maken van publieke trackers een hele lijst plakken van TCP en UDP trackers. Je client weet niet welke de voorkeur heeft en of er duplicates tussen zitten, die gaat vrolijk naar alle servers connecten.
[Reactie gewijzigd door Blaise op dinsdag 31 juli 2012 17:38]
Als je al verbonden bent met TCP, dan heeft het geen nut meer om op te hangen en over te gaan naar UDP. De extra DNS record is bedoeld dat de client vooraf zelf kan bepalen of TCP of UDP wordt gebruikt.
Ja de UDP response van een tracker is volledig binair en dus compacter, maar de TCP response kan (indien de client dat vraagt) een 'compact'e lijst van peers bevatten, ook binair. Dus zoveel maakt het niet uit.
Ik begrijp het probleem hier niet helemaal. In een .torrent bestand kan een tracker al aangegeven worden met udp:// of tcp:// - de eerste in de lijst krijgt de voorkeur.
Dus volgens mij is dit hele DNS verhaal eigenlijk verzonnen omdat blijkbaar mensen die een torrent maken, niet UDP trackers voorrang geven. Dit willen ze dus forceren dmv DNS, zodat de client, en niet de persoon, kan kiezen tussen TCP of UDP.
Ja de UDP response van een tracker is volledig binair en dus compacter, maar de TCP response kan (indien de client dat vraagt) een 'compact'e lijst van peers bevatten, ook binair. Dus zoveel maakt het niet uit.
Ik begrijp het probleem hier niet helemaal. In een .torrent bestand kan een tracker al aangegeven worden met udp:// of tcp:// - de eerste in de lijst krijgt de voorkeur.
Dus volgens mij is dit hele DNS verhaal eigenlijk verzonnen omdat blijkbaar mensen die een torrent maken, niet UDP trackers voorrang geven. Dit willen ze dus forceren dmv DNS, zodat de client, en niet de persoon, kan kiezen tussen TCP of UDP.
Het punt is juist dat er nog een heleboel oude torrents zijn met HTTP als communicatie voor de tracker, terwijl er allang een UDP variant op die server staat.Trackers die UDP accepteren, hebben meestal een url die met "udp://" begint. Dat is op zich niet onlogisch, gezien http *altijd* over tcp moet, volgens de standaard.
Een ander punt is dat mensen, of scripts, uit gewoonte de HTTP variant gebruiken.
Om dit te overrulen is dit TXT record er, zodat de client daarbovenop nog eens die check kan door door het TXT record aan te vragen en aan de hand daarvan beter te bepalen of er op met UDP / TCP verbonden moet worden en op welke port.
@Thantos
Alles op internet gaat over tcp of udp , maar het gaat hier simpel gezegd om wat gebeurt er als ik het NIET opgeef, dat veroorzaakt extra serverload, net als tcp over udp trouwens.
Tcp kost meer dan udp, op hogere lagen kunt je je dataintegriteit garanderen.
Zeker bij veel korte verbindingen kun je aardig besparen door udp te gebruiken, precies wat trackers doen.
Met tcp kun je nooit meer dan 65635 (theoretisch, realiteit is minder) verbindingen maken op één ip adres, en dat terwijl een computer er heel veel meer kan verwerken tegenwoordig.
Door dus udp te gebruiken heb je minder computers nodig voor het zelfde. Echter als je niet weet of de andere kant tcp, udp of beide praat, heb je geen voordelen van udp meer omdat je moet gaan proberen. Door dit via dns op te lossen heb je pas het udp voordeel.
Alles op internet gaat over tcp of udp , maar het gaat hier simpel gezegd om wat gebeurt er als ik het NIET opgeef, dat veroorzaakt extra serverload, net als tcp over udp trouwens.
Tcp kost meer dan udp, op hogere lagen kunt je je dataintegriteit garanderen.
Zeker bij veel korte verbindingen kun je aardig besparen door udp te gebruiken, precies wat trackers doen.
Met tcp kun je nooit meer dan 65635 (theoretisch, realiteit is minder) verbindingen maken op één ip adres, en dat terwijl een computer er heel veel meer kan verwerken tegenwoordig.
Door dus udp te gebruiken heb je minder computers nodig voor het zelfde. Echter als je niet weet of de andere kant tcp, udp of beide praat, heb je geen voordelen van udp meer omdat je moet gaan proberen. Door dit via dns op te lossen heb je pas het udp voordeel.
Dat is niet waar, je kunt met 100k clients verbinden naar 1 server, allemaal op poort 80. Die 64ki poorten is daar niet de limiet op. Wel op outgoing verbindingen, maar die doet een tracker niet en een client verbindt niet naar 100k trackers.
Overigens kan een server echt geen 50k+ simultaneous connections aan oha. Dat trekt een ethernet lijntje niet zo heel geweldig.
Overigens kan een server echt geen 50k+ simultaneous connections aan oha. Dat trekt een ethernet lijntje niet zo heel geweldig.
Ook niet.Wel op outgoing verbindingen,
Alleen op outgoing verbindingen naar hetzelfde endpoint (ip:port).Lang leve private trackers..
Moeten ze natuurlijk niet uit de lucht gaan 
lang leve usenet en een syno nas
Trackers trekken onnodig veel aandacht, private index en DHT.
Dus om wat serverload te besparen moet heel de wereld maar bandbreedte inleveren? Onlogisch.
Van de andere kant is dit een interessante 'mes-op-de-keel-aanpak' om softwareontwikkelaars te dwingen iets te implementeren wat voor het grootste gedeelte voor de bedreigers goed uitkomt.
Ik krijg hier gemengde gevoelens bij. Zeker als een paar mensen in andere branches (in de IT) erachter komen dat deze aanpak voor hun ook werkt, maar dan wel ten koste van het grootste gedeelte van de (IT-)wereld. Zorgelijk.
Ik krijg hier gemengde gevoelens bij. Zeker als een paar mensen in andere branches (in de IT) erachter komen dat deze aanpak voor hun ook werkt, maar dan wel ten koste van het grootste gedeelte van de (IT-)wereld. Zorgelijk.
Op dit item kan niet meer gereageerd worden.
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
