Version imprimable
Bonjour,
Je voudrais savoir comment (si c'est possible) avec AJAX un évènement peut remonter du serveur vers le client. Mon but étant de signaler au client l'aarivée d'un appel sur son téléphone.
Ce traitement doit il être asynchrone, cad le client requête régulièrement le serveur pour savoir se qu'il se passe ?
Ou y a-t-il une solution pour faire remonter l'info du serveur vers le client ?
Il y a actuellement deux solutions :Citation:
Envoyé par cocoyot
- Le polling : le client requete le serveur à intervalle régulier, le serveur renvoyant eventuellement les données.
- Comet : Le client ouvre une connection HTTP vers le serveur. Cette connection est maintenue ouverte pendant longtemps (quelques minutes). Le client vérifie régulièrement le contenu de la connection et le serveur écrit quand c'est nécessaire.
La deuxième option est plus attirante, mais consomme énormément de ressource coté serveur que cette utilisation de HTTP n'est pas du tout prévue par les serveurs (Apache peut gerer une 30aines de connections en simultanée, ce qui est d'habitude largement suffisant, mais si toutes les connections restent ouvertes, il ne pourra servir que 30 utilisateurs).
APache ne peut gérer que 30 connections en simultané ? pour ce type de communication client/serveur alors !???
denisC veut certainement parler de maxClients dans la configuration d'Apache qui a peut être la valeur 30 par défaut (je n'ai pas vérifié).
merci pour la réponse
Oui, c'est bien maxClient. La valeur par défaut est 256.Citation:
Envoyé par cocoyot
Mais il faut savoir que pour le moment, avec un serveur de type Apache, comet est encore très gourmand en ressources.
Voir la discussion :
http://jha.rajeev.googlepages.com/web2push
Par contre, il commence à apparaitre des connecteurs spécialisés dans Comet qui sont bien plus adaptés et moins gourmands en ressources :
Par exemple pour Tomcat : http://tomcat.apache.org/tomcat-6.0-doc/aio.html
Non, le contenu est poussé du serveur, le client le lit simplement. Y'a pas de polling explicite en comet.Citation:
Envoyé par denisC
Oui mais le client vérifie ce qu'il y a dans la connection.... si le client écoute pas la connection, ça marche pas :aie:Citation:
Envoyé par Shinuza
Je mettais l'accent sur "régulièrement", ce qui sous entend l'execution periodique d'une méthode, alors qu'en l'occurence la mise à jour est non pas périodique mais purement évenementielle. ;)
Il n'y a pas de contrainte temporelle dans ce modele.
Ben oui, mais il faut quand même que périodiquement, le client vérifie la connection :aie:Citation:
Envoyé par Shinuza
Le serveur fait de l'évenementiel (qui est souvent codé sous forme de périodiquement), mais le client vérifie pas en continu (bonjour le 100% proc), mais périodiquement le contenu de la connection poussée par le serveur...
En clair Ajax ne propose pas de solution fiable pour cette problèmatique c'est bien ça ?
Ca me fait penser à un projet de mes années estudiantines qui fesait communiquer un serveur et plusieurs client (c t des envois de sms) et JAVA était très pratique pour faire ce genre de chose : "écouter une socket", on le fesait aussi en C mais c'est plus laborieux, il fallait intégrer d'autres librairie à GCC ... pfff.
Le fait d'écouter une socket, ça bouffe juste un chouilla de mémoire vive mais pour le Proc c'est kuetchi. En clair, si tu affecte un port par utilisateur, tu écoute ce port et dès que tu as un événement tu va dans ta mini BDD et tu envois le mail, texto ou autre contenu à la personne non ?
Dites-moi si je dis que des conneries, c'est possible il est tard :lol:
C'est de l'ajax.