[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-team] serveur multiconnexions en Perl (was:Re:Perl)
On Tue, Nov 16, 1999 at 10:55:47AM +0100, Alain EMPAIN wrote:
> On Mon, 15 Nov 1999, Pascal Bleser wrote:
> > Ouaip... et pour les questions, y a mon e-mail ;))))
> Justement, un ami m'a posé un problème que je ne suis pas certain de bien
> résoudre :
> --------------------------------------------------------------------
> 1- Un serveur est connecté par TCP/IP à un interface RS/232 (lui-même
> émetteur radio /\/\-> récepteur pour acquisition de données)
>
> Dans ce cas simple pas de problème, j'ouvre un socket et entre en
> communication avec l'interface lointain d'acquisition de données. La
> lecture se fait par un simple read sur le filehandle <FILEHANDLE>. Les
> événements sont produits par l'acquisition de données, le read attend donc
> entre chaque message.
> ---------------------------------------------------------------------
>
> 2- Ce même serveur peut être connecté à un nombre non négligeable de ces
> interfaces TCP/IP->RS232 : comment ne pas bloquer sur un read particulier
> dans le cadre d'un polling général ?
Donc tu veux faire un serveur multi-connexions.
> Demander s'il y a des caractères en attente, lancer un thread par
> interface ... ?
La meilleure méthode (et la plus classique) pour gérer ce genre de problèmes
est effectivement de travailler en multi-thread (ou multi-process).
Le thread principal (aka thread 0) ne fait que:
- créer la socket, faire le bind, listen
- se mettre dans une boucle sur l'accept
Tu n'es pas sans savoir qu'un accept retourne un nouveau handle de socket/fichier
et que tu conserver le handle principal (celui sur lequel tu as fait l'accept).
Et bien, il suffit de lancer un nouveau thread (ou processus) en lui passant
cette socket (celle retournée par l'accept).
Le thread principal, après avoir lancé le nouveau thread/process, se remet en
écoute sur l'accept.
Les autres threads (les "workers"), eux, font ce qu'ils ont à faire et à la fin
du traitement, ils ferment la socket qu'ils ont reçu du thread principal.
Note que si tu le fais en multi-process et pas multi-thread, le processus
principal (qui fait l'accept) doit fermer la socket fournie par accept après
avoir fait le fork, car fork() duplique les file handles et les passe au
processus fils.
> Aucune solution ne semble triviale.
Bah, ça va, c'est relativement simple.
Mais j'ai jamais fait de multi-thread en Perl.
Déjà, je ne pense pas que les distributions Linux livrent un Perl multi-threaded.
> J'aimerais avoir raté une commande de base !
Ca doit pas être bien dur de trouver un exemple...
Consulte "man perlipc", ligne 930: il y a un exemple d'un bièsse serveur TCP/IP
multi-threaded (enfin... c'est multi-process ;)).
Mais... tu pourrais pas mettre le serveur dans inetd.conf ?
Ca se passe comment ?
Une connexion est faite en TCP/IP sur le serveur et il doit ensuite communiquer... peu importe.
Dans ce cas, il est encore beaucoup plus facile de simplement mettre le serveur
en nowait dans /etc/inetd.conf: tu recevras automatiquement le handle de la socket
passé par inetd sur STDOUT (handle 0).
Plus facile que ça... ;)))
--
-o) / Pascal Bleser ATOS Payment Systems|
/\\ \ C++/UNIX Development Aachen, Germany|
_\_v \<guru@linuxbe.org> <pbleser@atos-group.com>|
---------------------------------------------------|
University, n.: :
Like a software house, except the software's free,:
and it's usable, and it works, and if it breaks:
they'll quickly tell you how to fix it, and ...:
---------------------------------------------------'
---------
Visit the Linux Supertore Online: http://www.redcorp.com !
If you want to be deleted from the list, send a mail to
majordomo@rtfm.be with "unsubscribe linux-team" in the body.
Archive of the list: http://tania.be.linux.org/