Quelle méthode utiliser pour communiquer en HTTP ?

Bonjour,
J'ai un besoin assez particulier qui est de pouvoir manager une ou des bases de données SQLServer et Mysql. Ma question est de savoir quelle est la meilleur méthode à utiliser pour pouvoir communiquer avec.
L'un des tout premier critère c'est que le script soit très rapide. Du coté PHP j'ai fais en sorte de ne pas utiliser de framework et d'écrire de manière optimisé et propre. De ce fait, j'obtiens de bon score sur du gros volume.
Maintenant, reste la meilleur façon de communiquer avec Flex et Air afin que cela puisse être souple en terme de paramétrage concernant la connexion. C'est à dire, où il va chercher les données. Il faut pas que ceci puisse être écrit dans le code Flex.
Pour des raisons d'optimisation de temps et de traitement je souhaite pas interfacé une framework (AMFPHP/Zen_AMF).
Pour l'instant je me suis cassé les dents :aie: sur le Webservice avec Flex. Il me reste donc le HTTPService en sachant que les réponses du serveur ne sera que du XML. Est-ce délirant ou pas décommandé d'utiliser de telle méthodes pour ce type de projet.
Merci

J'ai pas tout saisi de ta requête mais il faut savoir que le protocole amf est de loin le plus performant. Certes zend_amf par exemple est long à instancier vu qu'il s'agit d'un framework mais une fois lamachine lancée, le protocole amf pulvérise tout ;)

Un test ici !

Citation:

---

Envoyé par Madfrix

J'ai pas tout saisi de ta requête mais il faut savoir que le protocole amf est de loin le plus performant. Certes zend_amf par exemple est long à instancier vu qu'il s'agit d'un framework mais une fois lamachine lancée, le protocole amf pulvérise tout ;)

Un test ici !

---

En faite, ma question est de savoir si j'utilise HTTPService serait ridicule dans mon type d'utilisation plutôt qu'un webservice ou AMF vu que dans mon cas j'ai essuyé quelque échec. Mais au vu des test il semblerait que AMF colle la pâté à tout autre technologie et j'ai besoin justement de ce temps de réponse et réaction. Donc je vais me sortir les doigts là ou il devrait pas et tester ta méthode ;) .

HTTPService c'est ni mieux, ni moins bien qu'une autre solution, c'est une solution ;)

Concernant AMF regarde du coté de AMFphp qui est beaucoup plus simple a mettre en oeuvre que ZendAMF, ca te permettra de faire qq tests avec amf et une solution php coté serveur.

Citation:

---

Envoyé par Jim_Nastiq

HTTPService c'est ni mieux, ni moins bien qu'une autre solution, c'est une solution ;)

---

Bonsoir

+1

Perso, je l'ai adoptée puisque je développe php en "dur".
J'ai cette chance.
Et celà permet beaucoup plus de souplesse dans les scripts... et surtout lorsqu'ils sont complexes.

Un framework de développement n'aura jamais toute la faculté de l'homme et de sa réflexion.
Il ne propose que des solutions, certes pratiques ou courantes, mais limité dans l'élaboration d'algos.
C'est une bonne initiative, ou alternative selon, mais il ne fait pas le café à notre place, et on est un peu dépendant de ses possibilités.
Quand on a pas le choix.

En ce qui concerne les réponses serveur :
- "Ce n'est que du XML" ???

Et alors ?...mais c'est bien bien ? ...On ne va tout de même pas révolutionner le xml ?

C'est top top ;)

Entre temps, j'ai choisie le HTTPService. Pour les même raisons que tu évoques. Cela me permet de m'affranchir d'une framework dont j'ai pu esquiver son utilisation jusqu'à présent. L'utilisation d'un xxxamf rend en partie figé la solution.
Par contre j'ai pas compris ta partie concernant le XML.

Je pense qu'il voulait dire qu'il était plus pro XML et donc que le XML etait selon lui une bonne solution ;)

si tu veux mon avis, je ne serais pas si affirmatif sur le bien fondé des échanges XML mais c'est un autre débat :mouarf:

Citation:

---

Envoyé par Jim_Nastiq

Je pense qu'il voulait dire qu'il était plus pro XML et donc que le XML etait selon lui une bonne solution ;)

