---

Hej alle

Vi kom til at diskutere et problem, og selv om vi fik et svar,
vil jeg gerne have det bekræftet. Konkret blev det udløst af at
nogen skulle sende et lille array over en TCP-forbindelse, og da
de lavede det i et loop der sendte en int ad gangen, opstod der
tvivl om om tallene ville ankomme i den rigtige rækkefølge.

Der er ingen tvivl om at en samlet forsendelse altid modtages
korrekt, men hvad med flere separate send-kommandoer? Bemærk at
forbindelsen åbnes én gang og ikke nedlægges igen før alle tal er
sendt.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospam@lundhansen.dk> writes:

> Vi kom til at diskutere et problem, og selv om vi fik et svar,
> vil jeg gerne have det bekræftet. Konkret blev det udløst af at
> nogen skulle sende et lille array over en TCP-forbindelse, og da
> de lavede det i et loop der sendte en int ad gangen, opstod der
> tvivl om om tallene ville ankomme i den rigtige rækkefølge.

TCP er en såkaldt pålidelige forbindelsesorienteret protokol. Der
arbejdes bl.a. med sekvensnumre for pakker (og et glidende sende- og
modtagelsesvindue), således at selvom to pakker modtages i modsat
rækkefølge af den, de er sendt i, så vil transportlaget sørge for at
ombytte disse to, så de kommer "ud i den anden ende" i den rigtige
rækkefølge.

--
J. Martin Petersen "Atter springer gnuerne ud i vandet..."

---

J. Martin Petersen skrev:

>TCP er en såkaldt pålidelige forbindelsesorienteret protokol.

Ja, det ved jeg godt.

>Der arbejdes bl.a. med sekvensnumre ...

Spørgsmålet er om disse sekvensnumre starter et nyt sted ved en
ny kommando på samme TCP-linje (som ikke nedlægges i
mellemtiden), eller om der køres med fortløbende nummerering af
alle pakker gennem en hel session selv om der overføres mange
forskellige elementer med hvert sit sæt af pakker.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Hej,

> J. Martin Petersen skrev:
>
>>TCP er en såkaldt pålidelige forbindelsesorienteret protokol.
>
> Ja, det ved jeg godt.
>
>>Der arbejdes bl.a. med sekvensnumre ...
>
> Spørgsmålet er om disse sekvensnumre starter et nyt sted ved en ny
> kommando på samme TCP-linje (som ikke nedlægges i mellemtiden), eller om
> der køres med fortløbende nummerering af alle pakker gennem en hel
> session selv om der overføres mange forskellige elementer med hvert sit
> sæt af pakker.

Når du opretter en tcp-forbindelse får du vel en garenti om at den data du
sender kommer frem på den øvre del af transportlaget i samme rækkefølge som
du sender data'en, også selvom det er mange små pakker.
Tilsvarende jeres eksempel er når du skriver i et terminalvindue på en
linuxserver(som ikke er localhost) at der ikke byttes om på rækkefølgen af
bogstaver i det du skriver (jeg har ihvertfald aldrig oplevet det og jeg
skriver monster hurtigt ;) ).

vh
Kim

---

Hej Bertel,

Bertel Lund Hansen wrote:
> >TCP er en såkaldt pålidelige forbindelsesorienteret protokol.
>
> Ja, det ved jeg godt.
>
> >Der arbejdes bl.a. med sekvensnumre ...
>
> Spørgsmålet er om disse sekvensnumre starter et nyt sted ved en
> ny kommando på samme TCP-linje (som ikke nedlægges i
> mellemtiden), eller om der køres med fortløbende nummerering af
> alle pakker gennem en hel session selv om der overføres mange
> forskellige elementer med hvert sit sæt af pakker.

TCP bruger faktisk bytes some sekvens nummer. Det vil sige at hvis du
laver en send af 2 byte efterfulgt af en anden send paa 2 byte, saa vil
tcp acknowlede dette som total 4 bytes.

Hvis du nu spoerge hvad sekvensnummeret er paa de pakker der sendes, saa
er det lidt svaert at svarre paa (se mit andet svar). Du kan have to
pakker med sekvensnummer 1 og 3, men du kan ogsaa have en med
sekvensnummer 1.

Martin

---

