Le topic de la programmation, string, chaînes, cuir et compagnie

**deathdigger** · 06/09/2011, 16h45

Petite question JS/Ajax :

Lorsqu'on fait un chat en JS/Ajax (avec PHP + Texte ou Mysql), on ne trouve que des tutos expliquant qu'il faut mettre un timer pour le rafraichissement de la fenêtre de chat. Je me pose une question sur les performances de cela, ça veut dire que toutes les 2 ou 3 secondes (pour éviter un trop grand retard), il faut requêter. Existe-t'il un moyen en "temps réel", avec par exemple :
Un formulaire de chat qui écrit dans un fichier texte, et les requêtes sont envoyées aux clients uniquement lorsque ce fichier texte est modifié (et pas lorsqu'il y'a un refresh) ?

**lincruste** · 06/09/2011, 17h06

Mais comment tu fais pour savoir si le fichier texte est modifié?

**deathdigger** · 06/09/2011, 17h09

C'est ça le truc

**GrandFather** · 06/09/2011, 17h17

Impossible à faire avec JS/Ajax. Le navigateur n'est qu'un client HTTP, et s'il reçoit des données d'un serveur c'est en réponse à une requête HTTP qu'il lui a transmise, dans un échange qu'il a initié. Tu ne peux pas inverser les rôles. Sans compter que tu ne ferais aucune économie de bande passante ou de ressources côté serveur, au contraire.

**rOut** · 06/09/2011, 19h53

Tu peux, ça s'apelle du Comet. Le principe en gros, c'est de tricher et d'abuser du protocole HTTP en effectuant une requête coté client mais en la conservant ouverte coté serveur, jusqu'à ce qu'il y ait des données à envoyer.
Dès que le client doit être notifié, le serveur écrit dans la réponse HTTP et termine la requête. Le client réceptionne tout ça, effectue les modifications et réémet une nouvelle requête immédiatement après. La réponse n'arrivera que lorsqu'il y aura des modifications. Etc.
On peut moduler ça de plusieurs manières, tout d'abord en ajoutant un timeout sur les requêtes (pour ne pas rester bloqué avec des clients qui sont en fait partis), et en obligeant les clients à rouvrir une requête une fois le timeout expiré, qu'il y ait ou non des modifications. Ou encore avec un délai avant de réémettre une requête, qui s'adapte à la fréquence des modifications.

C'est de cette manière que GMail fonctionne (entre autre, et toutes les applis Ajax qui veulent être réactives).

---------- Post added at 19h53 ---------- Previous post was at 19h51 ----------

Sinon maintenant en HTML5 t'as carrément des WebSockets pour de la communication en direct, donc plus besoin de se faire chier.

**GrandFather** · 06/09/2011, 21h04

La vache, je ne connaissais pas la méthode.

Ceci dit, ça doit pas être si évident que ça à mettre en œuvre. Déjà que les problèmes de timeout côté client ne sont pas faciles à appréhender avec des sites Ajax un peu complexes, avec du long polling en plus... Faut un framework béton.

**rOut** · 06/09/2011, 21h52

A mon avis tous les frameworks un peu sérieux proposent ça en standard maintenant.

**GrandFather** · 06/09/2011, 22h18

En standard pas vraiment, de ce que j'ai pu voir en regardant rapidement... Sous forme de plugins pour les frameworks JS les plus répandus, pas au niveau du core (sauf pour Dojo, dont le terme Comet provient). Et côté PHP, pas grand chose non plus, l'offre la plus complète semble être du côté Java.

Plus je lis des choses sur cette techno, plus je me dis que c'est quand même une sacrée bidouille... Heureusement que HTML 5 va rendre tout ça caduc.

**rOut** · 06/09/2011, 22h21

En Python/Ruby je pense que c'est "facile" à faire. Je dis ça intuitivement, c'est peut être pas vrai.

**GrandFather** · 06/09/2011, 22h57

Pour PHP le souci n'est pas le langage en soi, mais le fait que certaines de ses extensions (pas le core) ne sont pas thread safe, ce qui impose un modèle de processus prefork pour Apache (ou alors une compilation en FastCGI pour PHP, mais qui pose d'autres contraintes) si on ne veut pas jouer avec le feu. Ca pose un gros souci pour Comet qui impose des connexions persistantes, la consommation de ressources est trop importante côté serveur avec le modèle prefork (un processus par connexion).

**rOut** · 06/09/2011, 23h15

PHP ça pue quoi.

**GrandFather** · 06/09/2011, 23h19

Nan, c'est Comet qui pue.

:querelledexperts:

**rOut** · 06/09/2011, 23h22

Ou plutôt HTTP qui pue. :faitavancerledébat:

