Kommunikation zwischen zwei Delphiprogrammen

[rwb]

Danke, ich bastele jetzt mit den verschiedenen Ansätzen rum, und wenn was dabei rauskommt melde ich mich.
Danke noch mal an Alle für Ihre Beiträge.
RWB

[mjustin]

Zitat von dummzeuch:

Es gibt dafür aber die WinAPI Funktionen FindFirstChangeNotification / FindNextChangeNotification, die ich z.B. in dzEditorLineendsFix verwende, um die Font-Datei, die Delphi 2007 erzeugt, jedesmal wieder in ein anderes Verzeichnis zu verschieben.

Der Code läuft in einem Hintergrundthread und sieht so aus:
...
Und nicht vergessen: Der Code sollte in einem Hintergrund-Thread laufen, sonst blockiert er das UI.

Diese API habe ich einer Netzwerkumgebung zum Überwachen eines EDI (Incoming) Verzeichnis auch einmal eingesetzt.
Solange die Anwendung kontinuierlich läuft, und das Netzwerkverzeichnis erreichbar ist, funktioniert es auch prima. Doch nach einer Netzwerkstörung, wegen der das Programm den Incoming-Ordner vorübergehend nicht sieht, oder einem Neustart des Programms, liegen eventuell Dateien im Incoming-Ordner, die zwischenzeitlich eingetroffen sind.
Daher muss man beim Start des Programms dann zusätzlich noch einmal einen normalen Directory-Scan durchführen. So gesehen hat man dann zwei Schleifen für ein und dieselbe Aufgabe.

Zur Kommunikation zwischen zwei Prozessen würde ich entweder das klassische Suchen im Dateisystem (Findxxx) verwenden, oder eine andere Methode für IPC. Client-Server basierte Lösungen jedoch nur mit einem zentralen Server. Nicht auf jedem Rechner im lokalen Netz möchte die IT "wilde" HTTP- oder sonstige offene Server-Ports sehen

[Michael II]

Zitat von Rolf Frei:

Ich nutze hierfür Namend Pipes. Dafür gibt es eine Freeware Komponente, die das Ganze sehr einfach machen. Diese Freeware Komponente habe ich dir mal angehängt. Ich nutze dies schon sehr lange zum Steuern eines Windwosdienstes über ein Trayicon Programm.

Funktioniert super - besten Dank!

Problem:
Es kann bei TPipeServer beim Beenden der Verbindung (Active := false) ein Speicherleck entstehen:
Soweit ich sehe passiert es, wenn ein TPipeClient Disconnect aufruft und TPipeServer "gleichzeitig" mittels Write diesem Client Daten D übermittelt und dann Active := false setzt.
In der Methode TPipeServer.Write wird via AllocPipeWrite für D Speicher reserviert. DisposePipeWrite wird aber für diesen Speicher dann nicht aufgerufen => Leck.
(EurekaLog 7.11.0.1)

Lösung:
Code der Komponente anpassen.

Workaround (Lösung wäre schöner ):
Bei 1-1 Verbindung: TPipeServer schliesst die Verbindung.
Bei 1-n Verbindungen: Flusskontrolle einbauen.

[rwb]

Moin Michael II,
wie benutze ich denn jetzt das Ganze?
Mein Programm(e) ist in der IDE, ich lade die beiden Dateien, nehme sie in die USES auf und dann?
Ratlos,
RWB

[Michael II]

Hoi rwb,
falls du noch nie eine eigene Komponente erstellt hast, dann tu's mal - es macht Spass.
Zur Pipe: Wähle in deinem Delphi das Menu Komponente > Komponente installieren und füge RFNamedPipes.pas hinzu.
In RFNamedPipes.pas gibt's eine Procedure Register RegisterComponents('Win32', [TPipeServer, TPipeClient]);
Nach der Installation der Komponente findest du deshalb in der IDE in der Palette unter Win32 neu TPipeServer und TPipeClient.

Du hast zwei Apps 1 und 2, welche via Pipe kommunizieren sollen?
Knall auf 1 TPipeServer und auf 2 TPipeClient.
Setze die Eigenschaft PipeName in 1 und 2 auf den gleichen Wert.
Setze die Eigenschaft Active von TPipeServer auf true. TPipeServer wartet nun auf Verbindungsanfragen. TPipeClient kann mittels Connect verbinden.
Mit Write übermittelst du Daten. Auf der Gegenseite greifst du die empfangenen Daten im OnMessage ab.
Verbindung abbrechen:
Client seitig: Disconnet.
Server seitig: Active := false setzen (es gibt auch eine protected Methode, welche dich vielleicht interessiert, wenn du mehrere Clients hast und zu einem bestimmten Client die Verbindung kappen willst - schau in den Code)

Ich hoffe das hilft.

[rwb]

Hervorragend Danke

[Neumann]

Was ist mit dem App-Tethering? Das sollte doch auch funktionieren. Habe bisher wenig Erfahrung damit, nur mal ein Übungsbeispiel (Bild mit Handy fotografieren und dann zum Desktop schicken) das geht einwandfrei.

Oder gibt es damit Probleme die ich nicht kenne?

[Uwe Raabe]

Zitat von Neumann:

Was ist mit dem App-Tethering?

Das hätte ich auch in den Ring geworfen, insbesondere da es ja quasi zu den Bordmitteln von Delphi gehört. Leider war ich zum Zeitpunkt der Fragestellung nicht voll einsatzfähig und mittlerweile hat sich das ja schon sehr weit in eine andere Richtung entwickelt.

[Michael II]

Zitat von Uwe Raabe:

Zitat von Neumann:

Was ist mit dem App-Tethering?

Das hätte ich auch in den Ring geworfen, insbesondere da es ja quasi zu den Bordmitteln von Delphi gehört. Leider war ich zum Zeitpunkt der Fragestellung nicht voll einsatzfähig und mittlerweile hat sich das ja schon sehr weit in eine andere Richtung entwickelt.

Und ich würde wie TM (#4) tcp und dazu ICS Overbyte nutzen. Wenn ich die Tethering Infos richtig verstehe, dann kann das Ding für eine lokale Verbindung unter Windows auch "nur" IP - und da ich ICS voll vertraue und gleichzeitig sehe welchen Klotz sich Delphi mit Indy angelacht hat, bin ich vorsichtig mit einer Delphi eigenen Lösung. Aber das Ding ist natürlich sicher echt cool, wenn man gleich oder vielleicht später mal nicht nur lokal miteinander reden will.

Ich habe hier nur reingeschrieben wegen dem Leck in #9. Ich nutze die Pipe (#9) als Alternative zur einer tcp Verbindung. Da es NutzerInnen meiner App immer wieder gelingt mittels Firewall die Verbindung zu kappen ist ein zweiter Weg ganz gut.

[Uwe Raabe]

Die Wahl einer Lösung hängt natürlich auch immer vom persönlichen Geschmack ab. Das macht eine Lösung aber nicht zwingend zu einer besseren oder schlechteren.