networking in echtzeitapplikationen.

[netzwerker]

Wie wird das gehandhabt (z.B. in Spielen, Simulationen, etc.).

Wird eher ein Thread fürs Netzwerken benutzt oder funktioniert das (z.B. in Spielen) auch Seriel, also z.B. bei jedem Update einmal abzufragen was angekommen ist.

Kennt hier vll. einer Links zu guten Einsteigerartikeln in diese Richtung?

Grüße,
Netzwerker

[rapso]

das ist recht verschieden, die faule art ist einen blocking socket mit einem extra thread abfragen. eine einfacherere ist einfach in jedem durchlauf in dem man sich sonst vom netzwerkthread die daten rueber kopieren wuerde, diese einfach dierekt vom socket lesen (nur die menge die schon vorbereitet im buffer ist damit man nicht stallt). es gibt auch die moeglichkeit events zu registrieren, sodass man beim durchlauf der windows messages genau wie keyboard und mausevents, auch netzwerkevents bekommt (ist wohl die windows conformenste art und weise).

kommt am ende immer drauf an was du fuer anforderungen hast

[+fricky]

rapso schrieb:

die faule art ist einen blocking socket mit einem extra thread abfragen.
...
es gibt auch die moeglichkeit events zu registrieren...

im zusammenhang mit spieleprogrammierung taucht immer die sogenannte 'game loop' auf. hört sich für mich nach einfachstem polling an. wahrscheinlich wissen viele spielecoder noch nicht mal, dass es sowas wie multithreading überhaupt gibt.

[rapso]

+fricky schrieb:

rapso schrieb:

die faule art ist einen blocking socket mit einem extra thread abfragen.
...
es gibt auch die moeglichkeit events zu registrieren...

im zusammenhang mit spieleprogrammierung taucht immer die sogenannte 'game loop' auf. hört sich für mich nach einfachstem polling an. wahrscheinlich wissen viele spielecoder noch nicht mal, dass es sowas wie multithreading überhaupt gibt.

doch leider schon, aber das ist es auch schon gewesen mit dem wissen ueber threading, deswegen machen ja soviele den unnuetzen extra thread. der main thread muss dann an irgendeiner stelle vom netzwerkthread "polling" betreiben, statt direkt einmal den state vom socket abzufragen.

man hat dann:

OS-socket(-thread/process+buffer+state) <-> netzwerkthread auf spiel seite (mit buffer+state) <-> main thread

statt einfach nur

OS-socket(-thread/process+buffer+state) <->  main thread

das schafft latenz, threading overhead, unnuetzen speicherverbrauch und wer so programmiert, der hat sicher auf noch sync probleme ohne ende.

als ich mir damals nen Pentium dual socket rechner zusammensteckte, knallten die meisten spiele wegen netzwerk oder sound problemen weg (sound-thread haben auch viele 'spieleprogrammierer' die 'von threads gehoert' haben benutzt),
man muss nicht alles nutzen nur weil es moeglich ist es zu nutzen. wenn man es damals unter dos gemacht hatte, ueber interrputs, dann war es noch von nutzen. aber genau das macht heute der treiber.

[+fricky]

rapso schrieb:

+fricky schrieb:

rapso schrieb:

die faule art ist einen blocking socket mit einem extra thread abfragen.
...
es gibt auch die moeglichkeit events zu registrieren...

im zusammenhang mit spieleprogrammierung taucht immer die sogenannte 'game loop' auf. hört sich für mich nach einfachstem polling an. wahrscheinlich wissen viele spielecoder noch nicht mal, dass es sowas wie multithreading überhaupt gibt.

doch leider schon, aber das ist es auch schon gewesen mit dem wissen ueber threading, deswegen machen ja soviele den unnuetzen extra thread. der main thread muss dann an irgendeiner stelle vom netzwerkthread "polling" betreiben, statt direkt einmal den state vom socket abzufragen.

kommt drauf an. wenn der 'main'-thread eventgesteuert arbeitet, braucht er nichts zu pollen, sondern harrt seiner events (user-input, timer-tick, netzwerk, etc). also wie so'ne olle windoofs-fensterprozedur. polling auf 'nem multitasking-os ist immer doof, weils alles andere ausbremst. deswegen finde ich ja den begriff 'game loop' so blöd, weil der sich nach endlosschleife anhört, die pollt und zu 99% sinnlos cpu-cycles verbrennt.

[knivil]

Ja der Game loop ist ne Endlosschleife (prinzipiell). Auch macht ein Multithreaded game loop Sinn. Auch macht es Sinn, Networking in einen extra Thread auszulagern. Beispiel Daten werden nicht nur empfangen und gesendet, sondern auch fuer die weitere Verarbeitung aufbereitet oder fuer das Senden vorbereitet ...

Leider wollen die meisten Leute keine DOS-Spiele mehr spielen. 2 GHz Single Core reichen nicht mehr aus, so dass man alles moeglichst auf andere Prozessoren auslagert, was die FPS daempfen koennte.

[Andreas XXL]

knivil schrieb:

Ja der Game loop ist ne Endlosschleife (prinzipiell). Auch macht ein Multithreaded game loop Sinn. Auch macht es Sinn, Networking in einen extra Thread auszulagern. Beispiel Daten werden nicht nur empfangen und gesendet, sondern auch fuer die weitere Verarbeitung aufbereitet oder fuer das Senden vorbereitet ...

Leider wollen die meisten Leute keine DOS-Spiele mehr spielen. 2 GHz Single Core reichen nicht mehr aus, so dass man alles moeglichst auf andere Prozessoren auslagert, was die FPS daempfen koennte.

Was soll man bei einem Spiel großartig in andere Treads auslagern?

Sound, Netzwerkkommunikation ?
Das macht doch höchstens 1% der Last aus.
CPU Gegner? Gute Idee, aber die meisten wollen doch eh im Internet zocken und nicht gegen KIs.
Die heutigen Spiele sind eh Grafiklimitiert.

Es macht wenig Sinn überhaupt was auszulagern. Daher bring (vor allem für Spiele) mehr als 2 CPUs eh nix. (Egal was Intel und NVIDIA schreiben).
Die stecken eh in einer Sinnkriese. Was soll man wenn man zocken will mit mehr als 2 CPUs? Strom verbraten! Kauft euch lieber eine gute 2 Core CPU als eine 4er bei der jeder Kern etwas langsammer ist als bei der 2er.

Man muß sich mal überlegen, das eine Grafikkarte mitlerweile fast 100 mal schneller ist als eine "normale" CPU. Mit den aufkommenden Möglichkeiten direkt dort drauf Allgemeines zu rechnen wird Intel bald der Angstschweiß auf der Stirn stehen.
Das beste ist, die Verwaltung der Threads (bis 1000 Stück) geht in Hardware.
Das ist so schnell, das es sich auf einer Grafikkarte lohnt ein Array mit 1000 Elementen mit 1000 einzelnen Threads zu berechnen.
Versuch das mal mitz einer CPU. Die ist erst mal 5 Sekunden
(etwas übertrieben) damit beschäftigt die Threads zu erstellen .

Fazit: Ich kenne kein einziges Spiel welches nicht mit einer Single Core auskommt. Und das wird auch erst mal so bleiben.

[Badestrand]

Andreas XXL schrieb:

CPU Gegner? Gute Idee, aber die meisten wollen doch eh im Internet zocken und nicht gegen KIs.

Benötigt die KI idR nicht sogar am meisten CPU-Zeit? (Soll jetzt kein Widerspruch zu deiner Aussage sein, nur allgemein.)