lundi 29 octobre 2007

Tests de VCS distribués

Je suis depuis quelques temps à la recherche d'un nouveau VCS (Version Control System). J'utilise habituellement Subversion, qui a l'avantage d'être répandu. Mais le versionage centralisé commence à montrer ses limites. La goutte d'eau qui a fait déborder le vase a été le serveur SVN du LCA auquel je n'ai pu accéder a cause d'un glitch administratif, et qui nous a poussé à héberger l'arbre de CaveShooter sur un serveur à part, et la perte de temps qui s'en est suivie.

Quatre VCS distribués ont retenu mon attention pour l'instant: Bazaar, Darcs, Mercurial et Monotone.

J'ai eu tenté de migrer vers Arch (l'ancêtre de Bazaar) il y a quelque temps, mais j'ai trouvé l'interface rébarbative. Il semblerait que Bazaar aie porté le focus sur la facilité d'utilisation; c'est probablement une bonne chose.

Darcs prétend fournir des merges plus puissants, étant basé sur la "théorie des patches". L'interface est en revanche assez différente des VCS que je connais pour être déstabilisant.

Mercurial est très façile a prendre en main pour un utilisateur habitué à Subversion, la migration étant quasiment transparente.

vendredi 26 octobre 2007

CaveShooter 0.2

La programmation de CaveShooter avance gentiment:
  • La machine d'états TCP inclut maintenant le système de discussion et les join/part des divers participants.
  • Côté UDP, un nouveau trick de multithreading permet d'avoir des ticks un peu plus réguliers.
  • Les Magic Numbers manquants ont été corrigés
  • La logique de jeu a évolué, les objets sont maintenant capables de se déplacer, le tir devrait suivre sous peu.
  • La structure dans caveshooter.protocol.* a été revue et concerne maintenant la sérialisation/désérialisation des messages udp uniquement, le reste étant géré par les clients et serveurs respectifs

mercredi 24 octobre 2007

Configuration de l'équipement réseau

J'ai commencé à reconfigurer les équipements en accord avec le nouveau schéma d'allocation choisi.

Il semblerait que le protocole de trunking utilisé par le Dell 6224 soit incompatible avec les autres équipements Dell que nous avons (5224 et 3424); sur les switches que nous avions, le vlan 1 est considéré comme le vlan par défaut, et ses paquets ne sont jamais taggés, mais toujours envoyés tels quels sans étiquette de vlan. C'est une mesure de compatibilité; un client qui ne comprend pas les vlans 802.1q et se retrouve accidentellement connecté à un port trunk sera vu comme appartenant au vlan 1.

Sur le 6224, les paquets appartenant au vlan 1 sont taggés quand ils sortent par un port trunk. C'est probablement une mesure de sécurité, soit pour empêcher un client hostile du vlan 1 d'injecter des paquets a destination d'autres vlans à travers un port trunk.

La différence entre ces deux modes de gestion empêche les paquets du vlan 1 de traverser les port trunk entre le 6224 et les autres modèles. Il faudrait passer les trunks entre les backbones en mode générique, pour forcer les paquets du vlan 1 à sortir en mode non-taggé, ou ne plus utiliser le vlan 1 du tout. Pour l'instant, je retiens la 2e solution, qui est plus simple à configurer, mais empêche un client mal configuré de fonctionner sur un port trunk (ce peut être un mal ou un bien, en fonction de la situation)

Je pense également placer Loulou dans un micro-subnet à part, de manière a faire tout transiter par le 6224. Ca permettra à tous les autres équipements du réseau de n'avoir a configurer qu'une entrée de routage par défaut.

Le système de génération des configurations a été mis a jour pour inclure le nouveau schéma de vlans, et mettre les ports utilisateurs dans le vlan 2 par défaut.

mardi 23 octobre 2007

La structure réseau se met en place

On commence gentiment à planifier la topologie du réseau pour PolyLAN X.

Comme nous ne sommes pas certains de la performance qu'apportera la segmentation du réseau, nous allons prévoir quatre subnets pouvant accomoder ~ 500 machines chacun. Au début de la LAN, tous les participants seront dans un subnet unique, et nous couperons le réseau en 2 segments de 200, ou 4 segments de 100, si nécessaire.

La classe d'allocation 10.0.4.0/24 sera gardée pour le vlan administratif de l'équipement réseau. Nous utiliserons 10.1.0.0/16 à 10.4.0.0/16 comme subnets opérationnels. Dans ces subnets, 10.x.0.0/24 sera réservé pour les serveurs multihomed, tandis que 10.x.2.0/23 sera une classe libre à allouer aux joueurs.

Pour ce faire, nous abandonnons l'utilisation du proxy-arp. Premièrement, cette technique n'apporte qu'un faible avantage par rapport à des subnets distincts. Avec des subnets distincts, déplacer une machine de segment requiert de la déconnecter pour lui réallouer une adresse différente, tandis qu'avec le proxy-arp, même si l'adresse peut rester la même, il est quand même nécessaire de purger la table arp pour que le réseau fonctionne correctement, mais également de purger les entrées relatives a ce client sur toutes les autres machines. En pratique, on devra donc se baser sur le timeout arp pour faire expirer ces entrées, ce qui est peu pratique et exclut l'utilisation d'un timeout large. Or, nous comptons sur l'utilisation d'un timeout large pour réduire le traffic ARP.

