Onderzoeker bedenkt protocol voor snellere webservices

ZDNet weet te melden dat een professor - Jonghun Park genaamd - een nieuw protocol heeft ontwikkeld waarmee de huidige informatie tot tien keer zo snel te verwerken is, zo claimt hij. Het protocol zal Order-based Deadlock Prevention Protocol with Parallel Requests gaan heten. Deze hele mond vol tekst is gebaseerd op een algoritme dat een parallelle methode gebruikt om aanvragen te verwerken, iets wat nu nog serieel geschiedt. Experts zijn onder de indruk, maar waarschuwen dat voor het gebruik van dit protocol in bijvoorbeeld webservices eerst andere knelpunten op het gebied van veiligheid en betrouwbaarheid overwonnen moeten worden.

Desondanks zal volgens de experts bij een groot webservices-netwerk de komst van een efficiëntere verwerkingsmethode zeker welkom geheten worden. Het nieuwe protocol heeft niets meer met deadlocks en freelocks van doen en zoekt zijn extra snelheid in het effectiever gebruiken van aanwezige alternatieve bronnen van gevraagde informatie. Park zal de nieuwste versie van zijn protocol, waar een jaar van finetunen in is gaan zitten, binnenkort op een symposium in Australië presenteren.

Reacties (42)

[watzie]

Grappig dat alle tweakertjes hun bril niet ophebben. Het gaat over WebServices. Het gaat dus niet over het internet sneller maken, tcp/ip, downloadsnelheden of wat dan ook (wel leuke discussies trouwens). Nou verwacht ik niet dat niet programmeurs zo 123 weten wat een webservice is maar ik had toch wel verwacht dat iemand hier op in zou gaan?

Web services are a highly effective means of enhancing interoperability across heterogeneous platforms. A Web service is an application that exists in a distributed environment, such as the Internet. A Web service accepts a request, performs its function based on the request, and returns a response. The request and the response can be part of the same operation, or they can occur separately, in which case the consumer does not need to wait for a response. Both the request and the response usually take the form of XML, a portable data-interchange format, and are delivered over a wire protocol, such as HTTP.

Web service transactions are usually conducted between businesses. A business that is a provider of one service can also be a consumer of another service. A Web service consumer can also be a client device, such as a thin client connecting to the Web service provider over a lightweight protocol.

Kort door de bocht dus: WebServices zijn een protocol om (via het web) calls naar functies van systemen te maken (beetje RPC achtig dus), onafhankelijk van het platform van de aanroeper nog de service provider, gebaseerd op XML. Een soort van universele babbeltaal dus. De webservice zelf kan alles zijn wat je verzint (een vliegticket reserveringssysteem, weerdienst, nieuws, b2b etc.)
Vooral populair voor het koppelen van nieuwe applicaties aan bestaande (je hoeft alleen maar een webservice interface eromheen te bouwen en hop je kunt het aanroepen zonder het helemaal opnieuw te hoeven schrijven).

[Just_a_Gamer]

Goede post Watzie. Ook vind ik dat sommige mensen het artikel van ZDNet niet goed gelezen. Het gaat ook met name met DeadLocks en LiveLocks problemen bij webservices. Zoals misschien sommige mensen dat weten, worden bij de webservices elke request/response een process opgestart. Wanneer er meer request komen van de clients bij de webservices en de requests worden steeds langer kost het meer procestijd en geheugen. Deze problemen kan je niet met de nieuwe versie van IP of met grotere bandbreedte op te lossen.

[atomik]

Eindelijk iemand die de moeite neemt een en ander uit te zoeken voor hij gaat blaten! Hulde!!

[Captain Pervert]

Ik vraag me af in hoeverre de protocols die op dit moment gebruikt worden de bottleneck zijn, mij lijkt eerder de infrastructuur zoals backbones, knooppunten en dergelijke?

[ACM]

TCP en IP zijn vreselijk "domme" protocollen. Er is geen (echte) congestion control, geen garanties over allerlei belangrijke zaken als response tijden en bandbreedtes en er mist nog veel meer.

Het internet doet nu niets meer dan een simpele "best effort"-load balancing, wat er in de praktijk op neer komt dat sommige verbindingen helemaal niets doen terwijl andere stampvol zitten.

Het voordeel van het "domme" van TCP en IP is wel dat het niet steeds over dezelfde verbinding hoeft te lopen waardoor het wat flexibeler met uitval van routers en verbindingen zou moeten zijn.

HTTP zelf is ook, in zulke opzichten, nog erg "dom" dus wat dat betreft is er zeker in combinatie met een verbeterde transportlayer nog een hoop te optimaliseren.

Al met al denk ik dat er nog aardig wat te verbeteren is aan het internet op het gebied van protocollen. Hoewel je ftp-download natuurlijk niet ineens sneller zal worden dan de maximum van je huidige verbinding daardoor

Btw, de titel is erg misleidend.
Het gaat niet om een vervanger voor TCP, eerder voor een soort vervanger voor HTTP.

[ijdod]

