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.289 •

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)

Vooral erg fijn als je een dedicated verbinding hebt waarvan je de utilisatie zo hoog mogelijk wilt krijgen. Nu plemp je een lijn vol met meerdere TCP verbindingen zodat de som van feitenlijk verstuurde data ook zo hoog mogelijk tegen de maximale lijn utilisatie zit.
Als de preciese volgorder van aankomst van de data niet essentieel is kan je dan niet net zo goed meerdere TCP sessies opstarten zoals een FTP download manager dat voor je regelt? Toch?
Wat snap ik niet?
Nee, zo werkt het niet. Het is niet zo dat 1 TCP verbinding een limiet heeft, maar dat op een slechte verbinding veel retransmissies plaatsvinden, en dat dat dus tijd kost, en ook bandbreedte.

Dit 'geheime' protocol heeft dat op een andere manier voor specifiek dit soort problemen anders opgelost, waardoor er meer informatie heen en weer kan.
Als je meerdere logische verbindingen op je fysieke link nodig hebt om hem uit te nutten moet je vooral aan het engineeren in de manier waarop de applicatielaag met de data omgaat, die zit dan kennelijk te vertragen (overigens inderdaad een probleem met veel protocollen).

Dit gaat vooral over latency, de responssnelheid na het versturen van een pakketje en het ontvangen van het antwoord daarop. Waar jij het over hebt is de te benutten bandbreedte. Die staat daar min of meer los van. Wat zij hier doen is analoog aan een snellere motor in een auto zetten zodat hij eerder op de plaats van bestemming is. Waar jij het over hebt is de uitbreiding van de kofferbak :)

Het effect van korte latency is (ook binnen TCP overigens) dat de eindstations eerder door hebben wat de maximale snelheid is waarmee ze kunnen communiceren, daarom ontstaat in dit verhaal het verband tussen bandbreedte en delay.

[Reactie gewijzigd door Jheroun op 30 januari 2013 15:16]

Waar jij het over hebt is de te benutten bandbreedte. Die staat daar min of meer los van.
Nee. TCP moet packets acknowledgen of ze zijn aangekomen. Je download een bestand over de satelliet link.
  • 10 IP packets worden gedownload.
  • 500ms wachten
  • TCP upload een acknowledgement
  • 500ms wachten
  • 10 IP packets worden gedownload.
  • 500ms wachten
  • enz.
Dit wordt erger als je packetloss hebt. Stel je hebt een 1Gbps satelliet link met 500 ms latency. Hier staat een calculator. Bij een gigabit link met 500ms latency hou je per TCP flow slechts 1.04Mbps over. Voeg je 1% packetloss toe, dan blijft hier nog maar 0.23 Mbps van over. Bij een gigabit link met 500ms latency moet je downloadmanager dus 1000 sessies opzetten (van 1Mbps elk) om de lijn dicht te kunnen trekken.

[Reactie gewijzigd door Bl@ckbird op 30 januari 2013 17:44]

In mijn ogen is het een beetje zinloos een UDP alternatief (waar packetloss mogelijk is) te gaanvergelijken met TCP dat juist zekerheden aanbieden.

Het is een beetje appels met peren vergelijken wat ze hier doen aangezien zonder retransmissie UDP per definitie beter doet dan TCP en ik van een "opvolger" van UDP dan ook soortgelijk resultaat zou verwachten, vooral als deze geen extra veiligheidslagen inbouwt...

(wat niet wegneemt dat dit protocol beter kan zijn dan standaard UDP en een mooie winst oplevert natuurlijk, maar ze beiden niet echt vegelijkingsmateriaal...).
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.
De vergelijking is wel degelijk terecht. Ze hebben een protocol ontwikkeld dat met behulp van UDP (wat inderdaad packet loss negeert) vergelijkbare kwaliteiten als TCP oplevert: het detecteert welke pakketjes verloren gegaan zijn en zal die opnieuw versturen. Je kunt er dus zeker van zijn dat Šlle data bij de ontvanger aankomt, in tegenstelling tot standaard UDP. Het is dus in zekere zin een concurrent voor TCP.