Deuxièmement, l'architecture en subnets permet aux applications de savoir qu'elles ne communiquent pas avec des machines locales. Le proxy-arp peut en théorie rendre impossible le fonctionnement de certaines applications, et nous manquons de temps pour tester.

Pour permettre a tous les joueurs de voir tous les serveurs, les serveurs découvrables par broadcast (CS, BF ?) seront tous multi-homed; chaque serveur disposera d'une adresse dédiée pour chaque subnet différent.

Pour réduire encore plus le traffic de broadcast, nous installerons un serveur WINS, et demanderons si nécessaire a nos joueurs de configurer leur machine en p-mode (pas de broadcasts netbios). J'essaierai de bricoler qqch pour envoyer des messages popups aux machines fonctionnant en b-mode.

vendredi 19 octobre 2007

SpaceShooter devient CaveShooter

Le projet du cours sc250 pour l'année 2007 s'appelle désormais CaveShooter. Plus question de vaisseaux spatiaux, mais des hommes des cavernes opérant des catapultes pour lancer des rochers.

Côté implémentation, Aris a terminé les classes du modèle, et a attaqué la vue graphique; j'ai implémenté le serveur TCP, la machine d'états pour le prologue TCP, et le receveur UDP.

Le code est versioné avec SVN sur Xolus, mais je me demande sérieusement si je ne vais pas migrer vers Bazaar.

mercredi 17 octobre 2007

Résolu les crashs sur Fifi, structure réseau finalisée

Le plantage systématique de Firefox sur Fifi a été résolu. Apparemment, il s'agit d'un bug dans le driver ATI de X.org, propre à un modèle de carte particulier (ATI Rage IIC). L'accélération 2D hardware a été désactivée (option NoAccel de X.org), le système ne plante plus.

L'organisation réseau a été finalisée pour PolyLAN X. Nous aurons 3 subnets dans des VLANs séparés, respectivement 10.0.[1,2,3].*, pour les joueurs. 10.0.x.1 sera reservé pour le routeur Dell. 10.0.x.2 sera réservé également pour Fifi, qui aura besoin d'un accès a tous les domaines de broadcast pour le monitoring DHCP notamment.

Chaque joueur se trouvera dans un VLAN correspondant initalement au tournoi correspondant (CSS, RTS, et Autres). Il sera possible de changer dynamiquement de VLAN via une interface web, mais chaque VLAN sera limité à 200 personnes.

mardi 16 octobre 2007

Ouf

Ma demande de déplacement pour mon service militaire a été acceptée. Je vais pouvoir finir mon PDM tranquille, j'aurai tout le temps nécessaire pour m'occuper du milliard de choses que j'ai a faire. Champagne !

SpaceShooter v2.0

Aujourd'hui, j'ai commencé a travailler sur SpaceShooter "v2.0", le projet qui sera proposé en cours de réseaux pour les 2e SSC/3e informatique. Je ne peux pas en dire beaucoup pour l'instant, mais tout est dans le nom... le jeu ressemblera à celui que nous avons utilisé en 2004, mais avec de nombreuses améliorations, et un protocole réseau largement différent.

Comme de juste, Aris s'occupera du client et moi du serveur. C'est toujours amusant de revenir sur du vieux code qu'on a écrit...

A la fin du projet, je pense qu'on pourra publier ici le petit jeu, histoire de s'amuser un peu.

lundi 15 octobre 2007

Nouvelles de PolyLAN 0xA

PolyLAN X (0xA pour les intimes) approche à grand pas (10-11 novembre, pour les pas encore inscrits). Je travaille toujours sur PLT; cette version-ci va voir venir de nombreux changements clef.

- LLDP est maintenant activé sur les ports tronc du réseau. Un module est en cours de développement, qui permettra de récupérer la topologie en live sur le réseau de production (fini les incohérences avec l'affichage des liens). Auparavant, le système pouvait seulement vérifier la cohérence a l'aide des tables de forwarding.
- Beaucoup de paramètres codés en dur sont maintenant configurables depuis un endroit central (PolyLAN/Config.pm), ce qui facilitera l'installation du software sur un autre système.
- Le système de quarantaine a été remis a niveau (il était abandonné depuis l'introduction de l'authentification par 802.1x), les vlans sont maintenant configurables depuis une position centrale; le mécanisme de configuration des switches y a été adapté
- Les switches sont maintenant reconfigurables automatiquement également par tftp et plus seulement via le port série (si la configuration actuelle du switch le permet)

Nous avons également reçu un routeur Dell 6224 qui sera le nouveau coeur de notre réseau. Nos 400 joueurs seront divisés en 3 vlans (correspondant par defaut au jeu qu'ils ont choisi). Chaque vlan sera un subnet séparé, pour réduire le traffic de broadcast. Il sera possible de changer en cours de LAN, nous n'avons pas encore décidé comment. (manuellement, interface web, semi-automatique ?)

Il sera maintenant possible pour un joueur d'obtenir plusieurs adresses IP sans déclencher une alarme. Il n'y aura plus d'alarme lorsque un joueur change de carte réseau par exemple. En revanche, chaque adresse MAC se verra associer durablement une adresse unique, et le système gardera trace du propriétaire de chaque machine.

Encore une migration

Voila, j'ai encore une fois migré de plateforme pour raconter ma vie. Ce blog fait suite à la défunte installation DotClear que je n'avais plus le courage de maintenir. Je vous encourage à mettre a jour vos bookmarks vers cette nouvelle addresse (http://blafh.blogspot.com).
 
Also check me out on Mastodon