**deathdigger** · 07/09/2011, 00h22

Quel talent ce r0ut

Sinon, j'avais regardé rapidement en Ruby, sans trouver de réel résultat, sinon y'a effectivement en Java via la JRE, et doit peut être y'avoir moyen de coder quelque chose avec silverlight. Dans l'ensemble c'est effectivement toujours très gourmand en ressources, à part en HTML5 ou là, ça me semble nickel

**rOut** · 07/09/2011, 01h05

Faire du long polling, ça ne nécessite rien de bien compliqué : http://stackoverflow.com/questions/3.../333884#333884. Par contre ça peut te flinguer un serveur en moins de 2, pour peu que tu ais un peu de connexions et que ton serveur ne soit pas adapté (apache, apaaache...), parce que tu vas avoir tout plein de requêtes qui restent ouvertes.

Ceci dit, ça peut aussi être vu comme un moyen de bien maîtriser la charge, en réutilisant la même requête pour afficher la page, sans en recréer d'autre (ce qui, du coup, économise la partie acceptation et allocation d'une nouvelle requête HTTP). On peut aussi connaître précisément le nombre de clients connectés à chaque instant, et si on sait mesurer la capacité du serveur, refuser tout nouvel accès (et éviter d'avoir les clients qui se piquent les chaussettes les uns les autres et se tapent une erreur 500 sur tous les deux clics).

**GrandFather** · 07/09/2011, 08h53

Envoyé par rOut

Faire du long polling, ça ne nécessite rien de bien compliqué : http://stackoverflow.com/questions/3.../333884#333884. Par contre ça peut te flinguer un serveur en moins de 2, pour peu que tu ais un peu de connexions et que ton serveur ne soit pas adapté (apache, apaaache...), parce que tu vas avoir tout plein de requêtes qui restent ouvertes.

J'ai regardé cet exemple, ainsi que d'autres disponibles sur le net, et si c'est effectivement simple à mettre en œuvre en labo, je reste persuadé qu'en production et côté serveur c'est beaucoup moins trivial que ça en a l'air...

**messe sans cause** · 09/09/2011, 16h07

Nginx ne serait pas plus adapté côté serveur avec ses process asynchrones? (enfin ça ne règle pas le problème je vous l'accorde).

**rOut** · 10/09/2011, 15h03

Peut être. En tout cas certainement plus qu'Apache.

**deathdigger** · 10/09/2011, 16h14

Je vais certainement en faire hurler certains, mais c'est dans le but d'améliorer un truc :

Je suis actuellement en train de développer un jeu en tour par tour en multi, le client est en C# (C# windows form, pas de XNA, de directX ou autre moteur graphique poussé) et du côté serveur ce sont de bêtes pages PHP qui récupèrent des valeurs POST (sur un serveur Apache

).
Cette technique est bien sûr pas optimisé, mais avec les langages que j'utilise, difficile de faire plus.
Je pense qu'il serait plus judicieux d'utiliser C# du côté serveur pour faciliter, sécuriser et "fluidifier" les données transmises entre les postes clients et le serveur. La question est : sachant que c'est un serveur Linux, est-ce que mono est complet et permet de faire tout ce qui serait possible via un programme C# sur Windows ?
Quand est-il de la communication entre C# via mono et une bdd mysql ?

Le top serait bien sûr que j'apprenne un langage plus adapté (C voire C++), mais j'imagine que le temps d'apprentissage de ce type de langage est beaucoup plus élevé que le C#

**rOut** · 10/09/2011, 16h27

Heu pour coder un serveur, en supposant que tu conserve le protocole HTTP pour transporter tes données, le C# ne t'apportera rien. Ni en terme de fluidité, ni en terme de performance, certainement pas en terme de facillité de développement, et encore moins en terme de maintenance du serveur sous Linux... Du PHP/Python/Ruby ou n'importe quel autre language orienté web convient très bien et t'offre toute la facilité du développement et de l'hébergement web pour ton serveur. Une communication client/serveur avec les données formattées en JSON, une couche HTTPS gérée par le serveur web éventuellement si tu veux de la sécurité et roule ma poule. Pour du tour par tour, c'est suffisamment léger pour être rapide.
Autre avantage, c'est un protocole bien normalisé, et si ton client C# ne te plait plus, libre à toi de faire des pages web à la place, tu n'auras même pas à recoder la communication client/serveur.

Le C/C++/C# seraient plus appropriés si ton jeu nécessitait des données en temps réel, avec le moins de latence possible. Et tu aurais à te coder une couche de protocole réseau à la main, comme les vrais hommes, en slip et chaussettes.

**GrandFather** · 10/09/2011, 19h16

Envoyé par deathdigger

Cette technique est bien sûr pas optimisé, mais avec les langages que j'utilise, difficile de faire plus.

Tu es vraiment sûr de ne pas pouvoir faire mieux ? Si tu as la main sur le serveur, tu peux mettre en place un cache d'opcode pour PHP (type APC), utiliser les caches de requêtes de MySQL, relire pour la éniéme fois ton code pour vérifier s'il n'y a pas d'optimisation possible, éventuellement utiliser gzip pour diminuer la consommation de bande passante, vérifier que les indexs sur tes tables sont pertinents, et sûrement plein d'autres choses qui ne me viennent pas immédiatement à l'esprit...

**rOut** · 10/09/2011, 19h28

D'ailleurs pourquoi tu veux changer ? Ça rame ? T'es sûr que ça vient de ta couche réseau ?
Parce que bon, faut pas oublier non plus le vieil adage : "Quand ça marche, on ne touche pas."

**Robix66** · 10/09/2011, 23h24

Dites, j'ai une question qui me turlupine depuis un petit moment maintenant (un peu plus d'un an

).

En stage, j'ai fait un programme en C pour un microcontrôleur Microchip, avec une interruption toutes les Xµs.
Dans l'interruption, j'avais un truc du genre :

Code:

Interruption()
{
 Blabla
 ChangeValeur(Valeur);
}

Dans ChangeValeur :

Code:

Truc=On;
ChangeValeurTruc(Valeur);
Truc=Off;

Premièrement, on remarque qu'entre le moment où Truc passe de On à Off, il se passe beaucoup trop de temps (on ne dépasse pas la valeur de l'interruption, mais c'est trop quand même).
On colle le contenu de ChangeValeurTruc directement dans ChangeValeur, hop l'opération n'est plus anormalement longue.

Ça, c'était bizarre, mais soit.
Plus tard dans le programme, j'ai besoin d'effectuer des calculs avec des floats, sauf que la bestiole se met à ramer et donc à faire n'importe quoi vu qu'il passe tout son temps dans l'interruption.
"Ok, il est très lent à utiliser les floats, je vais les enlever... wait

". Le programme ramait quand même, même si les opérations sur les flottants n'étaient pas effectuées, genre si je les mettais dans une fonction jamais appelée. Si je les foutait en commentaire, ça remarchait proprement.

Après avoir avoir écumé le web, et tenté à peu près tout ce qui me venait à l'esprit (essayer sans brancher le debuggueur, virer le watchdog...) j'ai mis toute ma fonction ChangerValeur dans l'interruption, et miracle plus de problèmes.

Je voudrais bien qu'on m'explique ce qui s'est passé.

**Le_CuLtO** · 11/09/2011, 00h03

En attendant que les spécialistes répondent, je peux te donner une piste sur la lenteur du programme quand tu utilises plus de fonctions.
Si ma mémoire est bonne une fonction est transformée en jump quand c'est compilé, si tu ajoutes à ça la variable passée en paramètre ça fait utiliser un peu plus la pile, les 2 combinés ça donne quelques cycles processeur en plus.
L'exemple typique c'est les algos récursif, très simple, mais plus lent et dangereux de temps en temps ^^.

Mais ça doit jouer sur pas grand chose, là tu as l'air de dire que ton programme devient hyper lent.

**Thamior** · 11/09/2011, 00h05

Bah, mettre le code d'une routine directement dans l'interruption t'évites d'avoir à faire un saut vers le code de ladite routine et de revenir vers ton interruption une fois la routine exécutée, c'est de l'inlining en fait. Ça t'économise donc un certain nombre d'instructions. Faut voir l'impact que ça à sur ce microcontrôleur spécifiquement, mais la comme ça je dirais que c'est ça qui te fait gagner du temps.

Pour les float, par contre, sans ton code, moi je ne m'avancerais pas.

**Robix66** · 11/09/2011, 00h39

Envoyé par Le_CuLtO

En attendant que les spécialistes répondent, je peux te donner une piste sur la lenteur du programme quand tu utilises plus de fonctions.
Si ma mémoire est bonne une fonction est transformée en jump quand c'est compilé, si tu ajoutes à ça la variable passée en paramètre ça fait utiliser un peu plus la pile, les 2 combinés ça donne quelques cycles processeur en plus.
L'exemple typique c'est les algos récursif, très simple, mais plus lent et dangereux de temps en temps ^^.

Envoyé par Thamior

Bah, mettre le code d'une routine directement dans l'interruption t'évites d'avoir à faire un saut vers le code de ladite routine et de revenir vers ton interruption une fois la routine exécutée, c'est de l'inlining en fait. Ça t'économise donc un certain nombre d'instructions. Faut voir l'impact que ça à sur ce microcontrôleur spécifiquement, mais la comme ça je dirais que c'est ça qui te fait gagner du temps.

Oui, ça je m'en doutais, mais j'avais été étonné du temps gagné (plusieurs µs).

Envoyé par Le_CuLtO

Mais ça doit jouer sur pas grand chose, là tu as l'air de dire que ton programme devient hyper lent.

Envoyé par Thamior

Pour les float, par contre, sans ton code, moi je ne m'avancerais pas.

Oui ça devenait plus que lent, du genre 30s pour l'affichage du menu principal (le premier truc fait une fois l'interruption activée), de même (voir pire) pour le reste...
Ensuite mon code, j'ai celui de l'interruption qui n'a pas grand chose d'extraordinaire, mais pour les floats c'était vraiment des trucs basique, je me souviens avoir testé des trucs genre :

Code:

float Nombre = 3.3;
Nombre = Nombre*2;

Le tout dans une fonction jamais appelée, ben ça se mettait à ramer.
Ça m'a pas mal perturbé ce truc (ça et le fait que le programme pouvait rentrer dans un if alors que la variable testée n'était pas dans l'encadrement, mais je pense que c'était le débuggeur qui foutait sa merde là).

**Anonyme20240202** · 11/09/2011, 03h38

Question facile en bash :

Je suis sous windows 7 avec cygwin et j'essaye d'exécuter ça :

Code:

 #!/bin/bash
OPTIONS="Hello Quit"
select opt in $OPTIONS; do 
if [ "$opt" = "Quit" ]; then 
echo done
exit
elif [ "$opt" = "Hello" ]; then 
echo Hello World
else
clear
echo bad option
fi
done

Et j'ai une erreur : Erreur de syntaxe près le symbole inattendu " $'do\r' " ligne 3.

Quelqu'un peut me dire ce qui va pas avec ce script?

J'pense que c'est un problème du au fait que j'utilise cygwin.

EDIT: Ouais et quand je fous des espaces après le do, enfin que je vire les symboles "invisibles" de retour à la ligne et tout que windows fout sous l'éditeur de texte j'ai toujours des erreurs.

EDIT 2: Ouais quand je copie colle le script dans la console cygwin ça marche parfaitement...
Je copie colle mon script dans un fichier sh et quand j'essaye de l'exécuter j'ai l'erreur que je décris plus haut...

**DaP** · 11/09/2011, 07h49

Le \r ça sent un peu le problème de CRLF. Essaie d'enregistrer le fichier au format « Unix » (avec les sauts sur un octet au lieu de deux). Je ne sais pas si il y un nom officiel pour ça.

**Møgluglu** · 11/09/2011, 10h49

Envoyé par Robix66

Premièrement, on remarque qu'entre le moment où Truc passe de On à Off, il se passe beaucoup trop de temps (on ne dépasse pas la valeur de l'interruption, mais c'est trop quand même).
On colle le contenu de ChangeValeurTruc directement dans ChangeValeur, hop l'opération n'est plus anormalement longue.

C'est quoi Truc? Tes variables partagées sont bien toutes déclarées en volatile? Comment tu vois quand Truc change?

"Ok, il est très lent à utiliser les floats, je vais les enlever... wait

". Le programme ramait quand même, même si les opérations sur les flottants n'étaient pas effectuées, genre si je les mettais dans une fonction jamais appelée. Si je les foutait en commentaire, ça remarchait proprement.

Si tu n'utilises pas de float, le compilo n'incluera pas la bibliothèque de calcul virgule flottante au moment du link. Donc tu évites un gros paquet de code, ça change complètement l'emplacement de tes fonctions et tes données. Tu peux avoir un bug un peu subtil (genre accès hors limites, variable non initialisée, etc.) qui passe inaperçu quand la lib softfloat n'est pas chargée et qui déclenche l'apocalypse le reste du temps.
Idem quand tu déplace du code d'une fonction à une autre. En C on peut souvent trouver des cas où un programme à l'air de fonctionner correctement, mais ce n'est pas parce que tu as trouvé des conditions dans lesquelles ça ne plante plus que le bug est corrigé.

Aussi bien le bug n'a rien à voire avec ton gestionnaire d'interruption, mais l'erreur arrive à ce moment-là parce que tu accèdes à des données corrompues en mémoire. Bref, sans voir le code, impossible de te répondre plus précisément. Tu n'as pas un valgrind-like dans tes outils de dev?

**rOut** · 11/09/2011, 11h57

Quelqu'un ici saurait m'expliquer simplement ce qu'est une monade ?

Discussion: Le topic de la programmation, string, chaînes, cuir et compagnie

Outils de la discussion

Règles de messages