si tu veux mon avis, je ne serais pas si affirmatif sur le bien fondé des échanges XML mais c'est un autre débat :mouarf:

---

Ha mais non, exprime toi sur ce sujet, je voudrais avoir ton avis sur ce point puisque je pense que beaucoup se pose la question, comme moi.

Alors qq remarques sur le XML :

-extrêmement verbeux, et donc a proscrire dans ces certains cas (optimisation bande passante)
-rapidement compréhensible/lisible pour un humain
-parseur puissant en flex (=> E4X)


Le premier point étant pour moi très important, il faut bien étudier ce que l'on souhaite échanger et dans quel contexte l'échange aura lieu. J'ai vu des cas ou des échanges client serveur se faisait par XML uniquement pour échanger des nombre, entier ou boolean ... c'est un cas extreme mais ca existe :roll:

envoyer 40 caractères pour 2 caractères de données c'est la misère :mouarf:

bref le xml c'est normalisé et très utilisé donc c'est un classique mais il faut bien analyser son besoin avant de l'utiliser :ccool:

Citation:

---

Envoyé par Jim_Nastiq

Alors qq remarques sur le XML :

-extrêmement verbeux, et donc a proscrire dans ces certains cas (optimisation bande passante)
-rapidement compréhensible/lisible pour un humain
-parseur puissant en flex (=> E4X)


Le premier point étant pour moi très important, il faut bien étudier ce que l'on souhaite échanger et dans quel contexte l'échange aura lieu. J'ai vu des cas ou des échanges client serveur se faisait par XML uniquement pour échanger des nombre, entier ou boolean ... c'est un cas extreme mais ca existe :roll:

envoyer 40 caractères pour 2 caractères de données c'est la misère :mouarf:

bref le xml c'est normalisé et très utilisé donc c'est un classique mais il faut bien analyser son besoin avant de l'utiliser :ccool:

---

En effet, le XML donne beaucoup de possibilités mais le risque c'est d'en trop en faire.

Bonjour,

entièrement d'accord ! Entre choisir entre la rapidité de compréhension humaine et la rapidité de compréhension informatique, c'est tout vu...

Je prends un exemple concret : les 2 classes de connexion sockets xmlSocket et Socket. Une de ces classes transmet et reçois les infos sous forme xml (je vous laisse deviner laquelle !) et l'autre sous forme binaire. y'a pas photo de rapidité entre les 2...j'ai même envie de dire que la classe xmlSocket devrait être considérée comme dépréciée...

Une question au passage : celui qui sniffe le réseau et intercepte donc des paquets binaires (cas amf ou classe Socket) peut il facilement décrypter ces paquets à l'instar de ce que fait l'appli ultérieurement ?

merci

Là, je dis "attention". Il faut trouver une frontière juste car si nous rentrons dans le domaine de sécurité, nous risquons de rentrer dans l'excès au même titre que le XML. On peut sniffer 98% du traffic web. A cela je donne qu'une réponse. identification et HTTPS. Je pense que le socket est assez facilement décryptable.

Citation:

---

Envoyé par berceker united

... Il faut trouver une frontière juste car si nous rentrons dans le domaine de sécurité, nous risquons de rentrer dans l'excès au même titre que le XML...

---

C'est clair.

Concernant le xml, j'avoue aussi que je parlais de mon cas d'utilisation.
Je n'exploite pas des fichiers de réponses dépassant 2 MO.
Et le temps de réponse est correct, ou me semble correct, ... et 2 ou 3 MO, celà représente déjà un joli fichier.

Alors maintenant, c'est vrai, tout est relatif.
Et même si je souhaitais optimiser les perfs, je serais pénalisé par les "mini-temps" utiles pour la compression et décompression.
C'est quasi certain.

Citation:

---

Envoyé par Madfrix

....Une question au passage : celui qui sniffe le réseau et intercepte donc des paquets binaires (cas amf ou classe Socket) peut il facilement décrypter ces paquets à l'instar de ce que fait l'appli ultérieurement ?

merci

---

Bonsoir

J'avais oublié de répondre à cette question.
J'utilise un système de gestion de session php, et bien entendu pour des réponses au format xml.
==> Non pas cookies mais serveur.
Ce qui signifie que si les paramètres d'identification ne sont pas valides, aucune session n'est initialisée.
Une session valide conditionne l'accés à certaines données.

