[Decibel]

skulle vara kul att se hur en tcp-ack ser ut på servern om den får 5 olika ipnummer som vill ha olika delar av samma fil, rent tekniskt är det omöjligt.
Det går med mycket trixande och lastbalancering, dock inte på en och samma fil.

[faldo]

Originally posted by Decibel@Mar 19 2004, 18:47
skulle vara kul att se hur en tcp-ack ser ut på servern om den får 5 olika ipnummer som vill ha olika delar av samma fil, rent tekniskt är det omöjligt.
Det går med mycket trixande och lastbalancering, dock inte på en och samma fil.

Winroute gämför självklart paketen i realtid med varandra... annars skulle de inte funka, de har du rätt i.

När du skicar en fil via TCP/IP så klipper protokollet filen i små paket... om du väljer att inte ta emot de sista 50% av ett paket skulle filen inte kunna gå att återställa på andra sidan sladden, men om du redan har de sista 50% (vilket iofs. inte kommer i en klump) så kan du återskapa filen med de som saknas.

För att förklara exakt vad som händer så laddar IP nr1 ner första paketet, samtidigt som de 4 resterande dirigerar bort paket 2, 3 och 4... samtidite som IP nr2 dirigerar bort paket 2 så laddar den ner paket nr 5... osv...

[Robert]

Saxat från en annan källa:

"Enligt en källa på BBB är de i 99% av alla fall låst till 10Mbit i switchen. De kan någonstans finnas en gammal ännu ej utbytt rackare som skulle kunna möjligöra detta, men de lär nog tämligen raskt försvinna. "

...

[entreprenör]

Jag trodde ju detta var låst hårdvarumässigt via switchen.
Det enda man kan göra är att köra med 2 portar och koppla dessa samman och då få tex 20mbit.
Är porten låst till 10mbit så är det ju så, spelar ju ingen roll vilket protokoll man använder så länge porten är låst.

Men men, funkar det för er som testat så är det väl så.

[gabriel]

Ursprungligen postat av faldo

Ja tror ni har missuppfattar hur de hela fungerar...

På winroute datorn få finns de 6 näterkskort (en som går ut i de NATade nätverket till en dator), med 5 olika IP nummer från BBB, så långt fattar nog alla.
När sedan en datorn (som winroute har NATat) skickar en d/l förfrågan till en server på internt så skickar Winroute denna förfrågan via ALLA 5 ip adresserna... Precis som om 5 datorer (utan Winroute, med 5 olika ip nummer) skulle skicka var sin förfrågan till samma server om att ladda ner samma fil. Såhär långt tror jag oxå alla fattar...
Om de nu i själva verket VAR 5 datorer så skickas alla TCP/IP paketen separat, för detta behövs inget speciellt protokoll, eller hur?

Vad Winroute gör, är att kombinera de 5 olika IP adresserna å skickar exakt samma d/l förfrågan till servern (så servern märker ingen skillnad)... men när paketen går förbi Winroute för att routas ut till den dator som förfrågade, så läggs paketen ihop, med hjälp av "Advanced NAT" (precis på samma sätt som GetRight Download manager lägger ihop paket) och kombinerar paketen som skickas vidare till en NATad IP adress...

För att bevisa att man kan lägga ihop TCP/IP paket (där Gabriel tyckte motsatsen) så föreslår jag att ni laddar ner GetRight Download Manager så får ni se att de inte alls behöver något speciellt protokoll (förutom de funktioner som finns i programmet på klientsidan). GetRight är byggt för att ladda ner samma fil från olika servrar å på de viset snabba upp hastigheten... men där förfrågar man nerladdningen med endast en IP adress, så då kan du bara uppnå maxhastigheten på en IP adress.

Jag vet inte hur ja ska förklara tydligare :unsure:

jag tror du blandar ihop tcp protokol och exempelvis http protokol...

för det spelar ju ingen roll för hastigheten om båda börjar ladda ner samma fil samtidigt utan du får ju se till att dom börjar på olika ställen för att det skall fungera...

[Marcus]

Det flera nämner som något som måste "stödjas av tcp-protokollet" är ju i själva verket något annat. Det som det behöver finnas stöd för är precis som gabriel skriver här i inlägget innan mig att möjligheten för att ladda ner från olika delar av filen (även användt vid s.k. "Resume" vid nedladdning med ftp-klient från en FTP-server). Finns det inte stöd för att "resuma" en fil vid nedladdning från ftp-servern så fungerar det ni beskriver rimligtvis inte heller. Rent protokollmässigt (på protokollnivå) är detta inget problem. Däremot måste t.ex. FTP-servern som -skickar iväg- datan kunna påbörja sin "ivägskickning" från en viss offset i filen.

Saknas stöd för resume, bör det dock fortfarande inte vara något problem att ansluta och starta nedladdningar av olika filer. Om det inte finns specifika samtidiga användare/ip-begränsningar som sätter stopp, men det har ju inte med det här att göra egentligen.

