J'ai jamais vraiment abordé le fonctionnement que j'ai choisis pour ce projet. Le principe est simple : un module principale (le nom n'est peut-être pas très bien choisi) au centre du système attend la connexion de tous les autres modules et redistribue les messages reçus vers les modules concernés. Chaque module, à la connexion, précise les messages qu'il veut recevoir, et réagit en fonction des messages qu'il reçoit, en envoyant d'autres messages.

L'idée derrière tout ça est de bâtir un système programmé par évenement : le fonctionnement du programme ne serait qu'une suite d'évenements dont certains seraient la conséquences d'autres, et les autres produits par le matériel sous-jacent (le réseau en l'occurence). L'ensemble communique via des sockets ordinaires, permettant une distribution du système sur plusieurs machines si nécéssaire.

Pour me faciliter la tâche, notamment en ce qui concerne toutes les communications réseaux, je me suis fait une petite bibliothèque de socket qui fonctionne par évenement. Elle commence à devenir mature, puisque je ne la retouche quasiment plus et qu'elle réagit exactement comme je le souhaite (distribution des évenements, bloquante mais pas trop, gestion correcte des déconnexions, etc.). Par dessus cela, j'ai rajouté une couche de protocole pour mettre en forme un minimum la communication. L'échange d'information se fait sous forme de texte. Les données sont envoyées structurées grace à des dictionnaires en python qui sont écrit grace au module pretty print et lu grace à la fonction eval(). Je n'ai donc presqu'aucun travail d'analyse de flux à faire, et la sérialisation se fait toute seule.

Au final, l'écriture d'un module est rendu triviale. Il suffit d'instancier une classe CyberrailConnection, d'enregistrer les type de message qui nous interesse et auxquels sont associés des callback, et enfin d'appeler la fonction main() de cette classe. La négociation avec le module principal se fait tout seul et les évenements arrivent directement. Le module principale envoie toujours au début un message de bienvenue permettant au module de reprendre la main s'il a envie d'initier une communication.

Je pense avoir fait le gros du travail sur la couche de communication entre processus. Le fait de faire découpage clair permet une conception bien plus robuste du système, c'est un avantage non négligeable.