Client-Server-Programmierung

[Asmodeus]

Angenommen, mehrere Clients haben sich mit einem Server verbunden und kommunizieren über herkömmliche Sockets miteinander (unter Windows mit winsock). Nun möchte ich vom Server aus an alle Clients gleichzeitig eine Zeichenkette verschicken. Gibt es eine Möglichkeit, diese Zeichenkette wirklich gleichzeitig an alle zu verschicken, oder kann ich die Nachricht nur iterativ nacheinander an alle Clients verschicken?

Gruss, Carsten.

[Gast]

Du könntest immer wenn ein neuer Client eine Verbindung zum Server aufbaut, einen neuen Thread für diesen starten. Willst du dann eine Nachricht an alle versenden, liesse sich das so auch (fast) gleichzeitig machen, Threads sind nie _wirklich_ simultan ...

[Demirug]

Du könntest immer wenn ein neuer Client eine Verbindung zum Server aufbaut, einen neuen Thread für diesen starten. Willst du dann eine Nachricht an alle versenden, liesse sich das so auch (fast) gleichzeitig machen, Threads sind nie _wirklich_ simultan ...

Schlechte Idee. Ein Thread pro Client skaliert nicht gut. Musste ich selbst schon feststellen.

Asmodeus, wenn du im lokalen LAN bist (gleiches Subnetz) geht sowas auch mit Broadcasts. Ansonsten wo ist das Problem die Sockets in einer Schleife zu durchlaufen?

[grakaman]

Zumal wenn die Kommunikation übers Internet ist, wird man eh nicht garantieren können, dass alle teilnehmenden Clients dann die Nachricht zur exakt selben Zeit empfangen, sprich dass die Übertragungsdauer/weg der selbe ist.

[noid]

Schlechte Idee. Ein Thread pro Client skaliert nicht gut. Musste ich selbst schon feststellen.

Asmodeus, wenn du im lokalen LAN bist (gleiches Subnetz) geht sowas auch mit Broadcasts. Ansonsten wo ist das Problem die Sockets in einer Schleife zu durchlaufen?

auch nicht bei preallocated threads?

irgendwie schade...

[Demirug]

auch nicht bei preallocated threads?

irgendwie schade...

Sobald du eine Situation kommst in der deine Anwendung mehr Threads aktiv nutzt als CPU Kerne da sind kommt es zu einem Leistungsverlust durch die zusätzlichen Threadwechsel. Vorallem wenn dabei noch IO ins spiel kommt was bei Netzwerk Sachen ja der Fall ist.

[Asmodeus]

Schlechte Idee. Ein Thread pro Client skaliert nicht gut. Musste ich selbst schon feststellen.

Asmodeus, wenn du im lokalen LAN bist (gleiches Subnetz) geht sowas auch mit Broadcasts. Ansonsten wo ist das Problem die Sockets in einer Schleife zu durchlaufen?

Hmm, ist ne gute Idee, die in Frage kommenden Rechner können auch alle ins gleiche Subnetz übernommen werden und dann werd ich die Sache mit Broadcast mal testen.

Das Problem ist halt die Anforderung der Anwendung an sich. 8 Rechner (Clients) sollen Ihre Ausgabe absolut synchron mit Überlappungsbereich auf 8 Beamer ausgeben. Gesteuert wird das ganze von einem 9. Rechner (Server). Und da für Hardware-Synchronisation (Genlock, Framelock o.ä.) kein Geld da war soll die Synchronisation eben über Sockets laufen. Und nun hatte ich die Befürchtung, dass bei einem Schleifendurchlauf die Zeitdifferenz zwischen Refresh des 1. Clients und dem Refresh des letzten Clients vielleicht so groß sein könnte, dass man es bei der Ausgabe sieht.

Gruss, Carsten.

[Demirug]

Ohne syncronen VSync wird das aber nicht wirklich funktionieren.

Zudem würde ich den Swap auch nicht beim Empfang des Signals durchführen. Die LAufzeiten sind selbst bei einem Broadcast nicht syncron genug. Als erstes würde ich dafür sorgen das die Uhren der 8 Rechner syncron laufen und dann via Broadcast den Umschaltzzeitpunkt versenden. Damit bekommt man zumindestens das Laufzeitproblem in den Griff.

[Asmodeus]

Als erstes würde ich dafür sorgen das die Uhren der 8 Rechner syncron laufen und dann via Broadcast den Umschaltzzeitpunkt versenden. ...

Hmm, mit welchen Mitteln kann man die Uhren von 8 PCs im Millisekundenbereich synchronisieren?

Momentan habe ich folgende Beobachtung gemacht: Bei einer einfachen darzustellenden Szene, bei der die Clientrechner (sowohl CPU als auch GPU) wenig zu tun haben läuft die ganze Sache für das menschliche Auge absolut synchron. Aber bei komplexen Szenen (CPU und GPU der Clientrechner voll belastet) treten die Unsynchronitäten auf. Das Senden der Messages vom Server an alle 8 Clients dauert < 1 Millisekunde. Also kann es bei komplexen Szenen fast nur daran liegen, dass die Messages zu den 8 Clients unterschiedliche lange unterwegs sind (aber müsste die Unsynchronität dann nicht auch bei einfachen Szenen auftreten?) oder die Clients unter Volllast irgendwie unterschiedlich lange brauchen um im "Socketmanagement" die Messages entgegenzunehmen und dem Programm zur Verfügung zu stellen?
Auch die Umstellung der Sockets auf (TCP_NODELAY) konnte das Problem nicht lösen.