Att 5 olika "ip-adresser" startar nedladdningar samtidigt gör ju i sig inte att man får en "ökad överföringshastighet" (med avseende på en enskild fil) om det skulle vara så att de laddar ner exakt samma data. Även om den -totala- överföringshastigheten (utan avseende på vad som överförs) är högre så får man ju inte över en enskild fil snabbare om samma data överförs över alla anslutningar. Det hela bygger ju på att de "olika ip-adresserna" (med låt säga 10Mbit var) laddar ner -olika delar- av filen samtidigt och filen sedans "slås ihop" till en och samma. Skulle de istället allihopa börja t.ex. från början på filen och ladda ner med exakt samma hastighet skulle de ju samtidigt få ner exakt samma data (och bara resultera i 5 likadana kopior) och det finns därmed inget att "slå ihop".

[faldo]

Originally posted by desdecado@Mar 19 2004, 20:39
Saxat från en annan källa:

"Enligt en källa på BBB är de i 99% av alla fall låst till 10Mbit i switchen. De kan någonstans finnas en gammal ännu ej utbytt rackare som skulle kunna möjligöra detta, men de lär nog tämligen raskt försvinna. "

...

Näe du... ja tror inte BBB har i avsikt att göra reklam för denna "möjlighet"

[faldo]

Originally posted by gabriel@Mar 20 2004, 11:38
jag tror du blandar ihop tcp protokol och exempelvis http protokol...

för det spelar ju ingen roll för hastigheten om båda börjar ladda ner samma fil samtidigt utan du får ju se till att dom börjar på olika ställen för att det skall fungera...

Näe... Http, Ftp, p2p... alla dessa protokollen baseras på TCP/IP protokollet.
När vi snackar om http, ftp osv. så är vi inne på applications nivå, där de måste finnas en server och en klient som stödjer de gemensamma protokollet...
Jag pratar om renodlat TCP/IP, grunden för alla "överliggande" protokoll, själva överföringen från nätverkskort till nätverkskort.

Om båda IP adresserna laddarn ner samma fil från 1% till 100% så vinner man såklart ingen hastighet på de... men som jag förklarade tidigare så kan man med hjälp av "resume-funktionen" som Marcus så fint påpekade, och som i de flesta fall är möjligt om man inte valt att stänga av funktionen (med obegripligt skäl), välja att visa för servern vilka paket du har å vilka du behöver.

De ja försökte förklara förut, missuppfattades tror jag:
För att vinna på att ladda ner med 5 IP adresser så måste man självklart ladda ner olika delar, samtidigt. Så långt e alla med.
För att göra detta kan vi ta ett praktiskt exempel med olika tids-steg på en extremt liten fil som endast blir 10st paket.

Steg 1
Tid 00:01: IP nr 1 laddar ner paket nr1
Tid 00:01: IP nr 2 hoppar över paket nr1 samtidigt som den laddar ner paket nr2
Tid 00:01: IP nr 3 hoppar över paket nr1 och 2 samtidigt som den laddar ner paket nr3
Tid 00:01: IP nr 4 hoppar över paket nr1, 2 och 3 samtidigt som den laddar ner paket nr4
Tid 00:01: IP nr 5 hoppar över paket nr1, 2, 3 och 4 samtidigt som den laddar ner paket nr5

Steg 2
Tid 00:02: IP nr 1 laddar ner paket nr6
Tid 00:02: IP nr 2 hoppar över paket nr6 samtidigt som den laddar ner paket nr7
Tid 00:02: IP nr 3 hoppar över paket nr6 och 7 samtidigt som den laddar ner paket nr8
Tid 00:02: IP nr 4 hoppar över paket nr6, 7 och 8 samtidigt som den laddar ner paket nr9
Tid 00:02: IP nr 5 hoppar över paket nr6, 7, 8 och 9 samtidigt som den laddar ner paket nr10

...så har vi laddat ner 10 paket i 2 steg... som för en IP adress skulle ta de i 10 steg, detta kallas i fackliga termer för "elefantgång" (fråga mig inte varför, heh)

Där ja skriver "hoppar över paket" så väljer helt enkelt WinRoute att avvisa paketet.

[gabriel]

oki...
men borde inte servern som skickar ut skiten till winroute börja undra varför den nekade de första paketen men vill ha de kommande?

[faldo]

Originally posted by gabriel@Mar 20 2004, 15:36
oki...
men borde inte servern som skickar ut skiten till winroute börja undra varför den nekade de första paketen men vill ha de kommande?

Winroute nekar ingenting... gör den de går paketet tillbaka till servern å skickas igen, eller om du inte får paket 5 efter paket 4 så händer samma sak (sk. packetloss).

Winroute "tappar" de paketen som inte ska laddas ner med flit när dom kommer fram så att den IP adressen kan koncentrera sig på att ladda ner ett annat paket.