Discussion :

[natoine]

Moi j'aimerai créer une socket dans un script en tant que variable de session et l'utiliser dans d'autres scripts pour communiquer.

Je n'ai pas encore testé.
Est-ce réalisable?

[julp]

Non car toute variable de type ressource (un descripteur de fichier, une connexion à une base, ...) n'est pas sérialisable. Toutefois, les fonctions ayant un rôle persistant (pfsockopen par exemple) maintiennent cette ressource en état (un certain temps) et pourra être récupérée en fournissant à nouveau exactement les mêmes paramètres (puisque c'est sur la base de ceux-ci que la ressource est conservée en mémoire par un processus interne et propre à PHP de hachage).

[natoine]

Arf, le retour de pfsockopen.

En fait j'utilise, socket_create.
Donc dans ce cas, comment faire une socket persistante?

J'ai comme contrainte de forcément appeler mon script dans un navigateur, pas en ligne de commande.

Merci déjà pour ta réponse et merci d'avance pour les autres.

PS: vous retrouverez ma classe ComSeveur que j'aimerai rendre persistante dans la discussion: http://www.developpez.net/forums/sho...29#post2853029

[julp]

Malheureusement pour vous les fonctions de l'extension sockets n'offre pas de moyen de persistance. Cela dit, et entre parenthèses, cette extension deviendra une extension PECL à partir de la version 5.3.0 ...

[kaymak]

...cette extension deviendra une extension PECL à partir de la version 5.3.0 ...

Salut,
Par curiosité Julp, quelle incidence ?

Sinon pour le problème de natoine, sérialiser tels quels un socket c'est effectivement impossible.
Par contre sérialiser l'état d'un socket afin de pouvoir le réouvrir dans le même état précédement à sa fermeture c'est *surement* réalisable.
A étudier dans le détail de ton projet, mais c'est une piste qui pourrait fonctionner.

Autre idée, délégué la persistance dans un processus persistant.
En effet lorsque ton appli coté web souhaite créer une socket, pourquoi ne pas délégué cela à un processus PHP cli externe, qui pour le coup serait persistant.
L'interface web se contente d'enregistrer une socket de lecture PHP via un identifant. Et n'à plus qu'à controler sa création sa destruction.
Ainsi à chaque rechargement de page tu peux interroger ta socket PHP qui est resté connecté avec ton serveur final.
Bon ce n'est qu'une idée, dans la pratique faut voir si le processus cli ne va pas mourir avec la fin du processus httpd............... A étudier encore une fois.

Autremnent, concernant pfsockopen, supposons que tu l'utilises, comment vas tu, entre deux pages, être capable de retrouver le flux ouvert précédemment ?
Cette fonction ne semble pas renvoyer d'identifiant stockable en mémoire. De plus je ne sais même pas si PHP va être capable de retrouver un flux ouvert dans une page A depuis une page B. Et puis comment ? avec quelles fonctions ?
A moins qu'il n'y ai une information que je n'ai pas vu dans la doc.

bye

[julp]

Par curiosité Julp, quelle incidence ?

Cette extension ne sera alors plus standard puisqu'elle ne sera plus incluse avec les sources de PHP, vous aurez alors peu de chance de la retrouver sur tout environnement PHP.

Autremnent, concernant pfsockopen, supposons que tu l'utilises, comment vas tu, entre deux pages, être capable de retrouver le flux ouvert précédemment ?
Cette fonction ne semble pas renvoyer d'identifiant stockable en mémoire. De plus je ne sais même pas si PHP va être capable de retrouver un flux ouvert dans une page A depuis une page B. Et puis comment ? avec quelles fonctions ?

PHP crée, en interne, un identifiant à partir de la valeur des paramètres (regroupement des différents paramètres de la fonction en une chaîne qui est ensuite hachée afin de constituer un identifiant - entier), ceci lui permet donc de conserver cette ressource en l'état et de la restituer lorsque la fonction est rappelée avec exactement les mêmes valeurs pour ses paramètres.

[kaymak]

Cette extension ne sera alors plus standard puisqu'elle ne sera plus incluse avec les sources de PHP, vous aurez alors peu de chance de la retrouver sur tout environnement PHP.

Faudra l'installer via pecl en fait, si elle reste dispo. ok merci.

PHP crée, en interne, un identifiant à partir de la valeur des paramètres (regroupement des différents paramètres de la fonction en une chaîne qui est ensuite hachée afin de constituer un identifiant - entier), ceci lui permet donc de conserver cette ressource en l'état et de la restituer lorsque la fonction est rappelée avec exactement les mêmes valeurs pour ses paramètres.

Donc, à priori, on partage la même ressource avec tout les utilisateurs :/
Et on à finalement assez peu de contrôle dessus.

[julp]

Faudra l'installer via pecl en fait, si elle reste dispo. ok merci.

Oui mais ça reste assez rare d'aller installer des extensions PECL. Non seulement il faut que ça réponde à des besoins très précis mais il faut en plus pouvoir l'installer (donc disposer des droits nécessaires).

Donc, à priori, on partage la même ressource avec tout les utilisateurs :/
Et on à finalement assez peu de contrôle dessus.

Oui, je ne vois pas trop comment PHP pourrait faire autrement surtout quand il fonctionne comme module mais cela signifie qu'il faut connaître les valeurs des différents paramètres de la fonction concernée (les probabilités qu'un tel cas se présente sont donc très minces).

[natoine]

Pour ma part, on a modifié notre protocole de com.
Chaque message est signé avec un identifiant.
Du coup, on ferme les sockets à chaque fois mais on sait que c'est toujours le même client qui communique.

La bidouille quoi.

[kaymak]

La bidouille c'est quand on ne sait pas trop ce que l'on fait mais qu'on y arrive + / -, pas quand on trouve des solutions fonctionnelles et compréhensives pour des problèmes que l'on souhaite régler avec des outils inadaptés C'est encore moins le cas quand on fait des protocoles tant bien même cela ne correspond à l'idéal que l'on à imaginé en débutant le projet.