mboost-dp1

unknown

Fast TCP – den nye sprinterprotokol

- Via NewScientist - , redigeret af Pernicious

California Institute of Technology, Caltech, er langt fremme i skoene med deres “Fast TCP” protokol, der er en kraftig optimering i forhold til almindelig TCP.

Teknologien er tidligere testet, og har bevist sin ydeevne. Den store fordel ved denne ændring af TCP-protokollen er, at da pakke- størrelserne er de samme, skal der ikke meget hardwareopgradering til for at udnytte teknologien. Det er i princippet kun nødvendigt at ændre softwaren og hardwaren, på computeren der sender data.

Det er lykkedes at opnå forbedringer på over 300% med Caltechs nye protokol.





Gå til bund
Gravatar #1 - ESKIMO
7. jun. 2003 08:35
Vildt nok...
Gravatar #2 - sKIDROw
7. jun. 2003 08:40
Det lyder jo spændende.. :)
Håber de får en passende belønning.
Og så håber jeg den bliver lanceret med en passende licens, helst GPL* men ellers kan BSD licensen vel også gå an.

* Dette ville eliminere lukkede videreudviklinger/udvidelser, som vi ikke allesammen kunne bruge.. ;)
Gravatar #3 - BloodShed
7. jun. 2003 08:46
Me thinks det vil reducere lag i spill fremover :D
Gravatar #4 - funkymonkey
7. jun. 2003 08:47
jeg kunne ikke se noget i artiklen om det blivet noget lukket protocol, bortset fra det så lyder det lovende. gad vide hvordan det vil påvirke priserne og hvornår det bliver færdigt
Gravatar #5 - Infophreak
7. jun. 2003 09:42
Det tog dem også kun 30 år at finde på noget, der (muligvis - lad os nu se, om det bliver frit tilgægeligt for ALLE at bruge) er bedre end det nogle offentligt lønnede forskere fandt på i 60'erne. De kunne altså et eller andet dengang :)
Gravatar #6 - Tomcat
7. jun. 2003 09:43
Gad vide hvad de har mådte skære fra den gamle TCP protokol, for at opnå de 300%

Den nye protokol er sikkert lig WAV Vs. MP3.
Man skærer "unødig" information (CRC) etc fra.
Gravatar #7 - Jaxe
7. jun. 2003 10:02
#6 - De har jo ikke skåret noget væk fra protokollen, sådan som jeg læser det sender de simplethen bare pakkerne hurtigere efter hinanden.

Den nuværende protokol halvere sende hastigheden hver gang den ikke for svar pakken. Fast TCP vil med software/hardware se længere frem, og hvis der er "klar bane" booste hastigheden. Dermed opnår de en fordel over TCP
Gravatar #8 - Tomcat
7. jun. 2003 10:15
7#
Tak for infoen, havde ikke lige læst artiklen.
Gravatar #9 - MNM
7. jun. 2003 10:43
#6
Der er ikke noget unødigt i TCP protokolen og CRC er da meget vigtigt
Gravatar #10 - Gathond
7. jun. 2003 12:20
#9, CRC er så iirc ikke lige implementeret i TCP eller IP protocollen men som regel på MAC eller datalink laget. TCP sikrer derimod i modsætning til IP at alle pakkerne når frem (ved at gensende de pakker der ikke er blevet kvitteret for modtagelsen af).
Gravatar #11 - sKIDROw
7. jun. 2003 13:00
For mig er det allervigtigste bare at det bliver lanceret under en fri licens som alle har gavn af, og selvfølgelig FRI FOR NOGEN SOM HELST PATENTER!
Desuden bør man sørge for at implementeringen ikke forurenes af lukkede properitære udvidelser som kun nogen har gavn af.
Gravatar #12 - Tomcat
7. jun. 2003 13:08
9#
Netop. Det var derfor jeg lavede "" i unødigt, fordi det var ironisk ment
Gravatar #13 - SmackedFly
7. jun. 2003 13:29
#11

