Ich möchte gern ein LAN-fähiges Mühlespiel programmieren, jedoch habe ich mit LAN in Delphi noch überhaupt keine Erfahrung und wäre deshalb über Hilfe erfreut.

Entschlossen habe ich mich bis jetzt für Indy TCP/IP, da die Übertragung nicht besonders schnell aber möglichst ohne Verlust sein soll. Oder könnt ihr mir etwas anderes empfehlen?

Folgendes dazu habe ich bereits in Erfahrung gebracht:
- Server führt nur wichtige („vertrauliche“) Berechnungen aus und vermittelt ansonsten nur die Clienten
- Clienten sind nur „Darsteller“
- Ich brauche auf der GUI einen TIdTCPClient und TIdTCPServer

Jedoch habe ich noch nichts über die Befehle zum Verbinden und zur Kommunikation gefunden.
Auch stellt sich mir die Frage wie die Datenpakete die übermittelt werden aufgebaut sind?! … sind das nur strings die man vor dem Versenden aufwendig zusammenstellen muss, und der Empfänger diese dann zerpflückt?

Gruß

Hallo und im Forum!

kalle345 hat folgendes geschrieben :

Jedoch habe ich noch nichts über die Befehle zum Verbinden und zur Kommunikation gefunden.

So furchtbar viele Befehle haben die beiden Komponenten ja nicht.

kalle345 hat folgendes geschrieben :

Auch stellt sich mir die Frage wie die Datenpakete die übermittelt werden aufgebaut sind?! … sind das nur strings die man vor dem Versenden aufwendig zusammenstellen muss, und der Empfänger diese dann zerpflückt?

Das ist eine Möglichkeit. Aktuellere Delphiversionen bieten da auch noch ganz andere Möglichkeiten an, aber ich vermute mal, dass du eine ältere hast, oder?

Jedenfalls findest du hier eine Serie von entsprechenden Anleitungen:
www.delphi-library.de/topic_66706.html

Bei den von dir genannten Komponenten kannst du schon bleiben, du musst das ganze nur ein wenig darauf anpassen. Aber die Ideen für das Übertragungsprotokoll usw. werden dort z.B. gut erklärt.

Zurzeit nutze ich Delphi 2005, hätte jedoch die Möglichkeit bei Bedarf Delphi 2010 oder sogar XE2 zu nutzen.
Ist ein Übermittel von beispielsweise Koordinaten mit den neueren Möglichkeiten denn einfacher?
Wie heißen denn Komponenten dazu?

Gruß

Für den Anfang könntest du dir die Units DBXJSON und DBXJSONReflect anschauen. Damit kannst du ganze Objekte in einen String serialisieren und wieder daraus extrahieren:
docwiki.embarcadero....alizing_User_Objects
Diese Strings kannst du dann übermitteln.

Und ab der Enterprise Edition wäre DataSnap, das darauf aufbaut, eine sehr gute Kommunikationsmöglichkeit. Aber rein aus deiner Frage vermute ich, dass das für dich im Moment zu kompliziert und zu umfangreich ist.

Ich würde daher dazu raten die grundlegende Kommunikation über die TCP-Komponenten zu machen und dabei bei Bedarf die DBX-Units zu nutzen um Objekte zu übertragen. Auf diese Weise kannst du bei einem so einfachen Spiel wie Mühle recht komfortabel arbeiten, da ja nicht allzu viele Daten benötigt werden.

jaenicke hat folgendes geschrieben :

Für den Anfang könntest du dir die Units DBXJSON und DBXJSONReflect anschauen. Damit kannst du ganze Objekte in einen String serialisieren und wieder daraus extrahieren: docwiki.embarcadero....alizing_User_Objects Diese Strings kannst du dann übermitteln.

Ich hoffe, das war nur ein Beispiel dafür wie man das machen kann wenn man nur Strings hat. Ich mag JSON, aber bitte nichts serialisieren, was man nicht serialisieren muss.

kalle345 hat folgendes geschrieben :

- Server führt nur wichtige („vertrauliche“) Berechnungen aus und vermittelt ansonsten nur die Clienten - Clienten sind nur „Darsteller“

Das widerspricht sich.

• Entweder die Clients sind nur Darsteller, dann berechnet der Server alles.
  
• Oder die Clients rechnen selber, dann muss der Server immer auch mitrechnen um Konsistenzprüfung zu machen (Fehler/Cheater erkennen).
  
• Oder der Server rechnet gar nicht; das passiert nur verteilt bei den Clients. Das ist schwieriger zu synchronisieren, aber erlaubt mehr Clients, weil der Server nicht überlastet werden kann (er tut ja nichts mehr)

Ich würde wirklich empfehlen, die Tutorials von Narses aus dem Link oben mal von Anfang an durchzuarbeiten (Achtung: der Link geht auf den 5. Teil, aber die Liste steht ja ganz am Anfang dran). Ist die Beste Einfühung in das Thema, die ich kenne. Der Code funktioniert mit den Indies nicht 1:1, aber alle Konzepte (Server, Threads, Clients, Nachrichten, Protokolle etc) die dort vermittelt werden brauchst du ganz genau so wieder.

Client-Server-Sachen sind auch meiner Meinung nach die einzigen, bei denen es hilft sich vorher aufzumalen was auf welcher "Seite" der "Leitung" ist und wie das miteinander spricht. Kannst du ja bei den Tutorials schonmal machen, für dein eigenes Projekt wird das dann viel einfacher.