Je vergeeet de belangrijkste metric voor internet routers: kosten per MB. Hoewel je er als eindgebruikers weinig van merkt anders dan je datalimiet c.q. FUP, betaald iemand de rekeningen. Providers zullen hun verkeer bij voorkeur via de goedkoopste carrier routeren. Congestion en delay zijn daaraan meestal ondergeschikt.

[_JGC_]

Ik weet niet of jij weet hoe het SMTP protocol inelkaar zit, maar dies behoorlijk bloated: eerst gaat er over en weer wie er is en zegt de server steeds "ok, je mag nu sturen, nu mag je dat sturen, ok, ik heb em... etc"

Dan J Bernstein heeft hier destijds een ander protocol op bedacht: QMTP. Waar het op neer komt: client zegt waar de mail weg komt, server geeft een ack, client stuurt z'n HELE zooi aan data waarbij de server z'n bek houdt. Pas als de client klaar is mag de server z'n bek weer opentrekken. Uiteindelijk zou dat resulteren in een protocol wat stukken sneller veel mails kan verwerken (je kunt met 1 connectie ook meerder mails versturen, iets wat SMTP overigens ook kon)

Niet alleen SMTP is een nogal verbose protocol, er zijn nog veel meer: bijvoorbeeld WWW, IMAP en POP3.

De beperkte bandbreedte die je hebt moet je gewoon beter benutten, dat is waar deze nieuwe protocollen voor bedacht worden.

* 786562 Jan

[Verwijderd]

Volgens mij doet dit er wel toe. Internet werkt volgens mij packet georiënteerd. Voor iedere packet moet steeds weer de route gevonden worden en volgens mij als dat tien keer zo snel gaat, zullen met name videostreams en telefonie via internet stukken beter lopen zonder fysiek de capaciteit te verhogen.

Ik kan er natuurlijk ook helemaal naast zitten maar dan hoor ik graag hoe het wel is :-)

[ACM]

Ondanks dat het packet georienteerd is kan er wel degelijk een vaste route bedacht worden door een router, daar is ie in principe vrij in om te doen

Videostreams etc zullen meer winnen door efficientere multicasts dan door slimmere protocollen voor informatie vergaring.
De 100Mbits verbinding kan echt niet ineens een gigabit verwerken namelijk

[MBV]

De vertraging is bij spraak en video heel belangrijk. En juist daar kan nog het een en ander aan verbeterd worden bij tcp/ip. Dat geeft geen garanties over responstijd etc.

[Verwijderd]

Het gaat hier dus om een verbetering in de afhandeling van de processen al zei tegelijkertijd draaien.
Bij een pure download zal je daarom niet veel merken.
Het verschil zal hem denk ik vooral in dynamische webinhoud zitten aangezien hiervoor een aantal processen door elkaar lopen en als de afhandeling hievan versneld kan worden zal het resultaat sneller bij je aankomen.

[Verwijderd]

Het valt mij op dat in deze nieuwsposting er niet erg diep wordt ingegaan over wat dat nieuwe protocol dan precies inhoudt.

Het komt er dus dat er minder deadlock zal optreden deadlock is als 2 processen op elkaar aan het wachten zijn om data te versturen aangezien ze beide op elkaar wachten zal er dan niets gebeuren.

En minder livelock op zal treden dit is als 2 processen zich cconstant aan elkaar aan passen en hierdoor zelf nauwelijks enige productieviteit kunen hebben.

Het heeft dus niet veel met P2P te maken zoals in een eerdere replie gezegd werd maar meer met het oplossen van veel voorkomende opstoppingen in de afhandeling van processen.

[Verwijderd]

Als ik het goed begrijp kan met dit protocol meerdere aanvragen tegelijk worden afgehandeld.

Voor zover ik weet lopen over je kabel de gegevens in pakketjes achter elkaar, dit kunnen wel pakketjes zijn van verschillende aanvragen.

Willen ze met dit protocol dan die pakketjes bij elkaar gooien of niet??
Als ze toch achter elkaar aan blijven lopen, dan zie ik niet waar de winst op dit punt ligt!

[Richard]

Het protocol zal Order-based Deadlock Prevention Protocol with Parallel Requests gaan heten. Deze hele mond vol tekst is gebaseerd op een algoritme dat een parallelle methode gebruikt om aanvragen te verwerken, iets wat nu nog serieel geschiedt.

Mmmmm, HDD's gaan juist naar Serieel toe, terwijl dit protocol juist weer naar Parallel toegaat, ik snap het even niet meer.

[ACM]

Dat komt vooral ook omdat een HDD veeel dichter bij de cpu zit en daardoor "simpelheid boven breedte" kan gaan wat performance betreft.
Een serieel kanaal is in principe veel simpeler (geen gedoe met 32 verschillende kabeltjes die allemaal tegelijk hun signaal aan moeten laten komen) dan een parallell kanaal en door dat soort vereenvoudigingen zou sAta een stuk sneller kunnen worden dan gewoon Ata.

