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

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)

Reactiefilter:-168068+144+26+30
Moderatie-faq Wijzig weergave
Het versturen van deze correctie-data (PAR) is gewoon extra data. De overhead daarmee is dus ENORM!
SCTP al eens een draai gegeven?
Als je heel precies wilt zijn, dan is het ook geen applicatie protocol. Een applicatie protocol is een protocol dat binnen in de applicatie wordt geprogrammeerd. Dat is dit niet. (HTTP is een soort applicatie protocol). Dit nieuwe protocol wordt (kant-en-klaar) gebruikt door de applicatie. Het is een soort "middle-ware". Tussen de applicatie en het OS in.

IP is een netwerk protocol. Ik durf zelfs te stellen: IP is het netwerk protocol.
UDP zit daar een laag boven. UDP is een transport protocol. (Net als TCP).
Dit nieuwe protocol zit daar weer boven.

De best naam, imho, zou zijn: dit is een soort session-protocol.

(Netjes volgens het OSI model. Maar zelfs dan voldoet het waarschijnlijk niet aan de voorwaarden die het OSI model stelt aan een session-protocol. Bv omdat we in de IP wereld geen echte EndPoint-Indentifiers hebben (alleen interface-addressen)).

[Reactie gewijzigd door gryz op 31 januari 2013 00:55]

udp is van nature veel sneller dan tcp. Immers worden er geen ack's teruggestuurd waarop gewacht moet worden.
Misschien tijd dat iemand het concept "sliding window" uitvindt.
Tuurlijk. Want 108 MegaByte/sec halen over een 1 Gbps netwerk is wel erg slecht. Dit nieuwe protocol is wel 30x sneller. Dus dan kun je mooi 3240 MegaByte/sec halen ! Feest !

Zonder dollen: 108 MBps = 864 Mbps = 0.864 Gbps. Als je in gedachten houdt dat je altijd wat overhead hebt door protocol headers (minimaal 58 bytes voor iedere 1460 bytes aan data = 3.8%), dan zit je al aardig bij de maximale haalbare snelheid. Ik snap niet waar je over klaagt. Ik zou ook eerst eens kijken dan de bottleneck van je HDD (of zelfs SSD). En ook een Atom is niet al te snel, dus dat zou ook een beperkende factor kunnen zijn.
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.
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.
Kijk deze kant moeten we op :D
Dan nog ligt er tussen die datacentres echt een pad dat zo goed is dat je je kan afvragen of dit soort technologie kan helpen. Ze hebben het in het voorbeeld over een pad met drie hele seconden delay, dat is erg veel. Bovendien is bij een DC voor uitwijk de betrouwbaarheid stukker belangrijker dan de latency, dan ga je niet zitten prutsen met een of andere optimalisatie in je applicatielaag.
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]

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.
Inderdaad. Technieken als Cisco WAAS en Riverbed Steelhead doen dit al jaren.

Het protocol van Fujitsu doet alleen TCP optimalisatie. (Aangezien het daar een vervanger voor is.)
Het is geen synchrone cache, het doet geen compressie van data en het doet geen deduplicatie van data. En voor echt hoge latency links kan je het Space Communications Protocol gebruiken.
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.
Maar hoe handelt hij dan de "lost packages" of is "lost" gewoon lost...?
Dat is niet meer zo. Veel bedrijven (de meesten zelfs die ik van binnen heb gezien) hebben hun datacenters outsourced. En zelfs al hebben ze hun eigen centers, dan hebben ze doorgaans nog een uitwijkcenter op behoorlijke afstand. Internationale bedrijven centraliseren naar enkele datacenters voor een groot aantal landen. Als dit het mogelijk maakt met minder datacenters te werken zou het veel geld besparen.
Om precies te zijn gebruiken veel games "reliable UDP". Het simuleert TCP's zekerheid op belangrijke packets (schoten enzo), maar gebruikt gewone packets voor dingen als lopen enzo.
En bovendien, hoe vaak maak je tegenwoordig packetloss mee als je op een server binnen west europa speelt?
Iedere dag als je een Telfort-klant bent...
Dat zijn typisch transacties op korte afstanden in betrouwbare omgevingen met dikke links. Daar is dit protocol dus niet op van toepassing aangezien ze het in de test juist hebben over een langeafstandsverbinding over brakke links (gezien de hoeveelheid latency die ze zonder dit wonderprotocol hadden).
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.
Je denkt als een thuisgebruiker. Fujitsu maakt geen producten voor Henk en zijn gezinnetje thuis! Gamen en video streamen zal daarom niet bij de doelsystemen horen voor Fujitsu.

Waar je aan moet denken zijn productiesystemen, databases etc. die real-time werken en afhankelijk zijn van een snelle en 100% complete overdracht van gegevens. Vertraging in de systemen kan productie vertragen en dat loopt bij bedrijven al snel op tot grote bedragen. Een seconde is geen ramp maar een seconde vertraging per transactie kost bedrijven enorm veel geld.

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 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