TSocket - Online Spiel Kommunikation

[mamble]

Richtig vorerst will ich kein Indy benutzen. Wenn ich fertig bin werde ich mir das allerdings mal genauer anschauen und dann ergänzen.

Die langsame Kommunikation zwischen Client und Server (die eigentlich nie so vorhanden war) lag im übrigen nicht an den hier erwähnten Problemen, sondern daran das ich ein Panel zum fang des Klicks benutzt habe :D Das dieses die Klicks langsamer registriert und daher suboptimal für mein Programm ist, ist mir erst später eingefallen.

Mittlerweile habe ich die Panelkomponente durch einen (teilweise) unsichtbaren Speedbutton ersetzt... vorerst genügt das, später werde ich nach einer besseren Lösung suchen.

Das von shmia erwähnte Problem ist in in mehreren Testläufen (mit mehreren tausend Klicks) nur ein einziges Mal vorgekommen (ich protokolliere alle vom Server/Client gesendeten/empfangenen Nachrichten).
Dennoch werde ich mit der zeit auf UDP umstellen, sobald ich weiß wie ;)

Danke an alle.

Eine letzte Frage: Ich benutzte RAD Studio XE2. Wenn ich mir die Infos zu T(Client)Socken angucke, dann wird dort aufgeführt das diese Komponente auch OS X unterstützt. (Siehe Anhang)

http://i.imgur.com/zpat1.png

Wenn ich jedoch eine neue Firemonkey-HD Anwendung erstelle und die Komponente benutzen will wird mir diese nicht angezeigt. Was genau ist da los? ^^

[shmia]

Zitat:

Zitat von mamble (Beitrag 1157801)

Dennoch werde ich mit der zeit auf UDP umstellen, sobald ich weiß wie ;)

Das würde ich mir aber nochmal genau überlegen.
Bei UDP kann es folgende Effekte geben:
1.) einzelne Pakete kommen sporadisch überhaupt nicht an (ohne dass dir das vom Betriebsystem gesagt wird)
2.) Manchmal kommt das gleiche Paket auch zweimal oder öfters an
3.) UDP Pakete können sich gegenseitig überholen (Sender schickt A,B,C und der Emfpänger bekommt A,C,B)

Alle die beschriebenen Effekte sind zwar selten, aber wenn die Software darauf nicht vorbereitet ist kann es ganz böse Fehler geben. :warn:
Bei TCP können die beschriebenen Effekte nicht auftreten, denn das Betriebssystem sorgt dafür, dass alle Daten ohne Verlust in der richtigen Reihenfolge an dein Programm weitergeleitet werden.

[mamble]

Hast du mir in Post #5 nicht von TCP abgeraten? ^^
Was soll ich denn jetzt machen.

...wenn ich später auf Indy umprogrammiere, mit tcp, ist es ja laut mjustin einfach das durch vordefinierte Funktionen zu lösen.
Das wäre doch eine Möglichkeit, oder siehst du da auch noch ein Problem shmia?

Und bitte hilf mir mal einer bezüglich des oben erw. TSockets Problem für OS X :)

[Aphton]

Zitat:

Zitat von mamble (Beitrag 1157801)

Das von shmia erwähnte Problem ist in in mehreren Testläufen (mit mehreren tausend Klicks) nur ein einziges Mal vorgekommen (ich protokolliere alle vom Server/Client gesendeten/empfangenen Nachrichten).
Dennoch werde ich mit der zeit auf UDP umstellen, sobald ich weiß wie ;)

Moment mal, hack das ganze nicht deswegen einfach ab!
Ich schätze mal du hast das NUR lokal getestet, wo du (fast) keine Latenz hast. Dieses Problem tretet aber sehr häufig auf! Es ist also nicht davon auszugehen, dass es schon ok sein wird, nur weil dein "kleiner" Test dich davon überzeugt hat (mich haben meine Tests damals auch überzeugt als ich damit rumspielte.. -.-')

[BUG]

Wegen Nachrichtenverlust von TCP auf UDP umzustellen ist paradox - TCP garantiert die Reihenfolge und dass alle Daten übertragen werden, UDP nicht.
Weil UDP den Overhead für diese Garantien nicht hat, ist es schneller. Dafür können NATs nicht so gut mit UDP umgehen und du musst selbst überlegen, was du machst, wenn Pakete nicht, in der falschen Reihenfolge oder mehrfach ankommen.

[mamble]

Hab doch schon oben geschrieben das ich auf Indy mit tcp umsteigen werde.
Bei udp wärs blöd wenn die Pakte in einer anderen Reihenfolge ankommen, das hab ich nämlich noch nicht geregelt.

Hat einer nun Ahnung von der TSocket Komponente im Bezug auf OS X?

@Aphton: Ich werd das Spiel gleich außerhalb der lokalen Umgebung, online probieren. Danach werde ich dich über den Status informieren ;)