TCP Nwetvaerk Synkronisering

Du kan vel aldrig være helt sikker på at de kommer frem til 2 forskellige modtager på samme tid, da det afhænger af afstand etc.

Men du kan sende dem afsted på samme tid, hvis du laver en ekstra tråd i dit program, og synkronisere dem, så kan du sende på samme tid.

Aah ja, mit forsoeg vil foregaa over et lille lokalt netvaerk med lige lange afstande osv. saa det er mere med at faa pakkerne sendt paa samme tid. Min tcp server er multithreaded men naar jeg sender sker det dog paa en enkel traad (applikationens main thread) via en for loop. Jeg har en traad for hver klient der er logget paa. Diss traade er asynkroniske i ojeblikket, og designet til at lytte til klienterne, tror du jeg kan bruge disse traade til ogsaa at sende pakker til mine klienter, hvis jeg synkroniserer dem? Eller skal jeg lave nye synkroniseret traade til at sende pakker med?

Tror ikke du kan få dem sendt ud hurtigere end ved en for loop i en enkelt tråd. Har du tjekket om der bruges buffering? Hvis det er lokalt netværk kan du måske kigge på multicasting, hvor kun en besked bliver send til en bestemt adresse som flere lytter efter.

Jeg har lagt maerke til at jeg bliver noedt til at lave et ophold ved hjaelp af Sleep() mellem pakkerne. Hvordan kan det vaere? Hvis ikke jeg klader Sleep() funktionen ender jeg med enten at TCP pakkerne aldrig ankommer eller at pakkerne ankommer i brudte pakker. Jeg kan ikke forstaa at det er noedvendig med denne forsinkelse mellem de sendte tcp pakker naar jeg er paa et lokalt netvaerk.

Hvad vil vaere bedst multicast eller bradcast naar det er samme LAN netvaerk og alle klienter skal modtage samme data paa (forhaabenligt) samme tid?

Du kan ikke sikre det helt, for pakkerne sendes jo én ad gangen. Og selvom de blev modtaget nøjagtig samtidig, så kan modtagerne have forskelligt load og håndtere dem på forskellig tid.
Pakker kan godt blive brudt op, for der er grænser for, hvor store pakkerne må være...det kan du ikke gøre noget ved. Du må bare have én eller anden måde at se om du har modtaget en fuld pakke, og hvis ikke så smide det, du har, i en buffer, som du tilføjer til.

Man kan godt lave en server, som kan håndtere mange samtidige brugere uden at den er multithreaded. Det gør du med non-blocking sockets og dermed kan man løse mange andre problemer (tråd synkronisering og andre tråd relaterede problemer).

Ok, der er aabenbart mange maader man kan goere dette paa. Lad mig beskrive opgaven og maaske vi kan finde den bedste model.

Opgaven.

Jeg har en real-time simulation jeg koerer paa 5-6 computere. De viser alle forskellige vinkler af samme virtuelle verden. Men naar skaermene bliver sat sammen bliver det til et stort billede. Det er derfor vigtigt at de alle er synkroniseret. Det er meget faa data som skal sendes i real-time. Det meste af tiden bliver der ikke sendt nogen data men der vil hoejst blive sendt et par floats for at rotere/flytte kamera og enkelte objekter osv. Saa maengden af data er forholdsvist lille.

Jeg har en TCP server som sender disse data over et lokalt netvaerk (LAN). Computerne staar ved siden af hinanden og harderfor en kort fysisk afstand til hinanden.

Kender i en model som passer perfekt til denne opgave?
Jeg ved ikke meget om netvaerk ud over det grundlaeggende. Jeg har ikke vaeret i stand til at lave en kommunikation med synkroniseret data endnu. Formegenligt fordi at jeg sender pakkerne en for en. Tror I at en non-blocking sockets kan vaere noeglen til at loese dette? Eller findes der en helt anden model der er bedre?

Tror ikke det kan løses på netværksniveauet.

Multiplayer computerspil løser typisk problemet på en af to forskellige måder. Den ene er at ekstrapolere, dvs. gætte, hvad værdien er på et "nuværende" tidspunkt før resultat bliver modtaget og så korrigere. Den anden er at vise resultat fra tidligere eksempelvis der hvor du sætter det hele sammen til et stort billede kan du vise hvordan det så ud fra 100ms siden. Så gør det ikke noget at en computer har en ping på 5ms og en anden på 80ms.

Links der måske kan være brugbare:
http://gafferongames.com/networking-for-game-programmers/
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Jeg er enig med Søren om at man typisk "forudser" hvordan verden vil se ud...hvis vi bevæger os fremad med 10 km. i timen, så må det betyde, at vi om et sekund er nået til punkt X,Y,Z.
Multiplayer spil sender typisk denne slags data med UDP istedet for TCP, fordi der er mindre latency...der skal ikke sendes svar på alle pakker, og taber man en pakke, så skidt med det, for der kommer en ny opdateret pakke meget snart.