Bertel Lund Hansen <nospam@lundhansen.dk> wrote:
> Spørgsmålet er om disse sekvensnumre starter et nyt sted ved en
> ny kommando på samme TCP-linje (som ikke nedlægges i
> mellemtiden), eller om der køres med fortløbende nummerering af
> alle pakker gennem en hel session selv om der overføres mange
> forskellige elementer med hvert sit sæt af pakker.

Sekvensnumre styres (naturligvis) af operativsystemet, og gode
operativsystemer soerger for at de er uforudsigelige. Det hjaelper med
til at forhindre TCP connection hi-jacking.

Jeg haaber det besvarer dit spoergsmaal. Se evt. side 807 i TCP/IP
Illustrated Volume 2 for mere information.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

---

Alex Holst skrev:

>Sekvensnumre styres (naturligvis) af operativsystemet, og gode
>operativsystemer soerger for at de er uforudsigelige.

Er der virkelig slet ingen der forstår hvad jeg spørger om?

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospam@lundhansen.dk> writes:

> Alex Holst skrev:
>
> >Sekvensnumre styres (naturligvis) af operativsystemet, og gode
> >operativsystemer soerger for at de er uforudsigelige.
>
> Er der virkelig slet ingen der forstår hvad jeg spørger om?

TCP er en bytestrøm. Bytes bytter ikke plads i en bytestrøm.

--
J. Martin Petersen "Atter springer gnuerne ud i vandet..."

---

On Thu, 05 Sep 2002 17:52:32 +0200, Bertel Lund Hansen wrote:

> J. Martin Petersen skrev:
>
>>TCP er en såkaldt pålidelige forbindelsesorienteret protokol.
>
> Ja, det ved jeg godt.
>
>>Der arbejdes bl.a. med sekvensnumre ...
>
> Spørgsmålet er om disse sekvensnumre starter et nyt sted ved en ny
> kommando på samme TCP-linje (som ikke nedlægges i mellemtiden), eller
> om der køres med fortløbende nummerering af alle pakker gennem en hel
> session selv om der overføres mange forskellige elementer med hvert
> sit sæt af pakker.

For operativsystemet er det samme session, uanset om det er f.eks. en
telnet session, hvor du laver forskellige ting, så svaret må være at
sekvens numrene er stigende med pakke størrelsen for hver pakke.

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Hej,


Bertel Lund Hansen wrote:
> Der er ingen tvivl om at en samlet forsendelse altid modtages
> korrekt, men hvad med flere separate send-kommandoer? Bemærk at
> forbindelsen åbnes én gang og ikke nedlægges igen før alle tal er
> sendt.

I det givet tilfaelde er det maaske ikke saa vigtigt, men bemaerk at
selv om TCP garantere dig at alt hvad der kommer i frem i den anden ende
er uden fejl, huller og uden aendring af raekkefoelgen, saa er mange
send kommandoer ikke nogen god ide.

Under normale tilfaelde, vil TCP opdage at du kun skrev meget lidt data
(< MTU) i den foerste send kommando, og derfor vente yderligere 200ms, i
haabet om at du vil skrive noget mere, inden den sender pakken. I dit
tilfaelde har du jo nok skrevet hele arrayen inden de 200ms er gaaet,
saa maaske betyder det ikke saa meget.

Under alle omstaendigheder er det svaert at opnaa en god effektivitet
hvis man hele tiden sender paa den maade. Saml dine data i 1500 byte
blokke, og send dem naar de er klar.

Martin

---

Martin Djernaes skrev:

>er uden fejl, huller og uden aendring af raekkefoelgen, saa er mange
>send kommandoer ikke nogen god ide.

Måske ikke, men det besvarer ikke mit spørgsmål.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Hej,

Bertel Lund Hansen wrote:
> Martin Djernaes skrev:
>
> >er uden fejl, huller og uden aendring af raekkefoelgen, saa er mange
> >send kommandoer ikke nogen god ide.
>
> Måske ikke, men det besvarer ikke mit spørgsmål.

Nej det var jo besvarret - flere send kommandoer er underordnet.

Jeg er ikke sikker paa at du har formuleret dit spoergsmaal saa vi ved
vad du egentligt gerne vil vide.

Martin

---

Martin Djernaes skrev:

>Jeg er ikke sikker paa at du har formuleret dit spoergsmaal saa vi ved
>vad du egentligt gerne vil vide.

Her er en session:
0   TCP-handshake
1   Send <brev>
   Der sendes 17 pakker som nummereres fortløbende.
   De ankommer i tilfældig rækkefølge, men samles pænt af
   modtageren. Denne sending er afsluttet, men
   TCP-forbindelsen lukkes ikke ned.
