---

Jeg har en server(A) og en klient(B), når de starter oprettes der en TCP
forbindelse mellem dem, A og B sender så beskeder til hinanden en gang i
mellem men det meste af tiden står de begge bare og venter. Hvad nu hvis A
og B sender til hinanden på samme tidspunkt så går der vel kage i det? Og
hvis det kan ske hvordan koordinere man så tingene så det undgås?

Delphi 7 og WinXP

Mvh
HK

---

hej der.......

Harald wrote:

> Jeg har en server(A) og en klient(B), når de starter oprettes der en TCP
> forbindelse mellem dem, A og B sender så beskeder til hinanden en gang i
> mellem men det meste af tiden står de begge bare og venter. Hvad nu hvis A
> og B sender til hinanden på samme tidspunkt så går der vel kage i det? Og
> hvis det kan ske hvordan koordinere man så tingene så det undgås?
>

Da all transmision foregaar i pakker, og der da der kun kan være en pakke paa
kablet ad gangen, vil dette aldrig kunne forekomme. og dog,..... hvis du
bruger 10mb hub, kan du se at der formegntlig sider en lampe paa, som heder
colision. hvis den lyser har der været en kolision, men det skal du ikke
bekymre dig om, da pakken bliver retransmiteret, og alt dette foregaar
automatisk.

/Finn

>
> Delphi 7 og WinXP
>
> Mvh
> HK

---

"Finn Bindeballe" <finnb@post6.tele.dk> skrev i en meddelelse
news:3E75784B.91D4B778@post6.tele.dk...
> hej der.......
>
> Harald wrote:
>
> > Jeg har en server(A) og en klient(B), når de starter oprettes der en TCP
> > forbindelse mellem dem, A og B sender så beskeder til hinanden en gang i
> > mellem men det meste af tiden står de begge bare og venter. Hvad nu hvis
A
> > og B sender til hinanden på samme tidspunkt så går der vel kage i det?
Og
> > hvis det kan ske hvordan koordinere man så tingene så det undgås?
> >
>
> Da all transmision foregaar i pakker, og der da der kun kan være en pakke
paa
> kablet ad gangen, vil dette aldrig kunne forekomme. og dog,..... hvis du
> bruger 10mb hub, kan du se at der formegntlig sider en lampe paa, som
heder
> colision. hvis den lyser har der været en kolision, men det skal du ikke
> bekymre dig om, da pakken bliver retransmiteret, og alt dette foregaar
> automatisk.

Ok, men hvis nu A sender en større mængde data til B (dvs. mange pakker) der
måske tager 10 sekunder at overføre, så efter 5 sekunder sender B en besked
til A det duer vel ikke, her skal B vel vente på at A er færdig med at sende
alt, dvs. at A på en eller anden måde skal fortælle B at nu er jeg færdig
men hvordan gør man det smartest?

Mvh
HK

---

> hej der

>
> Ok, men hvis nu A sender en større mængde data til B (dvs. mange pakker) der
> måske tager 10 sekunder at overføre, så efter 5 sekunder sender B en besked
> til A det duer vel ikke, her skal B vel vente på at A er færdig med at sende
> alt, dvs. at A på en eller anden måde skal fortælle B at nu er jeg færdig
> men hvordan gør man det smartest?

tjaa.....hvis du mener at det er et logik-problem i din app, saa kunne jeg
foreslaa at du naar din lange transmision, fra a til b var slut, lukker
forbindelsen ned fra a. Dette kan opsnappes som et disconnect-event hos b, som
saa kan gøre hvad der skal gøres. her feks, oprette en ny forbindelse til a, og
saa sende sine data og saa afbbryde. ligeledes vil a kunne se at en transmition
er slut ved at trappe disconnect eventet.....

den underliggende TCP-stack er ligeglad med om du sender i begge retninger
....paa samme tid....

/finn

---

