AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke Delphi Pokerprojekt realisierung
Thema durchsuchen
Ansicht
Themen-Optionen

Pokerprojekt realisierung

Ein Thema von .chicken · begonnen am 28. Mär 2007 · letzter Beitrag vom 15. Mai 2007
 
Der_Unwissende

Registriert seit: 13. Dez 2003
Ort: Berlin
1.756 Beiträge
 
#21

Re: Pokerprojekt realisierung

  Alt 8. Apr 2007, 11:05
Zitat von DGL-luke:
Was heißt da "ordentlche Auswertung". Fakt ist, Strings matchen ist für sowas total falsch(weil langsam und fehleranfällig), es sei denn, man will es z.B. für Menchen lesbar halten.
Das stimmt doch so schon nicht. Sorry, aber wie kommst Du denn darauf?! Nimm einfach mal XML, ist natürlich langsam, aber keineswegs fehleranfällig oder nur für den Menschen lesbar gehalten. Der eigentliche Hauptvorteil von Strings liegt darin, dass diese immer gleich sind (unabhängig von Byteorder, Feld-Ausrichtung, ...). Klar, auch dort muss man einiges im Protokoll festlegen, aber Du hast eine sehr viel einfachere Erweiterbarkeit (Schlußzeichen), beliebige Anordnung der Bestandteile und kannst sehr einfach Programmiersprachen übergreifend damit arbeiten.
Records mögen schneller sein, sind aber eben für schlechter durch einen Menschen lesbar, auf eine feste Anordnung und Byteorder ausgerichtet und sehr viel schlechter zu erweitern. Natürlich kann man einfach die Größe eines Records senden, bevor das Record übertragen wird, aber die Kommunikationspartner sollten schon wissen, was sich wo in dem Record befindet.
Um das zu umgehen, verwendet man dann in der Regel Auszeichnungen (Tags) und hat ruck-zuck nichts anderes als ein Protokoll, dass eben auch durch Strings realisiert werden kann. Gute Beispiele für die Mächtigkeit sind so flexible Formate wie z.B. Tiffs oder auch XML-Dateien.

Zitat von .chicken:
Zu der Sache mit dem Controller. Also nur der Server kennt den Controller!
Wenn ein Spieler setzt, schickt er eine Nachricht an den Server, zB:
'Bet[600]' ---> 600setzen
Wenn der Server das empfängt, soll er den Controller benachrichtigen, dass er die procedure Bet aufruft!
Dann kann der Controller aber nichtmehr den Server benachrichtigen, wenn er die procedure ausgeführt hat, weil er den Server ja nicht in den Uses hat!
Nochmal dazu, ich verstehe Deinen Ansatz nicht. Warum muss der Controller den die Server Unit kennen? Die Serverunit kapselt doch nur einen TCP-Server (um die Komponente von der Unit zu trennen). Der TCP-Server lauscht in Deinem Programm auf einem Port auf dem Rechner. Kommt eine Anfrage, macht er irgendwas.
Auf der anderen Seite gibt es noch den Clienten. Der besteht unter Anderem aus einem Controller, aber auch aus dem TCP-Client, der mit dem TCP-Server verbunden ist (nach Beitritt zum Spiel) und Nachrichten abschicken kann.
Der Spieler wiederum sitzt vor dem Formular/GUI und drückt einen Knopf. Der Knopf repräsentiert jetzt ein Call, das wird dem Controller mitgeteilt. Der Controller muss das nun an den Server (hier ist der Rechner gemeint, der das Spiel hostet) weiterleiten. Dazu greift der Controller auf seinen eigenen TCP-Client (eigen im Sinne von einges Programm) zurück und schickt die Nachricht ab. Da der TCP-Client mit dem richtigen Rechner verbunden ist, kommt die Nachricht an und hier nimmt sie der TCP-Server entgegen.
Warum muss hier der Controller den Server kennen?

Zitat von .chicken:
Was hälst du denn davon wie ich die Nachrichten schicke und auswerte?
Was ich hier bemängeln würde ist, dass Du wirklich das Problem von Schreibfehlern haben könntest. Du solltest lieber eine Datei anlegen, die alle Kommandos als Konstanten enthält.
Delphi-Quellcode:
CONST COMMAND_CALL = 'Call';
      ...

SendText(COMMAND_CALL);
Damit kannst Du die Strings leicht an einer Stelle ändern (ohne dass Du eine Stelle übersiehst). Sonst kommt es vielleicht dazu, dass Du mal 'Call' mit 'call' vergleichst und das wird wohl nie gleich sein. Es ist einfach sicherer hier mit Konstanten zu arbeiten!

Zitat von .chicken:
Zur Auswertung hab ich mir ne Funktion geschrieben, der ich einen String und zwei Zeichen geben kann, und die dann den Substring zwischen den beiden Zeichen ausgibt
Finde ich gut!

Zitat von .chicken:
Gibts da eigentlich ne schönere/bessere Möglichkeit als diese tausend if-Abfragen?
Nein, die gibt es nicht. Der andere Ansatz besteht darin, dass Du wirklich feste Datensätze (Größe und Struktur ist statisch) überträgst. Da ist dann aber alles mögliche festgelegt und das ist eher weniger zu empfehlen. Heutige Rechner haben einfach massenhaft Leistung. Dynamik dominiert deutlich den Wunsch nach mehr Perfomance (die kommt eh ständig dazu). Modernere Formate (hatte ja vorhing schon Tiff und XML als Beispiel genannt, aber auch MS designierter Bitmap Nachfolger, PDF, ...) setzen auf Auszeichnungen, die zwar geringe Perfomancenachteile mit sich bringen, aber bei denen offensichtlich der Wunsch nach Flexibilität und Erweiterbarkeit doch deutlich im Mittelpunkt steht.
An sich solltest Du aber mit if ... else arbeiten. Ein else wird dabei nur ausgewertet, wenn das vorhergehende if als nicht wahr ausgewertet wurde. So wie Du es jetzt machst, könnte das erste If bereits zutreffen, es würden trotzdem auch alle anderen Punkte ausgewertet werden.

Zitat von .chicken:
Der Server schickt oft soviele Nachrichten nacheinander, dass der Server beim auswerten die Nachrichten durcheinander bringt, wie kann ich das verhindern?
Was genau kommt denn da durcheinander?
Ich schätze einfach mal, dass Du mit einer globalen Variable arbeitest, in die Du das einliest, was der Server empfängt/verschickt. Wechsel hier einfach auf eine lokale Variable, dass sollte das Problem schon beheben.
Hast Du das Problem, dass die Daten als Kette im Speicher landen (also z.B. 'CallBet...Call') und Du nicht weißt wo ein Datum anfängt und das andere endet (sollte bei TCP eigentlich nicht der Fall sein), dann könntest Du einfache Start- und Endzeichen vor jede Nachricht setzen und den String anhand dieser zerlegen (also z.B. 'Call#Bet....#Call').
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:02 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz