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:
- Hauptprogramm wird gestartet
- Hauptprogramm startet Plug-Ins als Kindprozesse
- Kindprozesse suchen sich einen Port zum Lauschen und teilen dem Elternprozess diesen Port irgendwie mit
- 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.