2   Send <dagsorden> som før (10 pakker).
3   Send <madopskrift> som før (20 pakker).
4   Forbindelsen slagtes.

Antag at første sendings første pakke får nummer 101. Den sidste
i første sending får så nummer 117.

Spørgsmålet er så:
Får første pakke i anden sending så nummer 118 eller kunne den
f.eks. godt få nummer 3742?
Får første pakke i tredje sending så nummer 128 eller kunne den
f.eks. godt få nummer 9511?

Eller på en anden måde:
Kan det godt ske at modtageren giver madopskriften en logisk
placering før brevet? (eller i vores lille modelprogram: kan det
ske at det smukt sorterede array modtages i et array hvor tallene
står hulter til bulter?)

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Hej Bertel,

Bertel Lund Hansen wrote:
>
> >Jeg er ikke sikker paa at du har formuleret dit spoergsmaal saa vi ved
> >vad du egentligt gerne vil vide.
>
> Her er en session:
> 0 TCP-handshake
> 1 Send <brev>
> Der sendes 17 pakker som nummereres fortløbende.
> De ankommer i tilfældig rækkefølge, men samles pænt af
> modtageren. Denne sending er afsluttet, men
> TCP-forbindelsen lukkes ikke ned.
> 2 Send <dagsorden> som før (10 pakker).
> 3 Send <madopskrift> som før (20 pakker).
> 4 Forbindelsen slagtes.
>
> Antag at første sendings første pakke får nummer 101. Den sidste
> i første sending får så nummer 117.
>
> Spørgsmålet er så:
> Får første pakke i anden sending så nummer 118 eller kunne den
> f.eks. godt få nummer 3742?
> Får første pakke i tredje sending så nummer 128 eller kunne den
> f.eks. godt få nummer 9511?
>
> Eller på en anden måde:
> Kan det godt ske at modtageren giver madopskriften en logisk
> placering før brevet? (eller i vores lille modelprogram: kan det
> ske at det smukt sorterede array modtages i et array hvor tallene
> står hulter til bulter?)

Paa IP level kan pakkerne vaere "hulter til bulter", men TCP vil samle
dem og ikke levere dem til modtageren (programmet) foer den har et
stykke som har den korrekte raekkefoelge.

Faktisk foregaar det paa den maade, at TCP vaelger en tilfaeldigt
startvaerdi. Nar nu du sender data (et brev at lad os side 170 byte, en
dagsorden af 100 bytes og en madopskrift af 200 bytes), saa siger TCP -
her er en pakke som er 100 bytes lang. Start sekvens nummeret er
<tifaeldig>. TCP protokollen, paa modtager siden siger saa "tak for det,
send venligst <tilfaeldig>+100".

Saa som du ser, saa ved tcp intet om breve,dagsordener eller
madopskrifter. Den ved heller ikke noget om dine "send" kommandoer, da
alt bliver lavet om til en stroem - forestil dig en haveslange med en
tragt. Du kan fylde en jaevn stroem ind i tragten, eller smaa slatter.
Uanset hvordan du fylder data ind i den, kommer det ud i en jaevn stroem
i den anden ende (forudsat at der er nok vand/data til at fylde
slangens/nettets kapacitet).

Haaber at det hjalp.

Martin

---

Martin Djernaes skrev:

>Saa som du ser, saa ved tcp intet om breve,dagsordener eller
>madopskrifter. Den ved heller ikke noget om dine "send" kommandoer, da
>alt bliver lavet om til en stroem

Sammen med Jespers forklaring besvarer det mit spørgsmål (med
samme svar som vores lærer gav). Tak for hjælpen til alle.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Martin Djernaes <martin@djernaes.dk> wrote:

>Haaber at det hjalp.

Du burde skrive noget lign. til TCP afsnittet i FAQ'en - og jeg håber
du husker at du "skylder" os noget om MTU. Vi ved du kan ..

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund wrote:
>
> Martin Djernaes <martin@djernaes.dk> wrote:
>
> >Haaber at det hjalp.
>
> Du burde skrive noget lign. til TCP afsnittet i FAQ'en - og jeg håber
> du husker at du "skylder" os noget om MTU. Vi ved du kan ..

Skal nok, men ikke i den her weekend :)

Martin