Communication PHP vers C++

Version imprimable

22/04/2009, 14h56
projetge2i

Communication PHP vers C++

Bonjour à tous,

Mon problème est simple, j'aimerais transmettre des variables d'un script php qui est sur un serveur web à mon application qui est en c++.

Pour le sens contraire sa n'a pas été trop dur il suffisait d'envoyer une URL avec les variables C++ au script, mais la j'avoue que je bloque.

J'ai penser à écrire les variable dans un fichier texte et le lire ensuite avec mon programme mais sa fait un peu bricolage et surtout c'est pas évident a gérer s'il il y a plusieurs accès simultané pour l'écriture de se fichier.

Merci de votre aide
22/04/2009, 15h59
FoxLeRenard
Citation:

Envoyé par projetge2i

Bonjour à tous,.....

Houla , une premiére précision, le PHP ne connait pas ton micro et ne sait qu'envoyer en réponse a tes requétes que des éléments HTML
donc le HTML, du javascript feuilles de style etc ... , c 'est vrais qu'il peut uploader unélément de ton micro ... mais sécurité oblige c'est trés limité !

Bien sur il serait facile en C de recevoir un paramétre genre lpCmdLine
mais cela supposerait que ton micro accepte qu'un site web puisse lancer
c:\truc\tonprog.exe parametre
Code:

1 2 3 4 5 6 7 8 int WINAPI WinMain ( HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR lpCmdLine, int nCmdShow )
22/04/2009, 16h02
comode

Pour moi, le mieux est de passer par un socket...

Créer un socket en écoute permanente sur ton appli en C, et lorsque ton script PHP veut communiquer, ouvrir le socket, envoyer tes data et fermer le socket.
22/04/2009, 16h12
projetge2i

Merci de vos réponse,
mais j'ai oublié de préciser que ces transfert doivent etre totalement transparent pour l'utilisateur donc les firewall ne doive rien bloquer.
C'est pourquoi il faut que je passe par le port 80 si possible.
Je ne connait pas très bien les socket, estce qu'il le permette ?

la commande lpcmdline ne me parait pas utilisable dans se cas car comme tu la dis les ordinateurs distant n'accepterais pas.
22/04/2009, 16h16
FoxLeRenard

Citation:

Envoyé par comode

Pour moi, le mieux est de passer par un socket...

Créer un socket en écoute permanente sur ton appli en C, et lorsque ton script PHP veut communiquer, ouvrir le socket, envoyer tes data et fermer le socket.

Désolé, aucun systéme ne peut créer une écoute même pas en TCP
car il te faudrait un systéme genre courrier avec acusé reception
donc un protocole UDP. 8O 8O

Mais de quelle entitée vers quelle entitée ?? as tu déjas utilisé ces notions de dialogue ? j' en doute :oops:

Tu crois qu'un micro peut attendre les ordres d'un site web ?? whaou gare aux virus :D
22/04/2009, 16h19
comode

Oui, les sockets permettent de passer par le port 80 sans aucune difficulté, mais il n'est évidemment pas possible d'ouvrir ce port si apache l'utilise déjà.

Cependant, je ne sais pas exactement ce que tu veux faire, mais normalement, de ce que j'ai compris, en aucun cas tu attaques le socket depuis le poste de ton client, mais bien depuis ton serveur apache ! La communication entre apache<->appli C n'est donc pas censé poser de problème de firewall ou autre (surtout si le prog en C et apache sont sur la même machine). Tu peux alors ouvrir n'importe quel port pour communiquer, c'est totalement transparent pour le client. Garde bien a l'esprit que apache ne s'execute que sur ton server, JAMAIS chez le client !

Dans cette optique, les sockets sont de loin la meilleure solution (mais aussi la plus simple)
22/04/2009, 16h25
projetge2i

Je ne comprend pas trop ta réponse comode, peut être que c'est moi qui me suis mal exprimé : mon script php est sur un serveur web et mon application en C++ est chez un client.
Donc lors d'envoi de données du script vers l'application il y a bien un problème de firewall puisque des données rentre chez le client.

merci de ton aide
22/04/2009, 16h25
FoxLeRenard

Citation:

Envoyé par comode

Oui, les sockets permettent de passer par le port 80 sans aucune difficulté, mais il n'est évidemment pas possible d'ouvrir ce port si apache l'utilise déjà.

Cependant, je ne sais pas exactement ce que tu veux faire, mais normalement, de ce que j'ai compris, en aucun cas tu attaques le socket depuis le poste de ton client, mais bien depuis ton serveur apache ! La communication entre apache<->appli C n'est donc pas censé poser de problème de firewall ou autre (surtout si le prog en C et apache sont sur la même machine). Tu peux alors ouvrir n'importe quel port pour communiquer, c'est totalement transparent pour le client. Garde bien a l'esprit que apache ne s'execute que sur ton server, JAMAIS chez le client !

Dans cette optique, les sockets sont de loin la meilleure solution (mais aussi la plus simple)

