mboost-dp1
unknown
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.. ;)
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.. ;)
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
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 :)
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.
Den nye protokol er sikkert lig WAV Vs. MP3.
Man skærer "unødig" information (CRC) etc fra.
#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
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
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.
Desuden bør man sørge for at implementeringen ikke forurenes af lukkede properitære udvidelser som kun nogen har gavn af.
#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.
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.
14#
Hehe, det er ikke altid man lige har tid til det, også må man lave nogle forudantagelser... Nogle bedre end andre.
Hehe, det er ikke altid man lige har tid til det, også må man lave nogle forudantagelser... Nogle bedre end andre.
#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
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
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.
hmm det kunne være jeg lige skulle genopfriske mit TCP/IP.
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 :)
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 :)
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.
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.
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.
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! :)
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! :)
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.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund