Hallo

2 Exe, welche auf der gleichen Maschine laufen, sollen untereinander Daten austauschen.
Die zu übermittelnde Datenmenge ist dabei eher gering. (Kommandos)

Die Exe 1 ist z.B. die Application und die Exe2 der Drucklistenserver.

Für diese Kommunikation kommen ja im allgemeinen zwei Verfahren in Frage.
Entweder Named Pipes oder TCP/IP über Socket.
Welches Verfahren würdet Ihr empfehlen?

Für einen kleinen Ratschlag dankbar.

Gruß Carla

WM_COPYDATA ist noch einfacher. Such hier im Forum mal danach. Das ist eine Standardfrage.

alzaimar hat folgendes geschrieben:

WM_COPYDATA ist noch einfacher. Such hier im Forum mal danach. Das ist eine Standardfrage.

Einspruch euer Ehren,

WM_CopyDATA macht Probleme wenn UAC ins Spiel kommt.
Einige Anwendungen fangen diese Message einfach weg.
Probleme auf 64 bit Systemen.
Ich habe alle Verfahren bereits ausprobiert. Es geht mir also nicht um die Lösung als solche.
Ich möchte eigentlich nur einen Tip zu Vorteil/Nachteil der beiden Verfahren.

Gruß Carla

Einspruch stattgegeben; Das wusste ich nicht.

Gut. Die Sache mit dem CopyData ist sauschnell, bei NamedPipes habe ich eine annähernd gleiche Performance erst mit 10 parallelen Pipes hinbekommen. Mit Sockets habe ich in diesem Zusammenhang noch nicht gearbeitet.

Shared Memory wäre noch eine Variante, fällt mir gerade ein, auch sehr flott.

Hier gibts mehr: www.codeproject.com/...hreads/fast_ipc.aspx

Naja, größter 'Nachteil' bei TCP dürfte wohl sein, dass man einen Socket braucht. Eventuell mischen sich hier mal Firewalls ein, wobei das bei Loopback-Verbindungen aber eher selten ist. Das öffnen des Listening-Sockets dagegen wird wahrscheinlich gemeldet werden.

Named Pipes sind (wie unter Windows alle Arten von Pipes) schweinelangsam. Ist bekannt, regen sich die Portierer von Unix-Programmen regelmäßig drüber auf, weil unter *nix schnelle Datentransfermethoden auf einmal nicht mehr reichen.

Was alzaimar da verlinkt hat ist übrigens ganz ordentlich (besonders das Update), um nicht zu sagen clever gemacht. Ich denke mal ich werde meine eigene RPC-Lib mal darauf umbauen, ein paar andere Ideen hatte ich für das gute Stück sowieso noch. Leider konnte ich die nie Umsetzen, weil CopyData da zu unflexibel war.

Hi,

Martok hat folgendes geschrieben:

Was alzaimar da verlinkt hat ist übrigens ganz ordentlich (besonders das Update), um nicht zu sagen clever gemacht.

Das kann man laut sagen. Hat schon jemand davon eine Delphi-Implementation? Wenn es nicht schon so spaet waere, wuerde ich den Compiler anwerfen...

twm

Ich habe mir das mal kurz angeguckt. Die arbeiten da mit Shared Memory. Das kann man so nicht mit Delphi abbilden, da der Delphi Linker dies nicht unterstützt. Das gleiche Problem hatte ich damals mit meinen LuckieDIPS, als ich das Programm von Jeffrey Richter von C nach Delphi portieren wollte.

Oh. Das erklärt, warum der Code mir so komisch vorkam. Könnte man das mit Mem Mapped Files hinreichend schnell nachbauen?

So wie es aussieht, werden wir uns wohl für TCP/IP (UDP) entscheiden.
Das ist als Verfahren zwar das langsamste, dafür aber das flexibelste.
Die Datenmengen, welche übertragen werden sind eher gering (Kommandozeile).
Ausschlaggebend war, das dieses Verfahren auch über das Netzwerk funktioniert.
z.B. Reportgenerator als Printserver, der schon mal unter Unix laufen kann.
Ein weiterer Vorteil ist das das ganze verbindungslos funktioniert.
Beim Start des Mainprogrammes kann ich über einen Brodcast erst mal feststellen,
welches Programm schon oder noch da ist und dieses z.B. korrekt beenden.

Wir verwenden das Verfahren in einem größeren Programmsystem.
Hier haben wir uns entschieden, Module und Teilprojekte als EXE auszulagern.
Damit sind wir die bpl und dll Hölle los und können mit unterschiedlichen Technologien arbeiten.
Z.B. Altlasten mit Delphi, neue Programmteile in Net.


Gruß
Carla