(Courriels de diversion: <sinuosites@tronquerez-phonologue.com> <reactualiserez@deguerpiraient-soulevent.com> <dilapideriez@privilegiant-electoralistes.com> <melodiques@grossiere-ruinees.com> <collets@medailles-sous-marinier.com> <rongeant@dorlotes-propagent.com> <noueras@elevons-assembla.com> <econduise@confondrai-devêtiraient.com> <seches@galaxie-pouliner.com> <raboterais@roulotte-dissonante.com> )
Cahier des charges: * gérer l'état du jeux (position du robot et des différents obstacles) * permettre de modifier l'état du jeux, et transmettre les ordres en conséquence à la table tracante * sortir l'état du jeux sous forme d'un GIF (pour affichage dans un navigateur) * accepter des requêtes depuis un programme exterieur (le serveur web par exemple). La première contrainte interdit l'utilisation de l'interface CGI, car il faut maintenir des informations globales au delà de la durée d'une requête, et gérer les accès concurrents à ces informations. Ca interdit également l'utilisation d'un serveur forking pour les mêmes raisons: les fils ne peuvent pas modifier l'état global car il n'est pas dans leur espace d'addressage; il faudrait passer par un système IPC complexe. Un serveur sérialisant poserait le problème des accès concurrents: un seul client lent pourrait bloquer tout accès au jeux pendant toute la durée de sa connexion. Je pense à une architecture de serveur HTTP multithread. Il accepte des requêtes du style "GET /image" qui lui renvoi un GIF de l'état du jeux, "GET /move?x=3&y=4&d=2" pour déplacer le contenu de la case (3,4) vers l'est, etc. Chaque requête est traitée dans un thread séparé, et les informations globales sont protégées par un sémaphore. Le serveur tourne sur un port élévé (8000 par exemple), et le Apache sur le serveur web CULTe du salon transmet toutes les requêtes ayant le préfix "/robots/" vers le port 8000 de la machine robots (en utilisant le mod_proxy de Apache). Etat d'avancement: j'avais écrit un prototype de la partie IA en Scheme (recherche de plus court chemin vers le soleil en évitant les obstacles), que j'ai réécrit en Python hier. J'ai un serveur HTTP multithread qui fonctionne à moitié. Là je pars jusqu'au 28, mais j'espère pouvoir montrer un prototype qui tourne sur savage (sans les accès à la table tracante bien entendu) avant la fin du mois. Il y aura également un peu de travail à faire pour la webcam, mais c'est plutôt trivial: il faut poller la caméra toutes les 2 secondes et écrire le fichier JPEG à un endroit donné; tout celà est indépendant du reste, ca peut même se faire sur une autre machine. -- Eric Marsden emarsden @ mail.dotcom.fr It's elephants all the way down