A l'inverse, seul l'identifié a accés aux données sollicitées...et depuis son poste de travail.
En l'occurrence, transmises vers le navigateur de son PC (temporaires), et non pas enregistrées sur le PC.
Par conséquent, il ne peut y avoir de fuites, ou données susceptibles d'être "sniffées".

En fait, je sous entendais que le "sniffeur" était l'utilisateur de l'appli destinatrice du socket. En effet, prenons l'exemple de la classe Socket (envoi binaire donc) l'appli Flex recoit ce message, le décrypte puis agit en conséquence. L'utilisateur de l'appli ne doit quand à lui ne rien voir de cette transmission encodée. Or, via des sniffeurs, il peut récupérer l'envoi du serveur de socket sous forme binaire. Peut il décoder ce message facilement ? Je pense que oui puisque la classe Socket et le serveur Zend_Amf pour ne parler que d'eux le font.

Citation:

---

Envoyé par Madfrix

... En fait, je sous entendais que le "sniffeur" était l'utilisateur de l'appli destinatrice du socket... .

---

Et même, celà change quoi puisque ces infos lui sont destinées.(?) :)
Si celui-ci est identifié, il a nécessairement accés à certaines données, binaires ou pas.
Mais ce qui ne sera pas le cas pour d'autres.
J'avoue ne pas comprendre cette "inquiétude".

Citation:

---

Envoyé par alain31tl

Et même, celà change quoi puisque ces infos lui sont destinées.(?) :)

---

Destinées oui, mais il n'a pas à connaitre le "cheminement" et la méthodologie employée pour lui envoyer.

Prenons encore l'exemple d'une socket (non binaire), toutes les informations circulent donc en clair ou presque. Si l'utilisateur clique sur un bouton, il peut potentiellement envoyer une requête au serveur de socket. Cette requête, il peut en voir le formatage en sniffant et "décoder" ainsi la logique du développeur avec un peu d'habileté. A la limite cela ce n'est pas grave. Par contre, à partir du moment où il peut faire le pont lui même au serveur et envoyer une requête, là ca devient extrêmement dangereux. Certes le policy file est sensé protéger contre ca s'il est bien construit mais bon Flex et Flash donc ne sont pas réputés pour leur sécurité :mouarf:

Voilà en gros une de mes inquiétudes

Personnellement, je rentrerais pas dans ce chemin là concernant les technologies client serveur. Il faut y placer un minimum de sécurité mais il y a un moment ou il faut utiliser les éléments déjà existant. Peur de se faire sniffer les trames HTTP, alors la réponse est le HTTPs qui va donner plus de mal. Car d'un coté, cela permet de se concentré plus sur son but que les risques possible. Pour avoir travaillé sur la sécurité coté PHP je peux vous dire que le risque de fermer la porte et laisser la clé de l'autre coté est très vite arrivé. Là ou j'ai travaillé c'est qu'il y avait une équipe chargé de s'occuper du développement et de l'autre coté la sécurité. Ceci parce que bien souvent le développeur laissait vagabonder son esprit sur la sécurité et perdait sa tâche principale et de ce faite, la sécurité était encore pire que s'il y en avait pas. Bref, la sécurité je la compare à une chimiothérapie. On utilise la chimiothérapie pour guérir entre autre d'un cancer mais d'un coté le système immunitaire est tellement abaissé.

Bonsoir,

Je reviens sur ce sujet, si tant est que le système d'identification soit fiable et sécurisé.
C'est un minimum, mais c'est aussi ce que l'on recherche.
Et si on est convaincu par sa pertinence, tout est possible sans trop se poser de questions pour la suite.
Ce qui me surprend, c'est qu'il n'y a jamais de souci lorsqu'on envoie par POST des identifiants (login & pass).
Tiens donc !
Quelqu'un a déjà réussi à intercepter votre log ou pass ? et pour l'exploiter à votre place ?
Moi, jamais.
Et ceci même avant d'être migré vers un support https.

Ensuite, pour en revenir au système de session php ( non cookies), l'originalité est que l'on peut mettre en session une multitude de variables.
10, 100, 1000, et sans limites à contrario des méthodes GET ou POST.
Elles peuvent être écrasées et/ou remplacées à chaque changement d'état depuis le poste utilisateur.
L'intérêt réside simplement dans la communication unique serveur/client.
Et si aucune session n'est initialisée en amont (poste navigateur client), pas de communication.
Ce qui signifie aussi que les données serveur/client unique ne peuvent être interceptées, dieu merci.

