Discussion :

[noobC]

Bonjour,

Voilà tout est dans le titre, donc pour préciser j'ai une appli cliente qui envois des requêtes à un serveur. Seulement je ne peux envoyer que 2 requêtes simultanément (sachant qu'elles peuvent être envoyé de plusieurs pc différents).
J'ai pensé à un "repère" dans un fichier ou une base avec un calcul par la suite du temps entre la requête actuelle et la deuxième (lorsqu'on est à 2 requêtes), pour faire une tempo.

Si quelqu'un à une idée d'algo? Et quelle serait la meilleur solution?

Merci

[tim974]

Je sais pas si ça existe en PHP, mais le principe des sémaphores peut t'apporter une solution.

[wiztricks]

Bonjour,
Permettez moi de reformuler!
Vous avez des applications clientes sur plusieurs PC qui envoient des requêtes à un serveur.
Vous voulez limiter le nombre de requêtes simultanées expédié par

1. chaque client,
2. l'ensemble des clients

- W

[noobC]

oui je connais les sémaphores en C mais je vois pas de rapport direct pour cet exemple (à creuser).

Vous voulez limiter le nombre de requêtes simultanées expédié par

1. chaque client,
2. l'ensemble des clients

En fait il s'agit d'un ensemble de client qui interroge un webservice. Comme ce serveur est sollicité par d'autres appli et qu'il regroupe plusieurs webservice, je dois contrôle coté client, donc limité l'envois pour l'ensemble des clients . L'appli en developpement est centralisée (j'aurais dû le préciser dans le post précédent)

[wiztricks]

2 solutions.

jeton : le client attend d'avoir reçu un jeton du serveur avant d'expédier sa requête.
=> si le client ne soumet pas de requête, comment le serveur regénère le jeton?

famine : le serveur ne traite simultanément qu'au plus deux requêtes, les autres requêtes client "attendent" - et les clients soumettent les requêtes suivantes après avoir reçu la réponse à la requête en cours.

Il est en général plus simple de limiter la capacité de traitement côté serveur que de faire fonctionner un algorithme distribué (beaucoup de tests à faire pour couvrir tous les cas de figures).
Mais "comment" dépend beaucoup de l'architecture de votre serveur.
- W

[noobC]

la méthode du jeton n'est pas envisageable parceque je n'ai pas accès au serveur. Pareil pour la "famine", le serveur à sûrement une gestion de ce type mais de toute facon je dois respecter le cahier des charges.

C'est pour ca que j'avais commencé par inscrire dans un fichier les chiffres 1 et 2 pour le nombre de requêtes. A chaque requête j'allais lire le chiffre et j'envoyais ou non ma requête. Par contre fonctionnellement c'est pas super donc je m'oriente vers le javascript pour indiquer une tempo.
Cette solution me parait tout de même bancale parceque j'imaginais aussi faire une comparaison sur les heures, minutes, secondes où sont exécutés les requêtes, parcequ'au final le principe il est là: surcharge coté serveur.

[wiztricks]

Galère votre truc.

C'est pour ca que j'avais commencé par inscrire dans un fichier les chiffres 1 et 2 pour le nombre de requêtes. A chaque requête j'allais lire le chiffre et j'envoyais ou non ma requête. Par contre fonctionnellement c'est pas super donc je m'oriente vers le javascript pour indiquer une tempo.

Est ce que cela signifie que l'on peut contrôler le nombre de requêtes faites par un client?
Est ce que le nombre de clients est fixe?
-W

[noobC]

Est ce que cela signifie que l'on peut contrôler le nombre de requêtes faites par un client?

C'est un point qu'il faudra que je vois avec mon chef de projet quand il sera de retour^^. Mais je pense qu'il faut contrôler le nombre de requêtes globalement envoyés au serveur. Pas de filtrage par poste donc.
Concernant le nombre de client je le connais pas.

[Djakisback]

Salut,
est-ce que tu peux préciser quelles types de requêtes ? est-ce que le client a besoin de savoir si sa requête a été effectuée directement ou non ?
Sans la main sur le serveur ca semble effectivement un peu compliqué.
Une solution serait de mettre en place une petite appli sur un autre serveur qui gère des pools de requêtes et que ce soit elle qui communique avec le serveur de données (encore faut-il qu'il accepte les connexions extérieures).
Y a ptêtre aussi moyen de mettre en oeuvre un pool dans des fichiers ou dans une bdd et d'appeler un script à partir d'une tâche cron si le serveur le permet. Si tu enregistres l'id de session du client en plus de la requête, tu peux lui mettre un message comme quoi il reste des requêtes à lui dans la bdd.
Sur certain sgbd tu peux récupérer le nombre de connexions je crois, tu pourrais donc aussi envoyer directement un message au client pour lui dire que le système est occupé et lui dire d'essayer ultérieurement.

C'est juste des idées y a ptetre plus simple...

[noobC]

Il s'agit d'un service web et comme l'appli cliente est en php j'ai décidé d'utiliser SOAP.

Si tu enregistres l'id de session du client en plus de la requête, tu peux lui mettre un message comme quoi il reste des requêtes à lui dans la bdd.

Je compte pas checker chaque client.

Sur certain sgbd tu peux récupérer le nombre de connexions je crois, tu pourrais donc aussi envoyer directement un message au client pour lui dire que le système est occupé et lui dire d'essayer ultérieurement.

Là faut voir, ca semble pas trop mal. Je chercherai de ce coté en attendant d'autres idées. merci


edit: je suis peut etre pas très clair donc si je me répète et bien c pas grave^^. Donc mon but s'est de limité l'envoie de requête au webservice, avec un controle depuis l'appli web coté client.

edit solus:

Bon je vais résumer.
J'ai utilisé une bdd finalement, avec une table qui enregistre les la requêtes envoyées et place un champs "etat" à 1 pendant l'envois.
Au retour je stock le résultat (ds la mm table) et je passe le champs "etat" à 0.
Donc avant chaque envois de requête je consulte la table et compte le nombre d'état à 1: si inférieur à n je peux envoyer sinon j'alerte l'utilisateur d'une manière quelconque.
Si il y a eu un problème du programme (mais qu'il est toujours "utilisable") et que la reponse n'a pas pu nous être parvenue et bien je replace le champs etat à 0.
Si la requête et le resultat sont présent en base et bien il est inutile d'aller réinterroger le serveur.