Nu lyder det som om det er en offentlig udviklingsinstans eller noget lignende, så jeg har på fornemmelsen at det bliver udsendt under BSD licensen. Eller skulle det være LGPL, det ku også være fair nok.
Gravatar #14 - Druid
7. jun. 2003 14:05
#8 Hvorfor kommentere en artikel hvis man ikke har læst den?
Gravatar #15 - Tomcat
7. jun. 2003 15:04
14#

Hehe, det er ikke altid man lige har tid til det, også må man lave nogle forudantagelser... Nogle bedre end andre.
Gravatar #16 - MNM
7. jun. 2003 15:28
#10
Både IP og TCP pakker har CRC/checksum. På IP pakker er checksumen kun på header'en men på TCP pakker er det checksum på hele pakken

lidt om TCP: http://www.scit.wlv.ac.uk/~jphb/comms/tcp.html
Gravatar #17 - dasbutt
7. jun. 2003 15:36
Nu har jeg jo selv lavet en protokol eller to så det er da sjovt at se. Jeg har ikke kigget så meget på TCP/IP, men skal den have en ACK tilbage for en pakke der er sendt før den sender den næste? Har man ikke med TCP et vindue med et antal acknowledge man kan have ude og "hænge" før man laver en re-transmit? For så burde det vel bare være et spørgsmål om at have det vindue stort nok?
hmm det kunne være jeg lige skulle genopfriske mit TCP/IP.
Gravatar #18 - mdj
7. jun. 2003 16:57
Af hvad jeg kan forstå på artiklen, så er det ikke selve opbygningen af pakkerne der er ændret så meget, men i stedet den måde som windowing foregår på. Normalt så bliver der hele tiden forhandlet om hvor mange pakker som der må være ubekræftet mellem modtagerne, hvis en pakke så ikke når frem, forhandler parterne så igen hvor mange pakker der må sendes uden bekræftelse, osv... Som jeg ser det, så har de "bare" gjort denne funktion mere tolerant.

kommentar til dasbutt: Du har helt ret, det er sådan set hvad de har ændret, jeg så bare ikke dit indlæg før jeg skrev mit eget :)
Gravatar #19 - Gathond
7. jun. 2003 17:13
#16, damn du har ret .. huskede båre IP og TCP som kun havende CRC på headeren, hvad jeg ikke regnede med var relavant i denne sammenhæng.
Gravatar #20 - Mukke
7. jun. 2003 20:05
Fedt... Hvori er det lige det helt vilde består?

Det eneste de gør er at tweake flow control indstillinger (f.eks. sliding window-størrelse).

Jeg kan da også godt lave en Mukke-tcp og vise den klarer sig 500% bedre end ordinær tcp, hvis jeg selv kan bestemme hvilke forhold det skal testes under.

Det her er vidst en af den slags historier som man hører en enkelt gang og aldrig ser mere til.
Gravatar #21 - Yasw
8. jun. 2003 13:55
Hvis man skulle forbedre sendehastigheden, så er det som jeg ser det pakkekolisioner man bør kigge på. Med de store hastighedder vi har i dag sker det ofte at pakker koliderer og skal derfor sendes igen. Hvis man nu fik gjort noget ved det problem, kunne hastighederne for alvor optimeres.
Gravatar #22 - seahawk
10. jun. 2003 07:53
Synes lige det bør nævnes(Da ingen andre har gjort det), at denne optimering INGEN forskel vil gøre på folks adsl eller deres lokalnet.

Det er for at kompensere for problemer på HURIGE linier med høj latency man roder med denne ændring, da TCP protokollen ikke opfører sig specielt hensigtsmæssigt sådanne steder(Tænk kabler over atlanten)

#20:

Sæt dig ind i hvad artiklen drejer sig om - der ER et problem med TCP protokollen som den er idag - dette lille fix klarer det problem på en ganske simpel måde! :)
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login