Discussion :

[lucho31]

Bonjour,

J'ai un petit soucis concernant la facon dont la queue est geree dans une IO::Socket::INET.

En fait, j'ai des evenements (que je ne controle pas) qui declenchent un script bash.
Il peut y en avoir plusieurs centaines et ils sont traites sequentiellement, chacun appelant le script bash lorsque l'evenement precedent est traite.
Pour faire simple, ces evenements sont de 2 types et c'est pourquoi j'aimerais mettre en place 2 daemons qui seraient utilises de la facon suivante:
- un evenement est declenche
- il declenche a son tour la script bash
- ce script determine la nature de l'evement (a l'aide d'une variable d'environment)
- en fonction du type d'evenement, il contacte un des 2 daemons
- le daemon fait sa tache

J'ai commence a faire des tests et ca m'a l'air de bien marcher mais j'ai un point qui me semble bloquant...
Avec un peu de code, c'est plus parlant... :-)

Script event.sh declenché par l'evenement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
...
port=""
if [ "$type" = "type1" ];then
   port=3333
else
   port=3334
fi
perl client.pl $port<<EOF
des infos concernant l'evenement
EOF
...

Script client.pl

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
#!/usr/local/bin/perl   
use IO::Socket;   
 
# Get port number (pour savoir a quel daemon le client doit envoyer ses donnees)
my $port = shift;
my @infos = @ARGV;
my ($value1, ...)=split(' ',@infos);
 
$sock = IO::Socket::INET->new(  
		Proto => "udp", 
		PeerPort => $port  ) or die "Cannot open socket on port $port.\n";
 
print $sock "$value1 $value2 ..."

Script daemon1.pl (le daemon2.pl est identique a part qu'il tourne sur un autre port)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
#!/usr/local/bin/perl -w
 
use IO::Socket;
 
$sock = IO::Socket::INET->new(
   LocalPort => 3333,
   Proto     => 'udp'
   ) or die "\nCannot create server.\n";
 
print "\nSERVER IS RUNNING\n";
while(<$sock>){
	my $params = $_;
        # fait_des_trucs_avec_ces_params();
	sleep(5); # pour simuler un traitement qui prendrait plusieurs secondes
}

Alors en fait le probleme c'est que si je simule une centaine d'evenement (un while qui declenche le event.sh 100 fois),
je vois que le serveur prend les evenements un par un (normal) mais en fait il en effectue qu'environ 70 (!!!).
L'explication que je vois... comme le temps de processing d'une requete par le serveur peut prendre quelques secondes,
et que les requetes s'accumulent donc dans la queue (les 100 evenements et tentative de connexion au serveur sont creees en environ 5 secondes...), est ce qu'il y aurait des demandes de connexion qui sont perdues....
Est ce qu'il y par defaut un nombre de process max qui peuvent tenter de connecter le serveur et qui sont mis dans la queue?

DEsole d'avoir fait un post si long.

Merci beaucoup pour votre aide,
Bonne soiree,

Lucho

[Woufeil]

Bonjour,

Bien que je ne sois pas persuadé que le problème vienne de là, tu peux essayer de fixer l'attribut Listen de ton scoket serveur à 100, le problème vient peut être de là.
Regarde le CPAN pour plus de détails

[lucho31]

Bonjour,

En fait j'ai essaye d'ajouter un param Listen mais an faisant cela je n'arrive plus a lancer le serveur... j'ai un message d'erreur....bizarre.

En tout cas merci pour ta reponse, je vais regarder cela plus en details.

Luc

[Woufeil]

Bonjour,

En fait j'ai essaye d'ajouter un param Listen mais an faisant cela je n'arrive plus a lancer le serveur... j'ai un message d'erreur....bizarre.

En tout cas merci pour ta reponse, je vais regarder cela plus en details.

Luc

C'est surement parce que tu n'utilises pas la métode accept dans ton serveur...
Je viens de penser, dans la doc officielle, il y a une partie très intéressante sur les sockets (section III, la partie sur les ipc). Lit la, tu y appendras sûrement deux trois truc intéréssants

[lucho31]

Merci c'est cool je vais regarder cela.
En fait je n'utilisait pas la methode accept parce j'avais l'impression qu'elle etait implicitement appelee lorsqu'une socket cliente se connectait... (je pensais (betement) que c'etait un fonctionnement propre a IO::Socket::INET ).
Merci beaucoup,
Lucho

[lucho31]

Merci,

effectivement avec la methode accept (qui n'est pas du tout appelee par defaut ) ca marche mieux.
Par contre, je viens de me rendre compte d'un autre probleme, je pense qu'il doit y avoir des best practices la dessus mais Google ne me donne pas grand chose...
En fait, il faudrait que le script bash, a chaque fois qu'il est execute, mette des params dans une queue (2 queues en fait, une pour chaque daemon) qui serait lu par les daemons... le probleme, c'est la synchro pour les ecritures par le shell et la lecture par les daemons perl. La premiere chose qui vient a l'esprit c'est l'utilisation de fichier mais j'ai un peu peu peur que niveau perf ca ne soit pas vraiment optinal.
Est ce que tu aurais une idee la dessus ?
Merci beaucoup,
Luc

[Jedai]

Habituellement on communique avec les démons sur un autre socket (ou un Pipe nommé), et on utilise select() dans les daemons pour savoir si il y a quelque chose à lire sans bloquer le processus. Tu peux utiliser IO::Select par exemple pour faire ça à un niveau un peu plus haut (il y a encore plus évolué, mais tout dépend de tes besoins).

--
Jedaï

[lucho31]

Hello,

Merci beaucoup, je vais jeter un oeil la dessus, je ne connais pas cette methode.

Sinon, j'ai fait autrement, (je ne sais pas si c'est mieux comme ca mais je m'affranchit des communications par socket et de la gestion d'erreur associee):
mon script bash cree un petit fichier (nom du fichier: id de l'evenement, et 4 parametres dans le contenu du fichier) ce qui fait pas mal de fichiers mais il sont tres petits. Ces fichiers sont crees dans un des 2 repertoires et les daemons viennet lirent, processer et effacer ces fichiers. C'est assez simple c'est vrai mais finalement je pense que ca devrait faire ce que je veux en fait (mettre la charge sur les 2 daemons et ne plus avoir d'evenements en attente dans la queue principale). Qu'est ce que vous pensez de cette approche ?

Merci beaucoup pour vos conseils.
Lucho