Sichere Kommunikation zwischen Programmen

  • VB.NET

Es gibt 20 Antworten in diesem Thema. Der letzte Beitrag () ist von siycah.

    Sichere Kommunikation zwischen Programmen

    Hallo,

    ich bin auf der Suche nach einer zuverlässigen Methode mit der verschiedene Anwendungen miteinander kommunizieren können.
    Bisher habe ich dafür auf Named Pipes gesetzt. Ich habe dazu jetzt keine genau Statistik, aber zu 100% zuverlässig sind die Named Pipes scheinbar auch nicht.

    Ich verschicke nur sehr kleine Nachrichten, die nach einer Aktion im Programm 1 eine Aktion im Programm 2 auslösen sollen.
    Da die untereinander kommunizierenden Programme auf dem gleichen Rechner laufen, habe ich mir gedacht mich dafür mal mit dem FileSystemWatcher auseinander zusetzen.
    Ich schreibe die kurze Nachricht im Programm 1 also in eine XML-Datei, die der Watcher in Programm 2 überwacht und bei Änderung ausliest.
    Scheint auch ganz gut zu klappen.

    Ist diese Methode sinnvoll, gibts bedenken?
    Oder gar noch andere Möglichkeiten der Kommunikation die wirklich zuverlässig funktioniert?

    Montoyafan schrieb:

    aber zu 100% zuverlässig sind die Named Pipes scheinbar auch nicht.
    Worin äußert sich das?
    Laufen beide Programme auf einem Rechner?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ja, laufen auf dem gleichen Rechner.
    Hatte vorher auch Anonymous Pipes versucht, die waren m.M. nach noch unzuverlässiger.

    Es ist halt leider unwillkürlich und lässt sich dadurch schwer nachvollziehen wieso einige Nachrichten nicht ankommen.

    Ich habe mal ein Beispiel angehängt wie ich das implementiert habe.
    Ich verwende den NamedPipeWrapper von Matt Watson (github.com/acdvorak/named-pipe-wrapper)
    Diese ist als Nuget-Paket installiert und im angehängte Beispiel mit enthalten, hoffe das ist okay.
    Wenn nicht, schmeisse ich es noch raus.
    Dateien

    • NamedPipe.zip

      (210,75 kB, 37 mal heruntergeladen, zuletzt: )

    @Montoyafan Die Projekte funktionieren tadellos.
    Wenn Du beide Projekte in eine gemeinsame Projektmappe packst und beide als Startprojekte auswählst, kannst Du in einem Studio in beiden Projekten gleichzeitig debuggen.
    Wenn Du das Nuget-Zeugs rausschmeißt und nur die DLL reinnimmst, wird das Gesamtprojekt etwqas schmaler.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Montoyafan schrieb:

    Ist diese Methode sinnvoll, gibts bedenken?

    Willkürlich auf dem Filesystem rumschreiben hat immer seine Schattenseiten. Gerade bei SSDs würde ich das, wenn möglich, vermeiden. Wenn es sehr kleine Dateien sind, dann wirst du unweigerlich einen Block beschreiben (4KiB) und auf Dauer auch die Lebenszeit der SSD beeinflussen.

    Montoyafan schrieb:

    Oder gar noch andere Möglichkeiten der Kommunikation die wirklich zuverlässig funktioniert?

    Für unsere IPC verwenden wir diverse Technologien, wie MQTT und DDS. DDS ist für dein Zweck wahrscheinlich völliger Overkill, aber MQTT oder ZeroMQ könnten hier eine sinnvolle Sache sein. Ist alles sehr schmal gehalten und funktioniert unserer Erfahrung nach 100% zuverlässig.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems
    Meine Privatwebseite: SimonC.eu

    Bitte nicht wundern, wenn meine Aktivitäten im Forum etwas langsamer sind, ich baue gerade mein Nebengewerbe zum Vollgewerbe aus.
    Ich versuche auf euch zurückzukommen :)

    RodFromGermany schrieb:

    @Montoyafan Die Projekte funktionieren tadellos.


    Ja, in der Regel tun sie das. Aber es gibt eine unbekannte Prozentzahl wo es eben nicht funktioniert.
    Ich sende über den Tag verteil zwischen den Programmen vllt. 100 Nachrichten hin und her. Wahrscheinlich kommen davon 99 an, aber eben 1 nicht.
    Ich weis aber nicht ob, wann oder warum.
    Es ist ja nicht wirklich reproduzierbar wann und warum hin und wieder eine Nachricht im Nirvana verschwindet.

    siycah schrieb:

    ... aber MQTT oder ZeroMQ könnten hier eine sinnvolle Sache sein. Ist alles sehr schmal gehalten und funktioniert unserer Erfahrung nach 100% zuverlässig.


    Schaue ich mir mal an, vielen Dank :)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Montoyafan“ ()

    Montoyafan schrieb:

    Ich weis aber nicht ob, wann oder warum.
    Es ist ja nicht wirklich reproduzierbar wann und warum hin und wieder eine Nachricht im Nirvana verschwindet


    Ich würde erst einmal rausfinden, welche Nachrichten nicht ankommen. Evtl. schickst Du eine Nachricht, die beim Empfänger einen Fehler auslöst. Ich würde ohnehin jede versendete Nachricht "quittieren" lassen. Sprich, der Empfänger schickt ein OK zurück zum Sender. So kannst Du rausfinden, ob alle ankommen.
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

    SpaceyX schrieb:

    Ich würde ohnehin jede versendete Nachricht "quittieren" lassen
    incl. Message Id oder Sequenznummer.
    Also ein high-level Übertragunsgsprotokoll.

    Wenn du in eine Pipe schreibst, sind die Daten zwar dort, aber es ist noch lange nicht gesichert, dass die Gegenseite sie auch ausliest.
    Das ist wie wenn du eine SMS schreibst. Auch wenn sie meist ankommt, hast du dennoch keine Übertragungsgarantie.
    Erst wenn der Empfänger zurück schreibt, weißt du auch, dass sie angekommen ist.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Montoyafan schrieb:

    ein Beispiel
    Du hast doch ein Funktionierendes Doppel-Projekt.
    Dasa Beispiel kannst Du Dir selbst erarbeiten, der Lerneffekt dabei ist doch wesentlich größer als wenn Du vorgegebenen Code abschreibst.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    SpaceyX schrieb:

    Ich würde ohnehin jede versendete Nachricht "quittieren" lassen

    Kommt natürlich immer auf die Pakete an. Es ist nicht immer sinnvoll, jedes Paket zu quittieren.

    petaod schrieb:

    incl. Message Id oder Sequenznummer.
    Also ein high-level Übertragunsgsprotokoll.

    Genau. MQTT bietet genau solche Möglichkeiten.

    Es können pro Topic und pro Nachricht QoS-Einstellungen getroffen werden. Das macht das Protokoll maximal flexibel.
    Selbst wenn das Topic ​meine/app/wichtige/nachrichten ein QoS von 2 hat (jede Nachricht wird exakt einmal gesendet), kann eine semi-wichtige Nachricht dennoch ein QoS von 1 (die Nachricht wird mindestens einmal sendet) haben.

    Das macht diese Protokolle natürlich unfassbar flexibel.
    Ich darf leider nicht allzu sehr ins Detail gehen, allerdings verwenden wir MQTT in Verbindung mit einem Cloud-Dienstleister für Telemetriedaten.
    Wäre besagter Clouddienstleister selbst nicht so frech was Datendrosselung angeht, hätten wir eine 100%ige Übertragungsrate.
    Dabei sind das Datenpakete von 120-8192 Byte in unterschiedlichen Intervallen.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems
    Meine Privatwebseite: SimonC.eu

    Bitte nicht wundern, wenn meine Aktivitäten im Forum etwas langsamer sind, ich baue gerade mein Nebengewerbe zum Vollgewerbe aus.
    Ich versuche auf euch zurückzukommen :)

    siycah schrieb:

    Es ist nicht immer sinnvoll, jedes Paket zu quittieren.
    Bei der Entwicklung und zu Testzwecken ist das sogar notwendig.
    Außerdem ist es einfacher, nach jeder Message eine Antwort zu senden als noch eine Auswahl treffen zu müssen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:


    Dasa Beispiel kannst Du Dir selbst erarbeiten, der Lerneffekt dabei ist doch wesentlich größer als wenn Du vorgegebenen Code abschreibst.


    Ich habe ja nur nach einem Beispiel gefragt, nicht nach einer Komplettlösung!
    Ich habe keine Ahnung was eine Sequenznummer sein soll und in wie fern sie mir bei meinem Problem hilft.

    Montoyafan schrieb:

    Ich habe keine Ahnung was eine Sequenznummer sein soll und in wie fern sie mir bei meinem Problem hilft.
    Pseudocode:

    Quellcode

    1. Start:
    2. Sequenznummer = 0
    3. Do Loop
    4. Sende Sequenznummer & was auch immer
    5. Empfang Bestätigung, Ausgabe Sequenznummer
    6. Sequenznummer += 1
    7. End Loop
    8. Stop
    Ansehen, was ausgegeben wurde, feststellen, ob alle Sequenznummern vorhanden sind.
    Wenn eine fehlt, beim Text dieser Nummer weiter suchen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Coldfire schrieb:

    geht das - gefühlt- tausendmall besser.
    Dem kann ich nicht beipflichten.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Montoyafan schrieb:

    Ich habe keine Ahnung was eine Sequenznummer sein soll und in wie fern sie mir bei meinem Problem hilft.


    Was hat dich davon abgehalten, selbständig zu recherchieren ? ?( ;)
    google.com/search?client=firefox-b-d&q=Sequenznummer

    RodFromGermany schrieb:

    Bei der Entwicklung und zu Testzwecken ist das sogar notwendig.


    Kommt immer ganz auf die Daten an. Bei Videos und Bildern ist es nicht zielführend, wenn man hier und da ein Frame verloren geht.
    Man muss immer schauen, was für Daten man gerade sendet.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems
    Meine Privatwebseite: SimonC.eu

    Bitte nicht wundern, wenn meine Aktivitäten im Forum etwas langsamer sind, ich baue gerade mein Nebengewerbe zum Vollgewerbe aus.
    Ich versuche auf euch zurückzukommen :)

    siycah schrieb:

    Man muss immer schauen, was für Daten man gerade sendet.
    Jou.
    Wir arbeiten mit vielen digitalen Messwerten über einen Zeitraum von mehreren Stunden.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

Facebook
Telefonspende