Wat ik zelf echter niet snap is waarom ze dit bovenop UDP gedaan hebben. Het idee achter UDP is inderdaad dat het niet boeit dat wat pakketjes verloren gaan, terwijl bij TCP die garantie er wel is. Als Fujitsu een protocol wil ontwikkelen dat beter presteert dan TCP maar wel gelijke kwaliteiten hebben snap ik niet dat ze dit niet ook als transport layer protocol hebben gedaan maar als application layer protocol (bovenop UDP dus): hoe efficient ook, het stapelen van protocollen levert altijd enige vorm van overhead op.
Doordat dit op standaard UDP draait kan dit gewoon worden gerouteerd zonder alle routers aan te passen. Als ze een compleet nieuwe protocol op OSI laag 3 hadden ontworpen dan moeten ook alle gebruikte routers worden geupdate.
Leuk hoor, zo'n protocol. Jammer dat het dus propriŽtair is, wat in de echte wereld betekent dat het nooit groot kan worden, of 'net zo groot' als TCP/IP en UDP/IP...
Dit protocol heeft geen zin voor korte afstanden. Op korte afstanden zijn verbindingen doorgaans betrouwbaar genoeg (tenzij je een brakke kabel hebt of wat anders). En wat Denizz ook al zegt: ergens moet er controle zijn. Een overgefloten bestand wil je graag in exact dezelfde vorm ontvangen. Bij TCP/IP regelt de TCP stack dat, bij UDP mag je dat zelf doen.

Packet los door slechte verbindingen kun je niets aan doen. Het kost hoe dan ook een recovery m.b.v. checksums of resent. En bij erg slechte verbindingen komt er helemaal geen bit goed aan de overkant. Daarmee is genoemde test kennelijk toch wel onder redelijk optimale omstandigheden uitgevoerd.

De latency die je hebt door de grote afstanden, kun je ook niets aan doen (hangt van je voortplantingssnelheid af van je signaal), maar de latency die optreedt door opnieuwe verzenden is wel te verbeteren (met TCP met settings, en Fujitsi heeft zijn eigen mechnaniek uitgevonden). En de keuze van een protocol (mate van overhead) speelt een rol.

Ik zou niet weten in hoeverre de TCP/IP stack van bijv. Windows onderscheid weet te maken tussen long & short distance verbindingen, en on-the-fly TCP/IP settings (bijv Windows size) aanpast. Wellicht is daar ook nog een hoop te winnen?
Ik ben niet verbaasd dat dit juist bij Fujitsu vandaan komt.
Een een vorig decennium was daar een Duits bedrijf Softlab dat zijn Maestro II workbench verkocht aan grote bedrijven, ook in Nederland. Dit tool maakte gebruik van een repository op een Unix omgeving die communiceerde met (windows) desktop clients voor de user interface: Een typische client server opzet. Deze communicatie was steevast UDP, want... dit was veel efficienter dan TCP. Alleen moest (extra) error checking aan de client side uitgevoerd worden op de ontvangen data.
De ENABLER repository technologie (object-database) is overgegaan van Softlab naar Fujitsu. Of de Maestro II is meegekomen weet ik niet. In ieder geval heeft Fujitsu goed gekeken naar de Duitse oplossing en deze nieuw leven ingeblazen. Maestro II was gebaseerd op een eigen "operating system" dat bovenop DOS draaide, met eigen tekst-vensterinterface en memory management. De extra benodigde error checking op de client zat dus in de maestro client.
En nu dus heeft Fujitsu kans gezien dit UDP concept opnieuw leven in te blazen.
De ervaring leert dat:

1. Je uit moet kijken als bedrijven met claims als 'x keer zo snel!!' smijten
2. Je hier waarschijnlijk nooit meer iets over hoort.

Volgende bericht.
Kijk deze kant moeten we op :D
Hoeveel van dit soort protocollen op basis van UDP zullen al niet gemaakt zijn?

BitTorrent Inc. was met zijn Micro Transport Protocol (ĶTP) er al veel eerder mee.

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 500GBSamsung

© 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