Synchrones Multiclient/Server-System mit Minimallatenz + Audio-Möglichkeiten

Hallo,

ich arbeite gerade an einem Multiclient/Server-System, welches eine geringe Menge Daten am Anfang und dann ein Triggersignal an die Clients (Verbunden via WLAN) sendet. Dazu hätte ich ein paar Fragen:

1. Welche Wege gibt es das Triggersignal zeitgleich an die Clienten zu senden, bzw. zu gewährleisten, dass sie Zeitgleich ihren Task beginnen. Es darf keine, oder wenn dann nur unmerkliche, Verzögerung (Latenz zwischen den Clienten unter sich und dem Server) vorliegen. Müssten die Geräte da auch miteinander kommunizieren gibt es da eine serverseitige Lösung?

2. Mal ins Blaue gesponnen, vielleicht gibt es ja doch was was, was ich aber eigentlich bezweifel: Ist es möglich ein stetiges Audiosignal von dem Server an die Clienten zu senden ohne hohe Latenzen in Kauf nehmen zu müssen UND diese Clienten nach wie vor unter sich und mit dem Server synchron zu halten?

Ich hoffe ihr versteht wo drauf ich hinaus will, bin gespannt auf Eure Anworten.

Danke!
Nick

Hallo Nichfaker,

such mal nach SignalR. Vllt ist das für dich.

Zu frage 2, kommt immer auf die Bandbreite und Qualität der Wlan Verbindung an, aber denke das sollte nicht das Problem sein.

Frage 1: absolut nicht möglich. Du kannst auf die Latenz keine Einwirkung nehmen.
Wenn Du eine annähernd absolute Parallelität braucht, dann brauchst Du eine andere Infratsurktur. SignalR ist gewiss nicht so aufgebaut, dass die Nachrichten zeitgleich ankommen. Darauf ist eigentlich kein asynchroner Kommunikationsweg aufgebaut, was auch einen WCF Broadcast einschließt. Das kann schon gut und gerne je nach Entfernung der Clients und Last des Servers bei 10 Sekunden liegen. Das ist alles asynchron!

Natürlich, zeitgleich ist nicht drin, einfach weil die Nachrichten hintereinander geschickt werden müssen. aber 10 sec?? Wenn die Verbindung gut ist und der Server nicht komplett ausgelastet ist, würde ich auf den unteren millisekunden bereich tippen.

Ja, durchaus möglich. Es kann bei vielen Nachrichten sogar dazu kommen, dass die Nachrichten nicht in korrekter Reihenfolge ankommen, sofern dies eine Rolle spielt.

Hmm also, alles was ich bisher von signalr gesehen habe und probiert habe war verdammt schnell. Und eigentlich für das beschriebene szenario geeignet.

Schon mal 240.000 Clients zeitgleich gehabt? 😉
Synchron ist das dann gewiss nicht mehr. Klar - generell hält sich die Latenz im Rahmen von 1-2 Sekunden. Aber es kann durchaus auch mal aufgrund der Priorität zu ein paar Sekunden mehr werden.

Seine Frage bezieht sich quasi auf Echtzeit, da er garantieren will, dass ein Task gleich beginnt. Könnte nun gute oder böse Absichten haben; daher werd ich auch nicht genauer.
Aber generell ist es als Echtzeit eben nicht möglich. Und ja, die Verzögerung ist merklich; selbst bei 3-10 Clients.

Puh, ABER er hat weder Echtzeit noch andere Grenzen genannt. Und wenn ich das Wort Echtzeit immer wieder höre kommt mir so ein wenig die Galle hoch. Schaust Du bitte bei wiki die Definition nach, oder soll ich das tun? Wenn ich definiere das Echtzeit eine Reaktionszeit von 25,345 Minuten sind, ist das so. Oder magst Du mir das absprechen?..

Dachte ichs mir doch..

Also er hat weder von der Auslastung seiner Server noch über die Menge, noch über sonst etwas gesprochen. Echtzeit ist ein völlig relativer Ausdruck der verdammt oft im falschen Kontext gebraucht wird.

In diesem Sinne.

LG

Es darf keine, oder wenn dann nur unmerkliche, Verzögerung (Latenz zwischen den Clienten unter sich und dem Server) vorliegen.

Keine Verzögerung entspricht mehr oder weniger Echtzeit. Daher hab ich auch geschrieben "quasi Echtzeit"; und nicht "garantierte Echtzeit".

Er braucht eine annähernd zeitgleiche Möglichkeit, einen Task zu starten - und genau das ist eben mit so einer Kommunikationsart _garantiert _nicht möglich.
Garantiert im Sinne, dass SignalR und Co so zuverlässig ist, dass dies immer funktioniert.

Ich weiß jetzt auch nicht, warum Du deshalb anfängst zu diskutieren. Das ist einfach so.
Bis der Themenstarter sich zum Vorhaben nicht mehr äußert, werde ich - da ich meiner Meinung nach alles Themenrelevante gesagt habe - das auch nicht mehr tun.

Wenn man die Uhren synchronisiert, einen Task mit einem Startzeitpunkt verschickt (z.B. 10 Sekunden später), dann können die Clients dies etwa zur gleichen Zeit ausführen.

LG pdelvo

Ich bin grade zufällig auf dieses Thread gestossen und stelle mir folgende frage:

Sagen wir mal wir Spielen ein Strategie-Spiel einer ist der Host und sendet an die anderen Spieler "starten", dann wäre der Host ja grundsätzlich im Vorteil weil er früher anfangen darf. Ich weiß es geht um eine sehr geringe Zeitspanne (ca. 10ms-100ms) aber grundsätzlich wäre das so oder täusche ich mich da? Wenn ich mich täuche würde mich intressieren wie die es schaffen das alle gleichzeitig starten.

Das einzige was mir eingefallen ist, wäre zuvor die latzen zu messen und somit auch später zu starten.

An den Vorschlag von pdelvo hab ich auch schon gedacht, aber die Uhrzeiten wäre ja auch in gewisserweise hinsicht asynchron wenn diese gesendet worden sind man müsste also die Uhrzeit + latenz rechnen um die richtige Uhrzeit zu haben.

Sprich egal was ich mir ausdenke 100% Synchron wird nicht gehen oder?

100 % genau geht es natürlich nie.

Aber man kann (laut Wikipedia) die uhren übers Internet auf bis zu 10ms synchronisieren. Dann bestimmt der Server einen Zeitpunkt an dem die Aufgabe gestartet werden soll, und schickt diese Zeit an die Clients. Deswegen spielt dann die Latenz dazwichen keine Rolle, solange sie geringer ist als der Maxilamwert (wie weit die Aufgabe in der Zukunft geplant ist). Dann dürfte das auf bis zu ~10ms genau funktionieren können, genauer wirst du es übers Internet nicht hinbekommen.

LG pdelvo

Crone, deswegen ist der Ping bei Spielen auch viel wichtiger als die Bandbreite.
Es gibt Spiele, bei denen der Ping enorm wichtig ist. Das betrifft so ziemlich alle Ego-Shooter, die zudem auch nicht mit TCP sondern UDP arbeiten.

Rollen-Games hingegen sind nicht so Ping-anfällig, da die Latenzen hier nicht unbedingt direkt in das Spielgeschehen eingreifen. Bei Moment-genauen Treffern wie bei Schüssen ist das aber so.

Die Spieleentwickler rechnen die Latenzen ein, daher wird auch ständig der Ping gemessen. Wie das genau bewerkstelligt und was dort alles hineinfließt wird Betriebsgeheimnis sein.