Martok hat folgendes geschrieben :

Ich hoffe, das war nur ein Beispiel dafür wie man das machen kann wenn man nur Strings hat. Ich mag JSON, aber bitte nichts serialisieren, was man nicht serialisieren muss.

Warum soll man es sich nicht einfach machen? Klar kann man die Daten auch komplizierter einzeln nach einem bestimmten Schema schicken, aber warum sollte man?
Auf diese Weise werden übrigens in DataSnap die Daten von Objekten und ganzer Datasets hin- und hergeschickt. Ebenso die Parameter von Funktionsaufrufen, var-Parameter, Rückgabewerte, ...
Damit kann ich die Objekte und Funktionen in JavaScript-Clients genauso nutzen wie in Prism, RAD PHP, Delphi, ...

Aber wie schon geschrieben: Das wäre hier mit einer Atombombe auf einen Spatzen geschossen. Nichtsdestotrotz halte ich die Serialisierung hier zur Vereinfachung durchaus für sinnvoll.

Ich habe jetzt den ganzen Tag überlegt, wie ich das anders schreiben kann. Leider ist mir nichts eingefallen, also mit dem Hinweis "bitte nicht in den falschen Hals kriegen":

jaenicke hat folgendes geschrieben :

Martok hat folgendes geschrieben : Ich hoffe, das war nur ein Beispiel dafür wie man das machen kann wenn man nur Strings hat. Ich mag JSON, aber bitte nichts serialisieren, was man nicht serialisieren muss. Warum soll man es sich nicht einfach machen? Klar kann man die Daten auch komplizierter einzeln nach einem bestimmten Schema schicken, aber warum sollte man?

Die Antwort passt zu dem Bild was ich von deiner Entwicklungsphilosophie habe. Warum sollte man nach KISS arbeiten, wenn es ein Tool mit wohlkingendem Markennamen dafür gibt?

jaenicke hat folgendes geschrieben :

Auf diese Weise werden übrigens in DataSnap die Daten von Objekten und ganzer Datasets hin- und hergeschickt. Ebenso die Parameter von Funktionsaufrufen, var-Parameter, Rückgabewerte, ...

XMLRPC in JSON, ist ja soweit okay. Immerhin ist es nicht SOAP Im LAN ohne Angreifer ist das auch alles okay.

jaenicke hat folgendes geschrieben :

Damit kann ich die Objekte und Funktionen in JavaScript-Clients genauso nutzen wie in Prism, RAD PHP, Delphi, ...

... was der OP gar nicht will.

jaenicke hat folgendes geschrieben :

Nichtsdestotrotz halte ich die Serialisierung hier zur Vereinfachung durchaus für sinnvoll.

Serialisierung ist dann sinnvoll, wenn ich Infrastruktur habe die nicht wissen kann, was sie da verschickt. Und selbst dann kann man immer noch binär serialisieren. Aber nicht, wenn man nur 4 Pakettypen braucht, von denen man vorher weiß an welche Plattformen sie gehen und wie sie sich verhalten müssen.
Und auch wenn Bandbreite heute nichts mehr kostet (diese verwöhnten Großstadtkinder ), das offensichtliche Argument ist ja die Sicherheit. Wer einen generischen Parser ans Netzwerk hängt und nach dem deserialisieren Objekte haben will mit denen dann gearbeitet wird, sollte schon sehr genau wissen was das bedeutet.

Martok hat folgendes geschrieben :

Warum sollte man nach KISS arbeiten, wenn es ein Tool mit wohlkingendem Markennamen dafür gibt?

Also wenn du selbst zusammenbauen (oder allgemeiner gefasst: selbst machen) statt einem Funktionsaufruf für das Serialisieren (oder allgemeiner gefasst: statt vorhandene Technologien zu nutzen) für KISS hältst, dann habe ich wohl andere Vorstellungen von den S in KISS als du...

Ich habe mich nun für DataSnap entschieden, da es mir für den Anfang am einfachsten erscheint.
Um einen Überblick zu bekommen habe ich dieses Tutorial durchgearbeitet.
Soweit funktioniert alles gut wenn ich Server und Client auf dem gleichen Computer laufen habe.

Wenn ich jedoch Server und Client auf 2 Verschiedenen Computern im Netzwerk laufen habe kommt beim Client der folgende Fehler (auch wenn die Firewall aus ist):


Hoffe ihr könnt mir weiterhelfen?!

MfG

Moderiert von Narses: Bild als Anhang hochgeladen.

Standardmäßig ist bei der TSQLConnection der Host auf localhost eingestellt, wenn du auf dem Client diese auf Datasnap einstellst. Das geht dann logischerweise nur lokal. Hast du den korrekten Hostnamen / IP gesetzt?

jaenicke hat folgendes geschrieben :

Standardmäßig ist bei der TSQLConnection der Host auf localhost eingestellt, wenn du auf dem Client diese auf Datasnap einstellst. Das geht dann logischerweise nur lokal. Hast du den korrekten Hostnamen / IP gesetzt?

Ach natürlich … vielen Dank!
Melde mich bei Bedarf wieder...

MfG

unter SOURGE FORGE gibt es Demos zu INDY 10 client server , einfach mal den Code anschauen