Version imprimable
Bonjour,
Je souhaite communiquer avec une application qui est déjà lancée.
Je suis sous Ubuntu, donc je pense que je dois récupérer le Pid de l'appli.
Ça c'est pas un problème par contre comment communiquer en C avec cette appli, quelle bibliothèque dois-je utiliser?
Merci pour toute informations.
Communiquer avec une appli ?
Sachant que les programme ne partage pas leur mémoire je vois mal comment tu peux communiquer avec les autres programmes.
Sauf si c'est ton programme , tu peux partager les donné via un fichier sur le DD (mais ça peut etre lourd) , soit avec les arguments qu'on passe en lançant un programme genre ./monprogramme argument1 agument2 ect.
Tu ne peux communiquer avec un autre programme (autrement qu'en lui envoyant des signaux) que si ce dernier peut lire ce que tu lui envoies (par reseau, semaphore, fichier...). Si le programme en question n'a aucune de ces fonctions, il n'y a pas de moyens de communiquer avec lui (tout du moins pas a ma connaissance).
Tu peux injecter une dll dans l'espace memoire d'un autre processus via ptrace et __dl_open de la libc. Le probleme, c'est que cette fonction n'est pas exportee, et que cela demance de trouver son addresse au runtime (via /proc/pid/maps) et de l'appeller en assembleur. En gerant eip/rip, tu peux donner le control a un point d'entre dans ta dll au chargement. C'est sale, mais ca marche. Hotpatch et injectso (32 bits seulement) utilisent ce mechanisme. Pour plus d'info sur la methode, voir phrack 59Citation:
Envoyé par imperio
Ca permet d'injecter du code dans un processus qui tourne et ensuite eventuellement de partager des donnees via shm.
Apres, est-ce que c'est une bonne idee...
Salut ;)
Le problème avec cette technique c'est que les systèmes de sécurité vont criés je pense (anti-virus) car c'est rarement honnête l'injection de code dans un programme en cours ;)Citation:
Envoyé par dahtah
Remarque sous Ubuntu, les anti-virus c'est pas très courant mais je te déconseille cette option surtout si tu comptes exporter vers d'autres plateformes ton projets :)
Sinon pour communiquer entre deux processus tu peux utiliser les pipes :)
Voir un tuto ici ;)
Salut,
Neyort
Un grand merci à tout le monde.
Vous m'avez donné des pistes plus qu’intéressantes, maintenant je vois dans quelle direction je dois chercher. :ccool
Evite en effet la méthode de dahtah... car même si c'est "réalisable", comme il le dit "indirectement" : ça n'est absolument pas fait pour.
Avec ta réponse et celle de Neyort, je suppose que tu as accès aux sources du programme qui fonctionne...
Et dans ce cas, tu peux utiliser n'importe quelle IPC en général (dont les pipes).
La liste que j'ai en tête (probablement pas exhaustive) :
- Pipes
- Socket
- FIFO
- Fichier partagé + sémaphore
- Message Queue
Les pipes sont un peu compliqués...
Peut être devrais-tu regarder les socket UNIX (qui restent locales) ou les FIFO pour t'éviter l'ouverture/fermeture de pipes + le fork initial qui te fera TOUT changer dans le programme quasiment...
Le mot-clé à chercher dans Google est "interprocess communication". Voir par exemples http://en.wikipedia.org/wiki/Inter-p..._communication ou http://www.advancedlinuxprogramming....p-ch05-ipc.pdf. Sous Linux, j'ai souvent entendu parler de D-Bus mais je ne l'ai jamais utilisé.
Hello,
Ça dépend du contexte : soit c'est un exercice scolaire ou bien deux processus distincts mais lancés en même temps dans le même contexte et, dans ce cas, tu devras probablement utiliser les tubes (pipes), soit c'est une vraie application conçue pour les Linux récents, qui vit sa vie mais que l'on doit pouvoir contrôler ou interroger depuis un client en ligne de commande et/ou que l'on souhaite éviter de lancer « en double ».Citation:
Envoyé par dashed
Dans ce dernier cas, la méthode privilégiée est effectivement les sockets UNIX mais tu peux également utiliser DBus, comme suggéré par Bktero. Cela dépendra en fait du niveau d'intégration avec le reste du système que tu veux donner à ton application.
Par contre, de grâce, n'alloue pas un port TCP/IP si tu n'as pas explicitement l'intention de la faire communiquer par le réseau.
Il faut aussi citer les tubes nommés, utilisés notamment par le spooler de l'imprimante et surtout les segments de mémoire partagée qui sont assurément la façon la plus efficace de communiquer des informations mais à qui il manque la possibilité de « signaler » l'arrivée de nouvelles données.Citation:
Envoyé par Metalman
Pour ce faire, on peut soit utiliser les signaux Unix, soit les pipes. Les premiers sont pratiques mais ont plusieurs inconvénients : ils engendrent un certain overhead, ils préemptent le processus, et ne peuvent pas se cumuler (ils fonctionnent dans le même esprit que les IRQ). En outre, n'importe qui peut envoyer indûment un signal au processus et cela limite l'extensibilité de la chose : si plusieurs clients communiquent avec ton application, elle ne peut pas savoir lequel a envoyé le signal.
Utiliser les pipes permet de faire tout cela proprement, mais les tubes anonymes doivent être ouverts à l'avance, ne peuvent être rouverts s'ils ont été fermés et du côté des tubes nommés, il en faut un par client. C'est pourquoi pratiquement tout le monde se rabat sur les sockets BSD qui sont reconnus aujourd'hui par tous les Unix.
DBus est vraiment très intéressant en soi. Le projet a atteint depuis un moment déjà la masse critique qui permet d'inciter les développeurs à s'appuyer dessus. Cela dit, il est relativement lourd à mettre en œuvre et à exploiter et cela implique qu'il soit déjà lancé. Ça veut dire aussi que l'application doit déjà communiquer avec DBus avant même de communiquer avec son client.Citation:
Envoyé par Bktero
Donc, on peut faire un choix entre des sockets UNIX simples et une architecture autour de DBus mais l'idéal serait de pouvoir activer l'un indépendamment de l'autre.