Forum Programmation.web lien entre un site PHP et un programme C++

Posté par  .
Étiquettes : aucune
0
18
jan.
2010
Bonjour,

Je suis programmeur débutant C++ utilisant Qt, et j'aimerai héberger un site contenant du PHP contenant des boutons qui activerai des actions dans mon programme C++.

Je n'y connais rien en HTML/PHP/autres...

Donc, je sais pas trop comment faire, pour l'instant je pense à 2 solutions :

- En passant par une base de données : j'aime pas trop ça implique que le programme C++ scrute dans une boucle la base.

- Envoyer des trames TCP/IP en local en ouvrant un socket dans l'application : il me semble que c'est possible en PHP.

Sinon il y'a peut être des modules à associé au PHP qui aide ?

  • # PS

    Posté par  . Évalué à 1.

    Je suis sur Debian

    J'ai pas trouvé comment on modifie un message sur ce forum.

  • # Ca me fend le clavier de répondre...

    Posté par  (site web personnel) . Évalué à 2.

    ... tant c'est une invitation aux trous de sécurité potentiellement dangereux.

    http://php.net/manual/fr/function.system.php

    Evite à tout prix d'y passer un paramètre !
    (sauf via du SQL (injections ^^) et encore)

    Nb : si le client coupe la connection au milieu, le script sera tué dans la foulée.

  • # fork & pipe

    Posté par  . Évalué à 1.

    Salut,

    "les pipes, les forks"

    Le php est interprété par le serveur, donc je vois pas trop comment faire un fork.

    Tu parle bien de fork sur le serveur PHP ?


    Pour l'instant je vois que TCP, en envoyant des trames directement du code PHP

  • # Mémoire partagée

    Posté par  . Évalué à 4.

    Nul besoin de Base de donnée, de socket ou autre… Va voir du côté de la mémoire partagée, des sémaphores et des signaux pour communiquer entre processus.

    • [^] # Re: Mémoire partagée

      Posté par  . Évalué à 1.

      Encore qu'un socket, dans ce cas précis, ce n'est ni plus sale, ni plus compliqué à mettre en œuvre ni plus gourmand en ressources que déclarer et allouer un segment de mémoire partagée, s'y rattacher, trouver le PID du processus et lui balancer des signaux. J'ai même envie de dire qu'à partir du moment où on utilise les signaux pour échanger des données, il y a quelque chose que l'on a mal conçu.

      S'il s'agit d'associer un bouton à une routine, autant faire passer directement le numéro du bouton à travers le socket. Et s'il s'agit d'un projet scolaire, il n'est pas impossible qu'on te demande de regarder du côté des R.P.C. ou de Corba.

  • # Hébergé en local ou sur le net?

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour,

    Une question peut-être avant d'aller plus loin : est-ce que le site que tu veux faire sera hébergé chez toi où par un hébergeur d'Internet?

    Car si tu veux le faire par un hébergeur d'Internet : aucun ne te laissera le faire. Cela implique trop de problème de sécurité. La plupart des hébergeurs proposent du PHP mais sans plus. Ce que tu cherches à faire (un front-end PHP faisant appel à un back-end C++ ou autre est généralement réservé aux portails et n'est donc pas leur cible)

    Si tu veux l'héberger chez toi : dans ce cas ça doit être possible même s'il doit y avoir des solutions plus adaptées.

  • # tube nommé

    Posté par  . Évalué à 1.

    Bonjour,
    Comme tu es sous linux et si tes 2 programmes sont sur la même machine. tu crées un tube nomme


    mkfifo /chemin/vers/tube


    Puis avec php tu écris tes demandes dans ce fichier
    et tu lis comme un fichier normal avec ton programme c++

    nota bene : ton programme c++ dois être lance d'abord avant d'écrire dans ton tube avec php sinon celui-ci va rester bloque en écriture

    Cordialement

  • # DBus ?

    Posté par  . Évalué à 3.

    Qt parle dbus, php parle dbus (http://www.google.com/search?q=php+dbus&ie=utf-8&oe=(...)

    Pourquoi s'embeter avec des ipcs compliquées ?

    • [^] # Re: DBus ?

      Posté par  . Évalué à 1.

      Parce que DBus n'est pas plus facile ? :-) /o\

  • # Essais TCP

    Posté par  . Évalué à 1.

    Bon j'ai fais un essai :
    serveur TCP en Qt
    un socket en PHP

    j'envoie une trame dans le PHP avec socket_write
    je la reçoit bien dans Qt.

    par contre je vais avoir un soucis :

    dans ce sens je peux interpréter instantanément la trame dans Qt grâce au signal readyRead()

    mais coté PHP, je crois pas qu'il puisse déclencher un signal quand qqc arrive sur le socket.

    et je vois pas trop comment lire régulièrement la socket PHP sans être bloquant.

    • [^] # Re: Essais TCP

      Posté par  . Évalué à 2.

      Va regarder du côté de select(). Ou fait du multithreading (je te conseillerais la première solution).

      • [^] # Re: Essais TCP

        Posté par  . Évalué à 1.

        select() c'est pas une liste déroulante ?

        • [^] # Re: Essais TCP

          Posté par  . Évalué à 2.

          Tu confonds deux choses complètement différentes :

          − L'appel système select() sous Unix sert à se mettre à surveiller simultanément plusieurs sockets ou descripteurs de fichiers ;
          − La balise <SELECT> en HTML, dans une page Web, permet de définir une liste déroulante.

          • [^] # Re: Essais TCP

            Posté par  . Évalué à 1.

            Salut,

            l'objectif est que lorsque des données arrivent dans la socket du serveur php, une fonction se lance automatiquement.

            ca éviterai de scruter constament la socket dans un thread.

            mais je sais pas si c'est possible en PHP.

            sinon peut être qu'a partir du programme C++ je peux grâce à une commande en DBUS amener le serveur PHP à faire une procédure.

            • [^] # Re: Essais TCP

              Posté par  . Évalué à 2.

              "qu'une fonction se lance automatiquement" : ça n'est pas que c'est possible ou pas en PHP, mais que ça ne correspond à aucun modèle d'exécution actuel. Les paradigmes "classiques" des langages de programmation actuels ne permettent pas ça. Il faudrait que tu revois un peu tes bases, je pense.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.