Hat jemand noch einen Lösungsvorschlag oder Begründungen, wieso es bei komplexen Szenen so nicht funktionieren kann?

Gruss, Carsten.

[Demirug]

Hmm, mit welchen Mitteln kann man die Uhren von 8 PCs im Millisekundenbereich synchronisieren?

Ich würde es mal mit den üblichen Zeitserver und Syncronisationprotokolen versuchen. Ansonsten vielleicht ein paar billige Funkuhr empfänger benutzten.

Momentan habe ich folgende Beobachtung gemacht: Bei einer einfachen darzustellenden Szene, bei der die Clientrechner (sowohl CPU als auch GPU) wenig zu tun haben läuft die ganze Sache für das menschliche Auge absolut synchron. Aber bei komplexen Szenen (CPU und GPU der Clientrechner voll belastet) treten die Unsynchronitäten auf. Das Senden der Messages vom Server an alle 8 Clients dauert < 1 Millisekunde. Also kann es bei komplexen Szenen fast nur daran liegen, dass die Messages zu den 8 Clients unterschiedliche lange unterwegs sind (aber müsste die Unsynchronität dann nicht auch bei einfachen Szenen auftreten?) oder die Clients unter Volllast irgendwie unterschiedlich lange brauchen um im "Socketmanagement" die Messages entgegenzunehmen und dem Programm zur Verfügung zu stellen?
Auch die Umstellung der Sockets auf (TCP_NODELAY) konnte das Problem nicht lösen.

Hat jemand noch einen Lösungsvorschlag oder Begründungen, wieso es bei komplexen Szenen so nicht funktionieren kann?

Gruss, Carsten.

Eine CPU unter Volllast kann natürlich zum verzögerten Empfang führen aber ich habe da noch eine andere Idee.

Nutzt ihr einen doppelte Handshake oder nur einen einfachen?

Was ich damit meine ist ob der Master die Umschaltmeldung einfach rausschickt oder vorher eine "Ready" Meldung von allen Clients abwartet? Ohne diese Ready meldung kann es nämlich passieren das die GPU noch an dem Frame rendert dann man gerade anzeigen möchte.

[Asmodeus]

Ich würde es mal mit den üblichen Zeitserver und Syncronisationprotokolen versuchen. Ansonsten vielleicht ein paar billige Funkuhr empfänger benutzten.



Eine CPU unter Volllast kann natürlich zum verzögerten Empfang führen aber ich habe da noch eine andere Idee.

Nutzt ihr einen doppelte Handshake oder nur einen einfachen?

Was ich damit meine ist ob der Master die Umschaltmeldung einfach rausschickt oder vorher eine "Ready" Meldung von allen Clients abwartet? Ohne diese Ready meldung kann es nämlich passieren das die GPU noch an dem Frame rendert dann man gerade anzeigen möchte.

Nein nein, der Server wartet bis alle Clients ihr "Ready" geschickt haben und sendet dann erst die Umschaltmeldung.

EDIT: Wobei die Frage vielleicht auch ist, wann ist ein Client wirklich "Ready" also wirklich fertig mit dem Zeichnen eines Bildes? Reicht es dafür, wenn man unter OpenGL nach dem Aufruf aller Zeichenroutinen glFlush/glFinish aufruft und dann das "Ready" sendet, oder besteht die Möglichkeit, dass gerade bei sehr komplexen Szenen der Treiber und die GPU dann immer noch "an etwas arbeiten" und dann plötzlich der Client die Umschaltmeldung bekommt, die CPU den Swapbuffer auslöst und dadurch dann etwas "durcheinander kommt". Bei NV-Quadrotreibern gibt es ja z.B. auch die Treibereinstellung, an wie vielen Frames die GPU schon im Voraus arbeiten soll, wenn ich mich nicht irre. Könnte es mit so einer internen Sache auch zu tun haben?

Gruss, Carsten.

[Asmodeus]

Puh, kleiner Fehler, große Wirkung. Ich hatte TCP_NODELAY zwar als Socketoption gesetzt, aber nicht noch mal überprüft, ob die Sache auch wirklich übernommen wird. Und auf Grund eines Fehlers bei der Angabe des Parameterwertes war dem natürlich nicht so. :rolleyes: Aber egal, jetzt läuft die Sache schön synchron.

Wenn es interessiert, ich habe nochmal zwei Bilder gemacht:

Powerwall Vorderseite (http://www.inf.uni-konstanz.de/~colditz/Powerwall01.jpg)

Wer mal zufällig in Konstanz ist und sich die Sache mal ansehen will, schreibt mir einfach ne PN, das lässt sich bestimmt einrichten.

Gruss, Carsten.