Indy10: Können Datenpakete überholt werden?

[eegoar]

Hallo.

Für ein etwas umfangreicheres Multiplayerspiel habe ich folgendes realisiert:

Es gibt einen Host (der Client und Server enthält) und bis zu 7 weitere Clienten.
30 mal pro Sekunde sendet der Host an alle Clienten (auch sich selbst) ein Datenpaket. Dieses Datenpaket besteht entweder aus den Informationen A oder Informationen B. Es wird korrekt auf den Clienten ermittelt, ob das Paket A oder B ist.
Jedes mal, wenn die Clienten Paket A oder B erhalten, so wird ein bestimmter Rechenschritt ausgeführt. Das bedeutet, dass alle Clienten gleich viele gleiche Rechenschritte machen und dementsprechend alle in derselben Geschwindigkeit laufen (die der Host vorgibt).
Datenpaket A enthält nur die Info, dass ein Rechenschritt gemacht wird. Paket B enthält auch die Information, dass einer, mehrere oder alle Clienten eine Aktion (z.B. Mausklick) ausgeführt haben.
Klickt der Client mit der Maus, so sendet er ein Paket C an den Server, aber im Clienten selber wird der Mausklick noch nicht verrechnet. Erst der Host sendet mit Paket B an alle Clienten, dass ein Client einen entsprechenden Mausklick ausgeführt hat.

Am Ende sollen eben alle Clienten exakt dieselben Berechnungen und Darstellungen haben, wie die anderen Clienten.

Nur wenn ich mit 8 Spielern teste, so gibt es nach ein paar Minuten kleine Unregelmäßigkeiten.
Alle Clienten zeigen an, dass sie dieselbe Anzahl Pakete von A und B erhalten haben. Die Zufallswerte sind in einer festen Reihenfolge, die ich vorher definiert habe. Alle Clienten haben IMMER dieselben Zufallswerte zu einem bestimmten Zeitpunkt (Rechenschritt), ich schließe aus, dass es daran liegt.

Meine Vermutung ist, dass irgendwo bei einem Clienten ein Paket A ein Paket B überholt hat. Der Server sendet über TCP, das Paket A ist nur etwa 1/30 der Größe von B. Ist das möglich?
Wenn ja, wie realisiere ich, dass so etwas nicht passiert, also dass die Reihenfolge der Datenpakete überall eingehalten wird?

mfG, eegoar

[Neutral General]

Hallo,

Wenn du UDP benutzt dann kann das passieren.
Bei TCP wird die Reihenfolge der Pakete beibehalten.
Da kann B eigentlich nicht vor A ankommen.
(Kann schon, aber dann wird auf A gewartet und erst A zurückgegeben und dann B)

[hathor]

Zitat:
"Beispiel einer TCP-/IP-Datenübertragung

Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 (variiert) und einer Nutzdatenlänge von 1460 Byte an den Empfänger. Der Empfänger bestätigt es mit einem TCP-Header ohne Daten mit ACK=1461 und fordert damit das zweite TCP-Segment ab dem Byte Nummer 1461 beim Sender an. Dieser schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger. Dieser bestätigt es wieder mit einem ACK=2921 und so weiter. Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind. Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen.
Fehlt zum Beispiel das TCP-Segment 3, weil es verlorengegangen ist, so kann er nur die 1 und die 2 bestätigen, 4 und 5 jedoch noch nicht. Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal.
Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente. Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt, einen Retransmission Timer."
http://de.wikipedia.org/wiki/Transmi...ntrol_Protocol

[mjustin]

Zitat von eegoar:

Klickt der Client mit der Maus, so sendet er ein Paket C an den Server

Nur zum besseren Verständnis: wieviele Threads verwendet der Client? So wie es beschrieben ist tippe ich auf einen Empfangsthread zum Warten auf A und B Pakete und einen Thread in dem das Paket C gesendet wird. Benutzt der Client zum Lesen und Schreiben die gleiche Connection (Socket) Komponente, oder wird ein TIdTCPClient nur zum Lesen und einer nur zum Schreiben eingesetzt?

[eegoar]

Danke für die Antworten.

Ich habe das Problem gelöst. Es wurden keine Pakete überholt oder nicht gesendet, sondern ich habe in einer bestimmten Prozedur Zufallsvariablen abgefragt, die davon abhängig waren, was der Client für ein Menü geöffnet hat und welche Menübilder zu sehen waren.
Da die Clienten verschiedene Menüs öffnen können und dementsprechend verschiedene Bilder auf dem Programm sehen, waren plötzlich überall verschiedene Zufallswerte vorhanden, die natürlich in dem Spiel bei jedem Clienten alles anders aussehen lassen haben.

Also lag es doch daran, welche Zufallswerte erzeugt werden