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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 68, views: 15.320 •

Fujitsu heeft naar eigen zeggen een nieuw en propriŽtair transmissieprotocol ontwikkeld op basis van udp dat ten opzichte van tcp tot dertigmaal hogere doorvoersnelheden mogelijk maakt. Ook de latency zou fors verlaagd kunnen worden.

Het nieuwe protocol maakt gebruik van de sterke punten van udp, een netwerkprotocol dat gebruikt wordt voor toepassingen als streaming media en online gaming. Udp weet gemiddeld hogere snelheden te behalen dan tcp, maar het protocol beschikt niet over een mechanisme voor het opnieuw versturen van datapakketjes als deze niet aankomen op de plek van bestemming.

Fujitsu stelt dat zijn nog naamloze protocol de latency van tcp bij het opnieuw versturen van data bij slechte dataverbindingen sterk kan reduceren. Dit zou mogelijk zijn doordat het protocol een eigen controlemechanisme heeft en op hoge snelheid onderscheid zou kunnen maken tussen lost packets en pakketjes die nog niet zijn gearriveerd op de plek van bestemming.

Fujitsu netwerkprotocol

Fujitsu claimt dat tijdens tests met het versturen van bestanden tussen Japan en de VS snelheidswinsten met een factor 30 zijn behaald. Bij het gebruiken van virtuele desktops over dezelfde verbinding zou de latency slechts 1/6 bedragen ten opzichte van eerder gemeten niveaus.

Het protocol zou als software-uitbreiding boven op een udp-stack kunnen draaien. Verder claimt Fujitsu dat een groot aantal internettoepassingen die gebruikmaken van tcp zonder verdere aanpassingen gebruik kan maken van het nieuwe protocol. Het Japanse bedrijf wil zijn netwerkprotocol aan andere bedrijven gaan verkopen in de vorm van middleware.

Reacties (68)

Idee:
Je kan ook met errorcorrectie (ala DVD) de data opzich zodanig redundant maken dat je de missende paketjes can reconstrueren.
Dan hoef je helemaal niets meer te hersturen en is het alleen problematisch als er zoveel niet aankomt dat het reconstrueren ook niet meer lukt.
En dan ben je inderdaad van die hele handshake af.

[Reactie gewijzigd door trogdor op 30 januari 2013 23:11]

tja je zou het misschien wel kunnen in bouwen aan de ontvangende kant
dat de computer zelf bij houd welke pakketjes aan komen en als er iets mist zou de aan de zendende computer kunnen vragen het nogmaals te versturen
dat genererend natuurlijk veel minder data..
Hoezo minder data ?
Wat je daar beschrijft, is wat TCP doet. De overhead van TCP is 20 bytes per segment. (En een segment kan (praktisch) zo'n 1400 bytes lang zijn. Dat is ongeveer 1% overhead (in packetsize). Ga je dat beter doen met je eigen protocol ?
voorbeeld tcp/ip
Ik heb een pak met 100 rietjes en jij wil het pak met rietjes hebben
we onderhandelen en ik stuur 1 rietje per keer naar je op via de post jij stuurt mij een brief terug van ontvangen stuur de volgende maar op. dit gaan we net zo lang doen tot jij alle rietjes hebt... best wel een tijds verspilling niet?
Gelukkig hebben we een "sliding window" in TCP. Van 64k (of groter, met nieuwere, gestandariseerde extensies). TCP zend dus een hoop rietjes achter elkaar, voordat het wacht op een ack.
Het zou fijn zijn als de nieuwe standaard dus zegt van
ik heb de doos binnen gekregen maar ik mis 2 rietjes stuur mij die even na.
dat scheelt heel veel data of we zouden standaard correctie bits moeten versturen en als we dus met films doen (par2 files is een voorbeeld)
Dat bestaat al. In TCP. En heet "selective ack (SACK)".
RFC 2018 uit 1996: http://www.hjp.at/doc/rfc/rfc2018.txt
RFC 2883 uit 2000: http://tools.ietf.org/html/rfc2883

Mensen hebben altijd kritiek op TCP. Dat het traag zou zijn. Dat het veel overhead heeft. Maar als ze dan zelf beginnen met een eigen transport protocol te ontwikkelen, dan blijkt na een tijdje dat ze alle features uit TCP hebben nagebouwd. En dus net zo veel "overhead" hebben.

Alleen als je voor specifieke applicaties een nieuw transport protocol wilt bouwen, dan heb je kans van slagen. Als je een general purpose reliable transport protocol wilt maken, voor zowel grote files als korte transacties, of interactief werk, dan is TCP een uitstekende keuze.

Dit protocol van Fijutsu heeft zich toegelegd op situaties waar je veel packet drops hebt. Tegenwoordig is dat vrij zeldzaam, behalve bij drukke WiFi netwerken. En zelfs dan hangt het er nog maar vanaf. Een maand of wat geleden was er hier een soortgelijk artikel over een ander protocol voor WiFi (met drops). Daar bleek dat de onderzoekers hun protocol hadden vergeleken met TCP zonder SACK. Tsja, dan lijkt het allicht beter dan de TCP van voor 1996.
Het protocol gaat beter om met high latency / high package-loss verbindingen. OF eigenlijk beter gezegd TCP gaat er heel slecht mee om. Deze problemen worden uitvergroot wanneer de verbindingen sneller worden. De afgelopen 10 jaar zijn er heel wat papers uitgekomen met oplossingen ik vermoed dat een aantal van deze zijn gecombineerd en geÔmplementeerd.

http://fasterdata.es.net/...ing/tcp-issues-explained/ beschrijft een deel van de problemen.
Dat lijkt me ook precies wat fujitsu heeft uitgewerkt. Applicatie level controle, daaronder gebruiken ze gewoon UDP.

Dus dit is geen netwerkprotocol maar een applicatieprotocol, het netwerkprotocol is gewoon UDP.

Zoals al eerder gezegd komen er wel meer van dit soort dingen langs, vaak ontwikkeld door partijen die een applicatie bieden die zowel lage latency als betrrouwbaarheid vereisen. Daarmee zal het dus concurreren, niet met TCP of UDP.
Hmm, niet echt nieuws in mijn ogen. Door de control's van TCP te verplaatsen naar een hogere laag kun je inderdaad bepaalde "nadelen" van TCP oplossen, maar er wordt even voorbij gegaan aan het feit dat binnen TCP al veel te tunen valt voor specifieke scenario's. Indien je een high latency verbinding met packetloss hebt, kun je bijvoorbeeld spelen met de window sizing en hoe snel deze opschaalt. De 30x sneller stelling lijkt me gebaseerd op "sane default" van een willekeurig OS. Zeker niet geoptimaliseerd voor de specifieke situatie. Ik zeg niet dat TCp per definitie even snel kan werken als UDP, maar ik denk dat dit meer een slim geschreven marketing middel is voor een commercieel product. Overigens lijkt me in de huidige tijd een implementatie van een proprietary protocol not done.

Daarnaast zijn er al vaker dit soort ideeen uitgewerkt en geoppert. Zoals Reliable UDP bijvoorbeeld. Ook heeft een UDP header bepaalde controls niet in de header, zoals handeling van fragmentatie.

Daarnaast geeft het feit dat TCP, sessie gebaseerd is (i.t.t. connectionless UDP), tussenliggende apparaten als proxies en firewalls veel meer handvaten of iets zinnigs met het verkeer te doen.

Dit protocol zal niet spoedig de wereld gaan veroveren ;-).

[Reactie gewijzigd door Dennizz op 30 januari 2013 13:53]

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBGrand Theft Auto V

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013