kommunikation zwischen zwei programmen während der laufzeit



  • Aus Sicht von C++ gibt es zunächst einmal nur ein Programm, das aktiv ist - Multi-Tasking ist eine Eigenschaft des Betriebssystems und benötigt auch System-Funktionen*.

    Aber als Ansatz würde ich dir empfehlen, eine Pipe o.ä. zwischen beiden Programmen einzurichten, über die sie Daten schicken/empfangen können.

    * dazu kommt gleich die Frage: Für welches System schreibst du?



  • Das ganze soll Portierbar sein, also so Plattform unabhängig geschrieben sein wie möglich...
    ich weiß leider net wie ich das mit pipes realisieren soll, denn ich habe bloß ein beispiel mit einem child prozess der erzeugt wird und dabei eine kopie von demselbigen irgendwas ist,...
    ich meinte am anfang mit child prozess aber ein executable programm das aufgerufen wird...
    ich gucke mich gerade noch a bissl um melde mich gleich wieder..



  • zeusosc schrieb:

    Das ganze soll Portierbar sein, also so Plattform unabhängig geschrieben sein wie möglich...

    Das wird schwierig. Schließlich hat jedes System seine eigene Technik, um Multi-Tasking umzusetzen (wenn überhaupt), da mußt du dich an die örtlichen Gegebenheiten anpassen.



  • hmmm,. bis jetzt habe ich gefunden das mit spawn[vpe]() programme sogenannte Child prozesse aufgerufen werden können und die environments mit übergeben werden, jetzt die frage: wenn ich den pointer (des pointers [des pointers[des ,.. sry kleiner scherz]]) der env mit übergebe die env übermaler, das heisst die env values im child ändere, müsste doch auch der parent diese veränderten bekommen haben oder net???

    das problem was ich noch sehe ist das der parent erst nach beendigung weitermacht... hmmm

    Mit Dcom habe ich mich auch noch nicht beschäfftigt,...

    Zu der Platformunabhängigkeit: so portabel wie möglich

    bei exec() kehrt der prozess nicht mehr zurück,.. heisst das auch das der parent beendet wird??

    Ansonsten schreib ich mal 2 test progs zu pipes()
    hier ist das sehr schön erklÖrt:
    http://cplus.kompf.de/artikel/pipe.html
    danke für eure hilfe bis jetzt 🙂
    melde mich die nächsten tage wieder
    mfg



  • sockets



  • oder vielleicht MPI



  • Mpi is ne schicke sache,.. ich möchte dazu aber net unbedingt ein externes prog nutzen (möchte selber lernen wie dat jeht 😃 )
    wer sich aber denoch dafür interessiert:
    http://www.lam-mpi.org/tutorials/nd/

    also wenn man die env setzt sind die ja nur lokal in bereich des progs,.. hier ein beispiel:

    //jenes liest die env's
    #include <iostream.h>
    #include <stdlib.h>
    #include <stdio.h>
    #include <string>
    using namespace std;
    int main(int argc, char **argv, char **env)
    {
      char **entry;
      bool k;
      std::string huhu;
      k=false;
      while(k==false){
      if(getenv("TESTENV")!=NULL){
    	  printf(getenv("TESTENV"));}
    	  for (entry = env; *entry != NULL; ++entry) {
        printf("%s\n", *entry);
      }
      cin >> huhu;
      if(huhu.find("exit")!=string::npos){k=true;}
      }
      return 0;
    }
    
    //und dieses schreibt eins
    #include <iostream.h>
    #include <stdlib.h>
    #include <string>
    using namespace std;
    int main()
    {
       char in[30];
       int ret;
       std::string bub;
       std::string da;
       bool k;
       k=false;
       char *dot;
       //ret=putenv("TESTENV=TRUE");
       //ret=system("testenv1m.exe");
    
       while(k==false){
    
       bub="TESTENV=";
    
       printf("na dann hau mal in die tasten\n");
       cin >> da;
       //da=in;
       if(da.find("exit")!=string::npos){k=true;}
       bub+=da;
       cout <<bub<<endl;
       ret=putenv(bub.c_str());
    
       }
       return 0;
    }
    

    Also, müsste ich das prog intern aufrufen und die env's mitübergeben, das prob ist das sie dann wieder nur lokal in der umgebung der jeweiligen child progs sind....
    also bleibt noch

    1. shared memory (jeht dat oder meckert win bzw *nix ??)
    2. sockets
    3. session files, ne *.ini gibt den ordner an, und das das datum und die zeit muss erkennbar im namen (bzw in den atributen sein), dann liest die letzte aus bzw schreibt eine neue,.. hmmm
      🙄


  • fuer IPC gibts viele moeglichkeiten ....

    welche die richtige ist, musst schon selber rausfinden.
    Ich hab noch keine richtige IPC bib gefunden, die auch noch plattformunabhaengig ist ... Am nachsten kommen die sockets(TCP/IP) ran. Bibliotheken die dafuer plattformunabhaengig was zur verfuegung stellen, gibts paar. QT zum beispiel.

    Die frage ist auch, ob deine beiden (oder mehreren) prozesse verwand sein sollen ... also quasi startest du jedes programm einzeln, oder startest du einen vaterprozess (daemon vielleicht) der (bei bedarf) mehrere clients creiert.
    Denk mal hier ist mindestens genau so viel konfliktpotential gegeben in sachen plattformunabhaengigkeit, da windows z.b. mehr auf multithreading setzt ... linux (und andere uinxe) mehr auf multiprozessing.

    der "Environment" mechanismus ist unter windows und UNIX zumindest gleich ... nur das es unterschiedliche standardwerte halt gibt ^^
    wichtig ist zu wissen, dass deine komplettes Enviroment beim creieren eines prozesses kopiert wird

    sprich du machst ne shell auf (dos shell oder bash) dann hat die nen set von variablen (autoexec / .bashrc)
    rufst du irgend ein programm auf, werden alle diese variablen kopiert und dem neuen programm uebergeben .... sprich du kannst im child die variable aendern, dein parent wird es nicht mitbekommen ....
    genau so wie du die variablen im parent aendern kannst, deine schon erzeugten childs bekommen das ned mit, erst die neuen ....

    funktioniert auch mit allen exec und system aufrufen aus programmen raus ... das aktuelle enviroment wird dann kopiert !

    Ciao ...



  • Ich würde auf jeden Fall auf berkeley sockets aufbauen - ggf. eine wrapper lib verwenden die die letzten verbleibenden Unterschiede noch ausbügelt.



  • ahh,. k, sockets,...
    http://de.wikipedia.org/wiki/Socket
    und ich dachte sockets bezieht sich eigentlich nur auf netzwerkverbindungen.....
    ich denke das werde ich als nächstes mal ausprobieren,... thx :xmas1:



  • Naja, hauptsächlich verwendet man sockets wenn man über nen Netzwerk will. Bloss kann man eben auch lokal damit "rumtelefonieren", also bloss von einem Programm zum anderen.
    Und weils auf vielen Systemen so halbwegs gleich ist kann man es halt schön hernehmen wenn was portabel sein soll. Es, das "socket interface".



  • Als erstes wollte ich ein bisschen mit winsock rumproben, aber mir fehlt
    ws2_32.lib,....
    ich benutze MinGW Dev Studio...
    wisst ihr wo ich die herbekomme,.. selbst bei msdn.microsoft.com habe wird es zwar erwähnt, finden tue ich aber nÜx....



  • Naja, beim MinGW enden die Libraries nicht mit .lib sondern .a. Das weiß sogar ich als Nicht-MinGW-Benutzer. Um genau zu sein, heißt sie libws2_32.a.



  • Mit MinGW kannst du sogar direkt, ohne Import-Lib, gegen eine dll linken. Das heißt du kannst dem Linker auch einfach die ws2_32.dll aus dem WINDOWS/system32 Verzeichnis angeben und fertig.



  • k thx,.. das funzt schon mal,..
    ich bin das tutorial
    http://www.c-worker.ch/tuts/wstut_op.php
    durchgegangen,..

    Wie wendet man AF_UNIX genau an?? also muss ich dennoch ein port addressieren??

    _________________________________________________________________________________
    wenn ich mehrere clients habe, dann wird eine verbindung aufgebaut, aber weder etwas empfangen noch gesendet, muss ich die acceptCon wieder closen wieder in den listen modus wechseln ??
    mfg und thx

    edit: ok dazu arbeite ich gerade das tutorial:
    http://www.c-worker.ch/tuts/select.php
    durch.....
    _________________________________________________________________________________

    die search engine hier im PhpBB forum ist ja case sensitiv, das erschwert die suche... 😞


Anmelden zum Antworten