Socket-Kommunikation mit anderem Prozess aufbauen - Wie finde ich den überhaupt?

[Der schöne Günther]

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.