Discussion:
Netzwerkkommunikation
(zu alt für eine Antwort)
Thomas Schwobe
2015-01-06 17:41:56 UTC
Permalink
Hallo,

folgendes Szenario: Zwei Anwendungen (A und B [programmiert mit
verschiedenen Sprachen]) sollen miteinander über das Netzwerk kommunizieren.
Dabei sollen sowohl Daten von A nach B aber auch umgekehrt geschickt werden.

Mir fallen das spontan Dinge wie Sockets oder DCOM ein. WM_COPYDATA und
ähnliches fallen wegen des Remotezugriffs weg(?).

Hat jemand schon derartige Erfahrungen gesammelt und kann mir mal einen Tipp
geben, welche Lösung hier angebracht wäre?

Danke und beste Grüße
Thomas
Peter Below (TeamB)
2015-01-06 18:30:36 UTC
Permalink
Post by Thomas Schwobe
Hallo,
folgendes Szenario: Zwei Anwendungen (A und B [programmiert mit
verschiedenen Sprachen]) sollen miteinander über das Netzwerk
kommunizieren. Dabei sollen sowohl Daten von A nach B aber auch
umgekehrt geschickt werden.
Mir fallen das spontan Dinge wie Sockets oder DCOM ein. WM_COPYDATA
und ähnliches fallen wegen des Remotezugriffs weg(?).
Hat jemand schon derartige Erfahrungen gesammelt und kann mir mal
einen Tipp geben, welche Lösung hier angebracht wäre?
TCP/IP ist dafür die beste Wahl, es funktioniert auch, wenn beide
Seiten auf Maschinen mit unterschiedlichen Betriebssystemen laufen und
für so gut wie jede Programmiersprache findet man Bibliotheken für
diese Art der Kommunikation.

Du mußt nur ein Protokoll für den Datenaustausch definieren das dann
auf beiden Seiten implementiert werden muss. Die Kommunikation läuft
generell nach dem folgenden Schema:

Anwendung A (der client) öffnet eine Verbindung mit der Anwendung B
(dem Server), dazu muss sie den Maschinennamen im Netzwerk oder die
IP-Adresse des Servers kennen und halt den Port, auf dem der Server
nach Verbindungsanfragen lauscht. Der Client kann dann Daten an den
Server schicken und andere Daten als Antwort zurückbekommen. (Prinzip
Anfrage und Antwort). Wenn der Server auch von sich aus (ohne Anfrage
des Clients) Daten an den Client schicken soll vertauschen sich dafür
die Rollen, der Server wird zum Client und der Client muss seinerseits
auf Anfragen von aussen warten, also wie ein Server agieren. Das Ganze
erfordert also auch ein gehöriges Mass an multithreading, da der auf
Anfragen wartende Thread blockiert ist bis eine Anfrage eintrifft.

Das Protokoll kann einfach sein. Üblicherweise definiert man einen
Header fester Größe und Struktur, mit dem jede Anfrage und jede Antwort
beginnt. Im Header steht mindestens wieviel bytes an Daten auf den
Header folgen, und möglichst auch eine feste Sequenz von Bytes, die als
Marker dienen, anhand dessen ein Header als solcher identifiziert
werden kann. Mit einem solchen Konstrukt kann der Emfänger immer
verläßlich feststellen, dass er die komplette "Sendung" erhalten hat
und verarbeiten kann.
--
Peter Below (TeamB)
Matthias Frey
2015-01-07 08:39:00 UTC
Permalink
Post by Peter Below (TeamB)
Das Protokoll kann einfach sein. Üblicherweise definiert man einen
Header fester Größe und Struktur, mit dem jede Anfrage und jede Antwort
beginnt. ...
Ist das üblich? Ich meine üblich ist es gleich eine Kanone wie z.B.
SOAP, REST o.ä. auszupacken - auch wenn man nur Spatzen hat. ;-)


Matthias
Peter Below (TeamB)
2015-01-07 18:51:02 UTC
Permalink
Post by Matthias Frey
Post by Peter Below (TeamB)
Das Protokoll kann einfach sein. Üblicherweise definiert man einen
Header fester Größe und Struktur, mit dem jede Anfrage und jede
Antwort beginnt. ...
Ist das üblich? Ich meine üblich ist es gleich eine Kanone wie z.B.
SOAP, REST o.ä. auszupacken - auch wenn man nur Spatzen hat. ;-)
Naja, ich habe es zumindest immer so gemacht ;-). Man will ja nicht
immer gleich einen Webserver verwenden, nicht wahr. Wenn man aber eh
einen braucht ist das natürlich durchaus eine Option.
--
Peter Below (TeamB)
Thomas Schwobe
2015-01-07 13:06:59 UTC
Permalink
Hallo Peter,
Post by Peter Below (TeamB)
TCP/IP ist dafür die beste Wahl,
danke für deine Hinweise.

Thomas
Ole Jansen
2015-01-07 15:44:29 UTC
Permalink
Post by Peter Below (TeamB)
Das Ganze
erfordert also auch ein gehöriges Mass an multithreading, da der auf
Anfragen wartende Thread blockiert ist bis eine Anfrage eintrifft.
In Delphi5 gab es noch ClientSocket und ServerSocket, wo
ich für einfache Anwendungen nur die entsprechenden Ereignisse
programmieren musste.
Ist im Prinzip selbsterklärend und Threads habe ich da nie benötigt
(zumindestens bei 1 Server und 1 Client)

Wie das bei den ganz neuen Delphis ist weiß ich aber nicht...

O.J.
Peter Below (TeamB)
2015-01-07 18:56:23 UTC
Permalink
Post by Ole Jansen
Post by Peter Below (TeamB)
Das Ganze
erfordert also auch ein gehöriges Mass an multithreading, da der auf
Anfragen wartende Thread blockiert ist bis eine Anfrage eintrifft.
In Delphi5 gab es noch ClientSocket und ServerSocket, wo
ich für einfache Anwendungen nur die entsprechenden Ereignisse
programmieren musste.
Ist im Prinzip selbsterklärend und Threads habe ich da nie benötigt
(zumindestens bei 1 Server und 1 Client)
Man konnte diese Komponenten in zwei verschiedenen Modi verwenden:
blocking und nonblocking. Für den ersten Modus braucht man einen
zweiten Thread, for den zweiten erzeugt die Komponente intern einen und
feuert entsprechende Events im Kontext des main threads. Für simple
Fälle war das wirklich völlig ausreichend.
Post by Ole Jansen
Wie das bei den ganz neuen Delphis ist weiß ich aber nicht...
Die Komponenten sind seit vielen Versionen deprecated aber noch da (man
muß sie nur installieren). Und sie funktionieren auch noch <g>. Ich
habe noch ein Projekt, momentan auf XE5, das sie erfolgreich verwendet.

Ansonsten sollte man aber besser Indy verwenden. Dessen
Socket-Komponenten sind aber blocking, da muss man also ein Bißchen
multithreading betreiben.
--
Peter Below (TeamB)
Loading...