TSocket - Online Spiel Kommunikation

[mamble]

Hallo zusammen,

ich will ein Delphi-Spiel soweit programmieren das ein MultiplayerModus möglich ist.
Da ich mir das anfangs nicht zugetraut hatte und auch nicht wrkl. wusste wie ich das realisieren sollte habe ich erstmal ein kleines Boxspiel programmiert und dann versucht die Kommunikation zwischen zwei Spielern (und einem Server) per TSocket zu realisieren. Was besseres ist mir nicht eingefallen, ich weiß nicht was man sonst für einen OnlineModus nehmen könnte. ^^

Das läuft grob so ab:
Clientapp sendet Befehl an Serverapp, Serverapp sendet Befehl an Clients und Clients führen aus.

Das alles klappt jedenfalls auch soweit.... das Problem ist nur das die Kommunikation zwischen Client und Server relativ langsam ist... wenn ich beim Client beispielsweise per Mausklick ein mal "Schlage" dann kommt das an.

Wenn ich aber 10 mal extrem schnell draufklicke dann kommen meist weniger Schläge an... so ca. 5.

Habt ihr da einen Tipp?
Wie kann ich die Geschwindigkeit verbessern?
Liegts an meiner Leitung? (teste das alles Lokal)
Sollte ich was anderes als TSocket verwenden?
Oder realisiert man einen Onlinemodus überhaupt ganz anders?

[Aphton]

Windows puffert intern Daten, die geschickt werden. Dieser Puffer hat eine bestimmte Größe (kann man selber auch setzen; max Größe = 64kb). Wenn du nun 10 x klickst und der aber nur 1 mal geschickt hat in der Zwischenzeit, so landen alle Daten, die noch geschickt werden müssen, im Puffer (9x).
Überschreibt dies den Puffer, so kommts zu nem Fehler und die Sendefunktion liefert als Result 0 oder einen negativen Wert zurück.
Das kann dann der Fall sein, wenn zB nur 4 weitere Datensätze reinpassen in den Puffer - damit wären wir bei den 5 Befehlen, die auch ankommen - so wie von dir beschrieben.

Lösung des Problemes - reagiere auf den Resultwert von der Sendefunktion.
Lege selbst (am besten einen) Queue Puffer an, dem du Datensätze draufpusht und der seperat abgearbeitet wird - per Sendebefehl wird solange gesendet, bis alle Datenabgerbeitet werden; und der Datenpointer wird natürlich um die Anzahl der Bytes, die geschickt wurden, inkrementiert. Kann mal etwas nicht geschickt werden, sei es nun weil der Puffer zu klein ist (oder sonstwas) so inkrementierst du einfach deinen Datenpointer nicht und beim nächsten Sendeversuch wird nochmal probiert usw. usf

Zu deinem Geschwindigkeitsproblem - ich weiß nicht, wie du das ganze nun wirklich gelöst hast, aber, sofern der Server schnell ist, sollte es da eig. keine Probleme geben. Evt. würde ich mir überlegen, von TCP auf UDP zu wechseln, sofern du das nicht bereits hast!

[mjustin]

Zitat:

Zitat von mamble (Beitrag 1157280)

Sollte ich was anderes als TSocket verwenden?

Mit Indy (oder Synapse) als TCP/IP Socketbibliothek erreiche ich lokal auf einem alten Notebook zwischen fünf- und zwanzigtausend Nachrichten (pro Sekunde). So schnell kann man nicht tippen :)

An TCP kann es eigentlich nicht liegen, eher ist etwas im Code ineffizient.

[mamble]

Zitat:

Zitat von Aphton (Beitrag 1157286)

Lösung des Problemes - reagiere auf den Resultwert von der Sendefunktion.
Lege selbst (am besten einen) Queue Puffer an, dem du Datensätze draufpusht und der seperat abgearbeitet wird - per Sendebefehl wird solange gesendet, bis alle Datenabgerbeitet werden; und der Datenpointer wird natürlich um die Anzahl der Bytes, die geschickt wurden, inkrementiert.

Okay, das Problem das du eben beschrieben hast, das hab' ich verstanden, allerdings verstehe ich die Lösung nicht ^^ bzw. wie ich das angehen soll, mit so etwas habe ich mich noch nie befasst.

Zitat:

Zitat von Aphton (Beitrag 1157286)

Zu deinem Geschwindigkeitsproblem - ich weiß nicht, wie du das ganze nun wirklich gelöst hast, aber, sofern der Server schnell ist, sollte es da eig. keine Probleme geben. Evt. würde ich mir überlegen, von TCP auf UDP zu wechseln, sofern du das nicht bereits hast!

Ich habe keinen echten Server, sondern eine Serverapplikation. (und diese führe ich mit dem client lokal aus)
Ja, glaube das ich TCP habe ^^ TSocket ist doch Standardmäßig TCP...oder nicht
Warum sollte ich von TCP auf UDP wechseln? ..und wie?

Zitat:

Zitat von mjustin (Beitrag 1157342)

Mit Indy (oder Synapse) als TCP/IP Socketbibliothek erreiche ich lokal auf einem alten Notebook zwischen fünf- und zwanzigtausend Nachrichten (pro Sekunde). So schnell kann man nicht tippen :)

An TCP kann es eigentlich nicht liegen, eher ist etwas im Code ineffizient.

Leider kann ich nicht gut mit Indy, ich weiß nicht wie ich da das realisieren kann, was ich mit TSocket bereits habe.

