Ja, dumme Frage. Erst hier über die wildesten Middleware-Frameworks philosophiert und jetzt noch nichtmal Socket-Kommunikation zwischen eigenen Prozessen auf die Reihe bekommen.

Ich dachte an TCP/IP zwischen meinen Prozessen. Ich habe ein Hauptprogramm und eine variable Anzahl von auf Anweisungen von ihm lauschende Plug-Ins. Diese Plug-Ins werden auf der gleichen Maschine übrigens aller Sittenhaftigkeit nach Kind-Prozesse des Hauptprogramms sein.

Jeder würde wahrscheinlich das Hauptprogramm zum Server machen und die Plug-Ins verbinden sich mit ihm. Ich finde diesen Ansatz nicht passend, die Plug-Ins sollen selbst der Server sein damit ich sie später eventuell auch mal von anderen Anwendungen (evtl. sogar auf anderen Computern) ansprechen kann - Siehe Skizze im Anhang.


Die Aufgabe: Der Kindprozess muss nun den Hauptprozess finden und ihm sagen "Hallo - Hier die Adresse unter der du mich in Zukunft erreichst falls du was zu sagen hast".

Ironischerweise muss man jetzt IPC betreiben um IPC betreiben zu können - Ich möchte nicht festlegen, auf welchen konkreten Portnummern gefunkt werden soll - Das gibt doch nur wieder Ärger falls auf der Maschine dann später noch Drittanbieter-Kram installiert wird.

Ich dachte hier an eine Named Pipe welche das Hauptprogramm bereithält für "Hallo, ich bin ein Plugin, erreichen kannst du mich in Zukunft auf diesem Socket". Broadcasts über Sockets fällt flach, ist ja kein UDP.


Ist das eine halbwegs hieb- und stichfeste Idee? Über Authentifizierung und Abhörsicherheit in der Datenübertragung haben wir uns noch keine Gedanken gemacht, Sessions werden auch nicht gebraucht.

Zitat von Der schöne Günther:

die Plug-Ins sollen selbst der Server sein

Dann müssen sie natürlich auf unterschiedlichen Ports lauschen. Und woher wissen sie welcher frei ist? Theoretisch könnten sie beim Start ab einem bestimmten Port beginnen und bei Kollisionen die Portnummer erhöhen, oder einen zufälligen Port in einem bestimmten Bereich öffnen.

Ich würde bei den Plugins keinen Serverport öffnen. Wozu ist das notwendig? Man kann auch bei einem Client, der sich mit einem Server verbindet, problemlos Pakete sowohl vom Client an den Server oder vom Server an den Client senden. TCP/IP Sockets sind immer auch bidirektional (Peer-to-Peer) benutzbar.

Wenn später mal andere Anwendungen auf die Plugins zugreifen müssen, können sie das über den Hauptprozess als Zwischenschritt tun.

Siehe hier: http://www.delphipraxis.net/1209879-post9.html

Danke für den Hinweis auf SLP - Aber ich glaube das schießt über das Ziel hinaus. Mir ging es mehr darum, nicht noch einmal eine zweite IPC-Methode aufzusetzen, um die erste überhaupt erst möglich zu machen. SLP sieht nach einer tollen Sache aus, aber damit sich zwei verwandte Prozesse unterhalten wohl zwei Nummern zu groß.

Zitat:

Ich würde bei den Plugins keinen Serverport öffnen. Wozu ist das notwendig? [...] Wenn später mal andere Anwendungen auf die Plugins zugreifen müssen, können sie das über den Hauptprozess als Zwischenschritt tun.

Ja, das wäre die große Alternative. Allerdings verbaue ich mir damit die Option, die Anwendung in Zukunft evtl. doch auf mehrere Systeme zu verteilen. Es sei denn, ich pflanze doch wieder jedem Modul etwas ein, selbstständig im Netzwerk zu wühlen und zu versuchen, das Hauptprogramm zu finden. Das ist zugegebenermaßen schon sehr elegant. Aber wenn der Kunde merkt, dass hier nicht eindeutig nachzuvollziehender Netzwerkverkehr entsteht schrillen oft alle Alarmglocken

Mein Plan zusammengefasst noch einmal folgendermaßen:

1. Hauptprogramm wird gestartet
2. Hauptprogramm startet Plug-Ins als Kindprozesse
3. Kindprozesse suchen sich einen Port zum Lauschen und teilen dem Elternprozess diesen Port irgendwie mit
4. Wenn das Hauptprogramm etwas mit einem Plug-In anstellen will, schickt es ihm auf der ihm nun bekannten Adresse eine Nachricht

Für Punkt 3) muss ich mich noch schlau machen, hier reichen wahrscheinlich schon anonyme (lokale) Pipes.