juillet
2008
Nous allons maintenant nous pencher sur les fonctionnalités communes à toutes applications (ou presque) d’un contrôleur maitre.
Comme dit précédemment le contrôleur maitre permet de gérer les problèmes de sécurité lié à la décentralisation du réseau.
Celui-ci devra alors être à même de :
– Controller aléatoirement des paquets en les demandant aléatoirement à des utilisateurs
– Réceptionner tout les hash d’intégrité de tous les paquets (envoyé par le client émetteur au contrôleur)
– Réceptionner le hash d’un paquet afin de valider son intégrité au client demandeur
– Tenir à jour une liste de client connecté/déconnecté
– Empêcher des utilisateurs d’émettre.
– Définir un client de confiance comme contrôleur maitre secondaire.
Bien entendu, le client doit être à même de communiquer avec ce contrôleur. C’est pourquoi, ils partageront la même architecture.
Il nous faut tout d’abord définir l’architecture du logiciel ainsi que toutes les interactions client-contrôleur afin de normaliser les échanges. (Partie Design Logiciel). Comme nous verrons cette étape de création dans l’article 12 (ainsi que le code en C#/.NET) nous nous contenterons pour le moment de définir ces fonctions :
– Le contrôle aléatoire des données se fera simplement à partir d’un random sur la liste d’utilisateur, ou le contrôleur lui demandera de lui envoyer tous les paquets reçu durant la période t, afin de pouvoir les analyser. En fonction du résultat de ces analyses, la liste des utilisateurs et des avertissements seront changées.
– La réception des hash d’intégrité se fera simplement par la réception d’une empreinte de 128bits à laquelle il associera un id dans un array. (id = iduser + idpaquet + rdm)
– En cas de réception d’une demande de vérification de la part d’un user, le serveur retrouvera le hash grâce à l’id et le comparera à celui envoyé par le client. Si les hash correspondent le client pourra alors utiliser le paquet.
– Le serveur émettra un ping vers chaque clients toutes les dix secondes afin de vérifier leur état. Dans le cas où le client est déconnecté, un message broadcast permettrait de retirer cet utilisateurs de toutes les listes de peers. Dans le cas d’une connexion, la même technique serait utilisée.
– Pour empêcher un utilisateur d’émettre/recevoir, un message broadcast informerait les clients de l’ajout en liste noire de tel id. Les messages en provenance de cet id seront alors automatiquement refusé, et plus aucun envoi ne lui serait fait. L’utilisateur fraudeur sera alors coupé du réseau.
– Afin de pouvoir définir un client de confiance comme contrôleur secondaire (en cas de montée en charge importante ou en cas de problème technique) il faut que les clients intègrent nativement le code de contrôleur maitre mais avec quelques restrictions (aucun ban possible, ne peut définir d’autres contrôleur maitre,…) Ainsi même en cas de panne serveur ou de montée en charge, l’utilisation de contrôleurs maitres secondaires permettrait de ne jamais être confronté à un réseau indisponible.
Ces fonctions permettent de maintenir un minimum de sécurité dans un réseau décentralisé (le contrôleur maitre pouvant être un utilisateur, le serveur est optionnel).
Bien sur, toutes ces fonctions sont à adapter selon les situations et selon les applications voulues. Elles ne sont là que pour représenter un contrôleur dit « générique ».
Comme prévu, prochain article, fin de semaine.