Das da etwas am Code ineffizient ist kann gut sein... hab nen sehr chaotischen style..

Hier das wichtigste:

Durch Mausklick aus Komponente sendet CLIENTapp an SERVERapp

Delphi-Quellcode:

ClientSocket1.Socket.SendText(Aktion);

<- Clientapp

Und bei der Serverapp im ClientRead folgendes:

Delphi-Quellcode:

procedure TForm2.ServerSocket1ClientRead(Sender: TObject;
  Socket: TCustomWinSocket);
var DieAktion:string;
    i: Integer;
begin
    DieAktion:=Socket.ReceiveText;
    Memo1.Lines.add(DieAktion);
    For I := 0 to ServerSocket1.Socket.ActiveConnections - 1 do
    begin
       with ServerSocket1.Socket.Connections [I] do
       if (Connected) then SendText(Text);
   end;
end;

Was mir persönlich jetzt an der ClientRead Prozedur aufgefallen ist, ist die suboptimale Lösung des Senden an alle aktiven Verbindungen... aber was besseres ist mir nicht eingefallen.


Jede Hilfe ist willkommen :)

[shmia]

Wenn du bei TCP/IP sehr schnell hintereinander Daten sendest, dann stehen die Chancen gut, dass beim Empfänger alles in einem Datenpaket ankommt.
Wenn der Absender z.B. folgendes schickt:

Delphi-Quellcode:

ClientSocket1.Socket.SendText('HIT 120, 50'); 
for i := 1 to 100 do ; // ganz kleine Pause dazwischen
ClientSocket1.Socket.SendText('HIT 85, 60');

Dann wird beim Empfänger möglicherweise nur ein String mit dem Inhalt "HIT 120, 50HIT 85, 60" ankommen.
Wenn dein Empfänger nicht in der Lage ist die einzelnen Befehle sauber zu trennen, dann kann die Kommunikation nicht korrekt funktionieren.

Aphton hat ja geraten auf den Resultwert der Sendefunktion zu reagieren.
Das ist aber nicht das Problem.
Das Problem ist, dass TCP/IP ein Streamorientiert ist während deine Anwendung Messageorientiert arbeitet.

Code:

StelldireinfachvoreinTextwürdeohneLeerzeichenun
dSatzzeichenübertragenwerdenEinComputerhättedie
grösstenSchwierigkeitendamitzurechtzukommenWofä
ngteinWortoderBefehlanundwohörteraufGenaudasist
dasProblemwennmankeinrichtigesProtokollhatmitde
mdieeinzelnenBefehlegetrenntwerdenkönnen

[Aphton]

Das ist nicht das Problem, klar, das ist die Lösung!
Also nun nicht zu DEM Problem...
Das war die Lösung zu dem Problem mit verloren gegangenen Paketen.
Das was du ansprichst ist auch sehr wichtig, was er nicht berücksichtigt!

[Aphton]

Lösungsvorschlag für das Problem mit Pakettrennung/erkennung:

Ein Paket (Datensatz) besteht aus 2 Komponenten:
<Größenangabe der Daten>
<Daten>

Man pusht nun auf den Queue Pakete in genau diesem Format drauf. Dieser wird abgearbeitet (byte für byte wenns sein muss, spielt auf dieser Ebene noch keine Rolle).
Beim Empfangen wird genau jenes auch getan.

Zwischendrin aber versucht der Empfänger rauszufinden, ob ein ganzes Paket schon angekommen ist, indem er zuerst einmal die ersten paar Bytes (Größenangabe der Daten) aus dem Empfangspuffer ausliest und zweitens sicherstellt, dass die Puffergröße >= Größe von <Größenangabe der Daten> + Größenangabe.
Falls die Bedingung zutrifft, so kann er ausgehen, dass ein Paket angekommen ist und poppt diese dann vom Empfangspuffer!

Edit: @Threadstarter
Ich helfe dir nur theoretisch. Ich werde dir keinen Code schreiben!

[mjustin]

Zitat:

Zitat von Aphton (Beitrag 1157383)

Falls die Bedingung zutrifft, so kann er ausgehen, dass ein Paket angekommen ist und poppt diese dann vom Empfangspuffer!

Das ist bei Indy einfacher - es gibt vordefinierte Funktionen um z.B. Text bis zu einem bestimmten Trennzeichen (CR/LF) in einen String einzulesen, oder eine bestimmte Anzahl Bytes in ein Bytearray (TBytes oder TIdBytes). Indy übernimmt dann das Pufferlesen und Paketzusammensetzen, bis die gewünschten Daten komplett vorhanden sind, oder (bei Netzwerkproblemen oder wenn der Client abgebrochen wurde) ein Timeout auftritt. Ähnliche Funktionen bietet auch Synapse.

[Aphton]

Meinte er nicht, er wolle kein Indy benützen?
:gruebel:

[mjustin]

Zitat:

Zitat von Aphton (Beitrag 1157416)

Meinte er nicht, er wolle kein Indy benützen?

Ja, das schrub er, und ich habe auch Synapse erwähnt. Beide arbeiten im Unterschied zu TSocket mit blockierenden Sockets, was aber nur bedeutet dass man mit Threads arbeitet, wenn gleichzeitig noch andere Operationen oder die VCL mit im Spiel sind. Vorteil bei beiden ist dann aber das leichtere Handling, man muss keine Pakete zusammenbauen und kann sich mehr auf das eigene Protokoll konzentrieren.