Bij websites bezoeken ligt het even wat anders, daar praten we niet over micro/nanoseconden maar over milliseconden, nogal een paar duizend tallen verschil. In die paar milliseconde kan je veel berekeningen en controles doen, ondanks dat je protocol veel complexer is. Een parallell protocol kan in zo'n geval dus juist wel beter werken. Want in principe geldt er "parallell is sneller" (maar dus met een grote voetnoot)

[bramseltje]

Om de een of andere reden denk ik niet dat jij met 4 gebruikers van jou HDD zit te leechen, tewijl je op een site als tweakers toch al gauw zo'n 50 requests naast elkaar hebt lopen.... Dus dat is iets meer parallel georienteerd dan HDD access.

Vlieger gaat niet helemaal op, je OS leest een aantal files (drivers ed) terwijl je zelf ook het nodige tegelijk doet (temp files van je internet, html tikken, een mailtje schrijven, enz). Dat zijn theoretisch ook wel een hoop parallele requests, maar het ging even om het voorbeeld

[Rafe]

Misschien omdat het internet meer profiteert van een paralelle afhandeling, terwijl HDs blijer zijn met serieel?

* 786562 Rafe

[Verwijderd]

Het komt op mij over, dat de prof een soort P2P achtige techniek gebruikt, niet 1 webserver gebruiken, maar alternatieven aanspreken. De grote vraag die dan bij mij opkomt: wie "weet" waar al die alternatieve meuk uithangt??? Een soort zoekmachine achtige structuur? Ga je dan niet veel tijd verliezen als zo'n ding erachter komt dat het alternatief de gevraagde informatie niet meer heeft???

Afwachten maar ...

[Verwijderd]

Dat niet alleen. Dat hij beweerd sneller informatie te kunnen presenteren dat geloof ik graag. Feit blijft echter dat hij voor deze snellere presentatie ook een gigantische resourcevergroting nodig heeft. En dus de netto internet-snelheid er echt niet op vooruit zal gaan.

[ACM]

Het kan wel voordeel hebben als hierdoor de routes op het internet een stuk korter worden.
Als de data die je opvraagt ineens grotendeels vlak bij de deur wordt gegenereerd, dan zal het wel flink kunnen schelen.
Maar domweg 10 ipv 1 connectie over al drukke routers sturen maakt het niet beter nee

Het lijkt me echter dat zo iemand ook niet dom is en vast iets handigs bedacht heeft ervoor
Het ZDNet artikel blinkt sowieso niet echt uit in duidelijkheid, het zou goed een protocol kunnen zijn voor enkel de intercommunicatie van web services, databases etc onderling ipv naar de gebruiker toe.

[Verwijderd]

van een artikel een aantal dagen terug kan ik mij herinneren dat P2P netwerken verboden zijn in Amerika... wel zielig voor de Amerikanen dat ze dan achter moeten blijven

[Verwijderd]

Zeg dan niks...

Dit gaat niet over P2P netwerken maar over het mogelijke gebruik van P2P "achtige" technieken...

[Palomar]

ik denk dat het vinden van een sneller protocol nog niet zo erg bijzonder is... het is alleen maar de vraag hoe je zoiets nieuws wil implementeren, als de hele wereld al tcp/ip heeft

[Paul C]

Misschien een server ontwikkelen die ze allebij paralel kan uitvoeren zodat tcp/ip verkeer door de ene helft en dat ODPPPR (dat krijg je als je de eerste letters achter elkaar zet ) door de andere helft afgehandeld word....

[Fairy]

©OD3PR

[tweakerbee]

Dat zal dan wel als ODP3R afgekort worden

[Verwijderd]

@ xtuv:

Het betreft hier toch allen een severside aanpassing
Dus dan zou het gewoon http bljiven of heb ik dit fout?

[vehpol]

Nee hoor, dit heb je helemaal goed.

[Verwijderd]

Is er dan wel aan gedacht dat iedere parrallelle stream een eigen dns-request maakt ...
Dit gebruikt kan worden voor DDOS attacks, met minder computers, zelfde effect ...
Het me eigenlijk doet denken aan DAP maar dan voor internetpagina's

Edit: Typo's

[Verwijderd]

Ik denk dat parrallele methode echt sneller is.

De vele tweakers gebruiken downloadversnellers, dat zijn proggies die een download versnellen door meerdere verbindingen te gebruiken ipv 1. Stel dat je een zeldzame Half-Life-mod (100+MB) moet downloaden. Als dat mod gehost is op trage servers (1mbit/s) en jouw ADSL kan tot 8mbit/s gaan. Dan kan je dus met het huidige serieel systeem, maar tegen die upload van de server downloaden, dus maar 1mbit/s. Maar met parallele systeem van downloadversnellers maakt je 8 verbindingen naar verschillende servers en mirrors. 8 * 1 mbit/s = 8mbit/s = je kan tegen je max snelheid gaan.

Met meerdere verbindingen kan men ook de backbone belasting verdelen, dus niet alles door 1 kabel en de rest zit te niksen.