Alors ça mille fois OUI, avec toi,
si le C est sur le serveur c' est plus du tout le même probléme !
Je n'avais pas compris ça au départ :oops:
22/04/2009, 16h25
comode

Citation:

Envoyé par FoxLeRenard

Désolé, aucun systéme ne peut créer une écoute même pas en TCP
car il te faudrait un systéme genre courrier avec acusé reception
donc un protocole UDP. 8O 8O

Mais de quelle entitée vers quelle entitée ?? as tu déjas utilisé ces notions de dialogue ? j' en doute :oops:

Tu crois qu'un micro peut attendre les ordres d'un site web ?? whaou gare aux virus :D

N'y vois aucune velléité, mais je ne suis pas du tout d'accord avec toi... Bien sur que tu peux ouvrir une connexion depuis apache sur une appli en C si y'a un socket à l'écoute... Car c'est bien ce qui est demandé :

Code:

d'un script php qui est sur un serveur web à mon application qui est en c++

Et ça serait pas le 1er fois que je le ferait ! Alors évidemment, il faut prendre garde à la sécurité (bien qu'un firewall soit plus que suffisant pour ce qui est de la sécurité si appliC et serveur web sont sur la même machine), mais techniquement, je ne vois pas le rapport avec l'usage d'UDP...

Connexion TCP simple, socket simple, un script PHP qui fait un fsock et sans rentrer dans les considérations "quand est-ce qu'on envoi", c'est terminé...
22/04/2009, 16h28
FoxLeRenard

Citation:

Envoyé par comode

N'y vois aucune velléité, mais .......

Oui oui nos messages se sont croisés :king:
22/04/2009, 16h29
comode

ok, fox, on c'était mal compris, et apparemment, je n'avais pas comrpis ce que voulait projetgei non plus :p

Bon, la solution que je propose marche également très bien si tu mets ton appli en C chez le client a condition que ce dernier ne fasse tourner ni serveur web, ni skype (qui utilisent deja tout 2 le port 80) et que son routeur laisse passer le message...

C'est a mettre chez tous les clients ?

Dans tous les cas, aucun routeur ne laissera par defaut entrer une connexion sur la machine de ton client... C'est bien le principe du firewall : ça bloque ce qui rentre et n'est pas explicitement autorisé.
22/04/2009, 16h30
FoxLeRenard

Citation:

Envoyé par projetge2i

Je ne comprend pas trop ta réponse comode, peut être que c'est moi qui me suis mal exprimé : mon script php est sur un serveur web et mon application en C++ est chez un client.
Donc lors d'envoi de données du script vers l'application il y a bien un problème de firewall puisque des données rentre chez le client.

merci de ton aide

Houlala !! on réponds trop vite, alors nous revoici avec ce que je craignais, le C est sur le micro client !!! pffffffff ... mission impossible !
22/04/2009, 16h34
comode

Citation:

Envoyé par FoxLeRenard

Houlala !! on réponds trop vite, alors nous revoici avec ce que je craignais, le C est sur le micro client !!! pffffffff ... mission impossible !

Oui, là d'accord... à moins de faire 2 applis en C :p

La version client qui ouvre la connexion vers une apli en C sur le serveur, que le firewall ne devrait pas bloquer (connexion sortante)... De cette façon, on peut ouvrir une connexion persistante entre le client et le serveur.

La version serveur en C qui reçoit les connexions entrantes et qui fait le pont entre l'appli du client et le serveur Apache, et fonctionnant sur le principe que j'évoque plus haut (sauf qu'on reste connecté).

Par contre, ça devient tout de suite moins simple lol !
22/04/2009, 16h36
projetge2i

Oui l'application sera chez tous les client et c'est bien pour cela que l'utilisation du fichier texte est un peu délicate car il peut y avoir plusieurs connection simultanée.
Et comme je l'ai deja dit il faut que ça demande aucune configuration de l'utilisateur.

Je sais c'est compliqué :roll:

merci à tous les 2
22/04/2009, 16h43
comode

Bon bhé cherche pas, la dernière solution que je propose est la seule qui puisse fonctionner, avec au pire l'éventualité qu'il faille "accepter" que la connexion sorte sur certains firewall du style de zonealarm (mais généralement, une popup apparait le proposant pour les connexions sortantes).

Le gros du travail du coup se situe sur l'appli "intermédiaire" qui devra être capable de gérer une multitude de connexions, et donc d'utiliser des sémaphores (SELECT sur descripteurs de fichier en C). Tu ne pourras cependant pas faire cohabiter apache et l'appli intermédiaire si tu veux qu'ils soient tout 2 sur port 80 et sur le même serveur... Mais comme je dit, c'est pas un très gros problème tant que c'est le client qui établi la connexion.

Il me semble dans mes souvenirs que javascript sait mettre du texte dans le presse-papier 8O

Alors la par contre le C sait trés bien récupérer ça non ?

Je réédites car j'ais troucé ça pret a l'emploie sur le web :king:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
 
<html>
<body>
<script language="javascript">
function retournepressepapier()
{
return window.clipboardData.getData("Text");
} 
 
function copiedanspressepapier()
{
window.clipboardData.setData("Text",formulaire.zone_de_copier.value);
}
 
</script>
 
<form name="formulaire">
<input type="text" name="zone_de_coller"> 
<input type="button" value="Coller" onclick="formulaire.zone_de_coller.value = retournepressepapier();">
<input type="text" name="zone_de_copier"> 
<input type="button" value="copier" onclick="copiedanspressepapier();">
</form>
 
</body>
</html>

22/04/2009, 17h02
FoxLeRenard
Oui je précises que si je mets ça sur mon site, et que l'un de vous va sur mon html ... le copier sera bien dans la mémoire sur votre micro, et donc récupérable par un C de votre micro !

En C on recupére genre
Code:

1 2 3 4 5 char * buffer; if(OpenClipboard()) buffer = (char*)GetClipboardData(CF_TEXT); CloseClipboard();
22/04/2009, 17h09
Seb33300

Mmmh

Si tu appelle une url pour envoyer des infos à PHP, pourquoi ne pas faire la même chose pour les récupérer ?

Par exemple tu appelle une url qui va renvoyer les données que tu cherches à récupérer et qui renverra une chaine du genre var1|var2|var3|... ou encore mieux un xml.

Je suppose que si tu peux appeler une url en C tu dois aussi pouvoir récupérer le contenu de celle ci.
22/04/2009, 17h19
FoxLeRenard

Citation:

Envoyé par Seb33300

Mmmh
Si tu appelle une url pour envoyer des infos à PHP, pourquoi ne pas faire la même chose pour les récupérer ?
Par exemple tu appelle une url qui va renvoyer les données que tu cherches à récupérer et qui renverra une chaine du genre var1|var2|var3|... ou encore mieux un xml.
Je suppose que si tu peux appeler une url en C tu dois aussi pouvoir récupérer le contenu de celle ci.

Non l'Ami, tu verras ça a été expliqué,
le programme C présent chez tout les clients de cette sociétée, sur leurs micros peuvent bien sur passer des paramétres a un PHP situé sur le WEB de la sociétée, mais linverse non !! bien sur le PHP n'ayant aucune action possible sur le visiteur heureusement !
22/04/2009, 17h30
comode

Il parrait que le PHP 5.3 intègre désormais un garbage collector en plus de la gestion des connexion persistante qui marche déjà :p

Enfin moi, je dit ça, je dit rien ^^
22/04/2009, 17h46
FoxLeRenard

Citation:

Envoyé par comode

Il parrait que le PHP 5.3 intègre désormais un garbage collector en plus de la gestion des connexion persistante qui marche déjà :p Enfin moi, je dit ça, je dit rien ^^

Oui les petites fuites mémoire du PHP :mrgreen:
MSN avait lancé son "ramasse miettes" mais tout ça fait que la mémoire est mieux gérée (heu... devrait étre) au niveau serveur.

Le micro du visiteur lui il s'en moque sauf si PHP perd des données pendant son traitement :D
22/04/2009, 17h51
comode

Je pensait plutôt à utiliser PHP en connexion persistante avec le client en C...

De la la sorte, on reste connecté avec le serveur PHP, et on peut envoyer/recevoir à volonté dans les 2 sens et de façon asynchrone. Bref, utiliser Apache comme une appli en PERL ou en C, sans timeout, en lieu et place de la 2e appli C que je propose pour faire le pont entre apache et le client C. Apache, évidemment, ça reste et doit rester sur le serveur.
22/04/2009, 18h07
FoxLeRenard

Mais tu ne trouves pas que le copier collé automatique et transparent c'est quand même mille fois plus simple ?
22/04/2009, 18h11
comode

Bhé non... A vrai dire, je vois pas à quoi ça va te servir... Puisque de toute façon, le serveur apache n'est pas capable d'ouvrir une connexion en direction du client pour lui envoyer spontanément un message (ou du moins, il ne peut pas le faire sans se heurter au firewall)... Donc je vois pas où tu veux mettre ton JS puisqu'il n'a jamais été question de navigateur web là...
27/04/2009, 17h30
projetge2i

Je voudrais revenir sur la proposition de SEB33300,

Estce qu'il exist une fonction du type httpsendrequest qui lance un script.php et qui pourrait retourner le code HTML produit par le serveur ?

Merci
27/04/2009, 23h43
FoxLeRenard

Citation:

Envoyé par projetge2i

Je voudrais revenir sur la proposition de SEB33300,
Estce qu'il exist une fonction du type httpsendrequest qui lance un script.php et qui pourrait retourner le code HTML produit par le serveur ?
Merci

Oui oui l'Ami, mais encore en BETA avec coté serveur pas nimporte quoi et les micros en VISTA tout ça pour quoi 8O
28/04/2009, 15h29
Vil'Coyote

heu la notion/utilisation de webservice ne peut pas rentrer en compte dans ce genre de cas?

Fuseau horaire GMT +2. Il est actuellement 04h20.