"Finn Bindeballe" <finnb@post6.tele.dk> skrev i en meddelelse
news:3E75B799.356579F7@post6.tele.dk...
> > hej der
>
> >
> > Ok, men hvis nu A sender en større mængde data til B (dvs. mange pakker)
der
> > måske tager 10 sekunder at overføre, så efter 5 sekunder sender B en
besked
> > til A det duer vel ikke, her skal B vel vente på at A er færdig med at
sende
> > alt, dvs. at A på en eller anden måde skal fortælle B at nu er jeg
færdig
> > men hvordan gør man det smartest?
>
> tjaa.....hvis du mener at det er et logik-problem i din app, saa kunne jeg
> foreslaa at du naar din lange transmision, fra a til b var slut, lukker
> forbindelsen ned fra a. Dette kan opsnappes som et disconnect-event hos b,
som
> saa kan gøre hvad der skal gøres. her feks, oprette en ny forbindelse til
a, og
> saa sende sine data og saa afbbryde. ligeledes vil a kunne se at en
transmition
> er slut ved at trappe disconnect eventet.....
>
> den underliggende TCP-stack er ligeglad med om du sender i begge retninger
> ...paa samme tid....

Jeg havde en ide om at når A og B var startet op så oprettes der en TCP
forbindelse mellem dem og denne forbindelse holdes indtil en af maskinerne
slukkes (normalt slukkes A efter 16 timer mens B er tændt 24/7). Men det er
måske en bedere (almindelig) løsning at oprette/lukke TCP forbindelsen hver
gang der skal overføres data?

Mvh
HK

---

> Men det er
> måske en bedere (almindelig) løsning at oprette/lukke TCP forbindelsen
hver
> gang der skal overføres data?

Det mener jeg ikke det er. Dit problem kan løses ved at lade en
pakkestørrelse indgå i en "header" (en slags indholdsfortegnelse) på din
transmission.

I din header kunne du også inkludere et kontrol nummer, som dit
klient/server kigger efter for at sikre sig, at det nu er starten
af transmissionen, den har fået fat i.

Men du ville sikkert ikke kunne mærke forskel på hastigheden hvis du valgte
at lukke/åbne forbindelsen hver gang - jeg synes bare det andet er en bedre
løsning.

TCP/IP siges at være en såkaldt stream protokol - og fungerer dermed ikke
med pakker, der bliver sendt, men nærmere en strøm af data.

I det underliggende system bliver de sikkert delt op i portioner, men TCP/IP
protokollen har du garanti for, at modtageren modtager alle data og i den
rækkefølge de blev sendt - desuden har du garanti for at de når frem (med
mindre forbindelsen rent fysisk fejler noget selvfølgelig).

Du behøver ikke at tage hensyn til hvorvidt klient og server sender på samme
tid, da man typisk laver TCP/IP asynkront - dvs. uafhængigt af programmets
normale kørsel via. hældelser, der indtræffer når der sker noget på din
socket.

Skulle pakkerne støde sammen, sørger det underliggende system automatisk for
at gensende pakken - det eneste du oplever som programmør er en lille
ubemærkelig forsinkelse og et fald i transmissionsdata pr. sekundt, hvis du
laver statistik over sådan noget i dit program.

---

> hej der......

> Jeg havde en ide om at når A og B var startet op så oprettes der en TCP
> forbindelse mellem dem og denne forbindelse holdes indtil en af maskinerne
> slukkes (normalt slukkes A efter 16 timer mens B er tændt 24/7). Men det er
> måske en bedere (almindelig) løsning at oprette/lukke TCP forbindelsen hver
> gang der skal overføres data?
>

jeg vil absolut raade dig til at lukke forbindelsen, naar den ikke bruges
mere....... det er muligt at din server i teorien køre 24-7, og din client kun
køre 8 timer....men i praksis er det altid noget andet....

/finn

>
> Mvh
> HK

---

Harald wrote:
> Ok, men hvis nu A sender en større mængde data til B (dvs. mange pakker) der
> måske tager 10 sekunder at overføre, så efter 5 sekunder sender B en besked
> til A det duer vel ikke, her skal B vel vente på at A er færdig med at sende
> alt, dvs. at A på en eller anden måde skal fortælle B at nu er jeg færdig
> men hvordan gør man det smartest?

Det skal du slet ikke bekymre dig om. TCP protokollen indeholder
information omkring packet number og CRC check, så når du har modtaget
en stream, så kan du være 100% sikker på at stream'en er nøjagtigt kopi
af kilden. Til gengæld bruger TCP har et overhead på 26 bytes pr. pakke
i forhold til UDP (så vidt jeg husker), men her skal du så selv holde
styr på at stream'en er korrekt, dvs. selv udføre packet number check og
CRC check.

Med venlig hilsen,
René Jensen