Ceci dit, pour appuyer le fait que le binaire ou pas, n''est qu'une question de choix ou de confort, mais qui ne répond qu'aux problèmes de temps de réponses.
Et à mon avis, ce n'est pas une question propre à la sécurité.:)

Mmhhh, je suis pas aussi confiant que tu l'ais avec les sessions. Certes, tu t'es peut être jamais fais intercepter l'identifiant et mot de passe. Mais peut être que tu ne le sais pas ou que tu n'as pas été victime.
Pour information, les sessions peuvent être facilement piratable si le serveur est mal sécurisé. C'est simple, les variables mis en session sont en faite placées dans un fichier dont le nom correspond à l'id de la session. Si quelqu'un accède à ce répertoire, c'est la bamboula party. il y a d'autre moyens mais c'est pas le sujet. ;)

Pour en revenir au sujet principal, binaire ou pas binaire. Je suis conscient et je prend le partie que l'utilisateur peut attendre à la seul condition qu'ont lui fait comprendre qu'il y a une notion de temps à prendre en compte. Pour l'instant je débute et j'ai personnellement pas envie d'aller sur du complexe. Déjà que les webservices n'ont pas l'air de vouloir fonctionner chez moi :roll:

Citation:

---

Envoyé par berceker united

... Certes, tu t'es peut être jamais fais intercepter l'identifiant et mot de passe. Mais peut être que tu ne le sais pas ou que tu n'as pas été victime.... :

---

Oui, un formulaire par définition est conçu pour s'identifier, si sophistiqué soit-il.
Quel intérêt sinon ?
Dans le cas contraire, revenons au boulier, et laissons tomber internet.:)

Citation:

---

Pour information, les sessions peuvent être facilement piratable si le serveur est mal sécurisé. C'est simple, les variables mis en session sont en faite placées dans un fichier dont le nom correspond à l'id de la session. Si quelqu'un accède à ce répertoire, c'est la bamboula party. il y a d'autre moyens mais c'est pas le sujet. ;)

---

Il n'y a pas de répertoire.
==> Sauf chez free (?), ce qui est assez singulier en matière de sécurité.
Pour les autres :
Un id de session n'est créé que lorsque l'identification est valide.
Pas d'id de session ? ==> Pas d'accés aux données.
Et de surcroit, l'id de session n'est accessible que depuis le navigateur qui a sollicité la session, en l'occurence depuis un poste utilisateur...unique
Mais à ton avis, pourquoi ces systèmes de session php ont été innovés, c'est justement pour palier aux problémes de sécurité via les méthodes POST ou GET.
Maintenant, je te défie de me fournir un id de session accessible. ;)

Citation:

---

Envoyé par alain31tl

Oui, un formulaire par définition est conçu pour s'identifier, si sophistiqué soit-il.
Quel intérêt sinon ?
Dans le cas contraire, revenons au boulier, et laissons tomber internet.:)



Il n'y a pas de répertoire.
==> Sauf chez free (?), ce qui est assez singulier en matière de sécurité.
Pour les autres :
Un id de session n'est créé que lorsque l'identification est valide.
Pas d'id de session ? ==> Pas d'accés aux données.
Et de surcroit, l'id de session n'est accessible que depuis le navigateur qui a sollicité la session, en l'occurence depuis un poste utilisateur...unique
Mais à ton avis, pourquoi ces systèmes de session php ont été innovés, c'est justement pour palier aux problémes de sécurité via les méthodes POST ou GET.
Maintenant, je te défie de me fournir un id de session accessible. ;)

---

L'id de la session passe en get ou post et si tu snif le réseau tu peux récupérer le SESSIONID dans la tram. Tu peux éventuellement récupérer la session de l'utilisateur. Mais il est possible de se protéger de cela mais il faut le savoir.

En faisant une recherche sur la compression des données transférées, je suis tombé sur ce site intéressant
Tutorial
http://www.madebycode.fr/tutorials/a...xml#comment-27
Bench
http://www.inwayvideo.com/xmlperf/flex/