Jeudi 13 Mars

Accueil - Dimanche - Lundi - Mardi - Mercredi - Jeudi - Vendredi

Matin

Conférence de Lorenzo Alvisi (UT Austin - Texas): "Byzantine Fault Tolerance : the Long March"
Lorenzo commence son exposé en décrivant BFT (Byzantine Fault Tolerance) comme étant un spectre hantant la communauté. Le premier réflexe en tolérance aux pannes est de répliquer. Dans un système de décision, lorsque plusieurs processus répondent à une même demande faite par un client, nous utilisons des votes pour déterminer qui a raison. Les processus organisant les votes vont donc être répliquer afin d'assurer une réponse cohérente. Lorsque les pannes apparaissent sur ces voteurs, les problèmes commencent. Une solution serait de donner la tâche du vote aux différents clients. Oui, mais si les clients tombent en panne ? L'astuce est là, "We don't care about clients who fail !!".

Des rounds vont être mis en place pour gérer ces pannes. On pourrait ainsi définir les propriétés de broadcast et d'accept :

• Justesse (correctness) : si un processus correct p exécute broadcast(p,m,i) au round i, alors tous les processus corrects vont exécuter accept(p,m,i) au round i.
• Unforgeability : si un processus correct q exécute accept(p,m,i) au round j>=i et si p est correct alors p a exécuté broadcast(p,m,i) au round i.
• Relais (relay) : si un processus correct q exécute accept(p,m,i) au round j>=i', alors tous les processus corrects auront exécuté accept(p,m,i) d'ici le round j+1''.
  

PBFT (Pratical Byzantine Fault Tolerance) nous a été présenté. Il utilise un recouvrement pro-actif pour tolérer plus de fautes sur toute la durée de vie du système. Une structure hiérarchique avec des noeuds primaires (primary) et des noeuds secondaires/sauvegardes (backup) est définie. Ici, Lorenzo affiche un slide intitulé : ''What could possibly go wrong? :

• primary is faulty
• backup are faulty
• ...
• Carla Bruni could start singing !''
  

On termine cette présentation avec Zyzzyva issu du dernier article de Lorenzo.

Après Midi

Conditions météo : soleil, soleil, soleil et d'après Lorenzo Alvisi sa chemise Texane y est pour quelque chose !
Enneigement : neige fraîche quoique légèrement lourde.

Ah la plus belle journée du séjour, ciel bleu, aucun nuage à l'horizon (sauf autour du sommet du Mont Blanc). Bref, on dévale les pentes sans compter, la fatigue accumulée a disparu et le temps passe bien trop vite à mon goût. La conférence du soir a été décalée de 30 minutes pour nous permettre de profiter plus longtemps des pistes.
Comme c'est le dernier après-midi ski, j'en profite pour vendre la qualité des pistes de La Plagne. Bien sûr, le domaine est vaste donc 3 après-midis n'ont pas suffi à découvrir tous les recoins. L'autre avantage de cette station est la difficulté bien dosé des pistes. On trouve des bosses un peu partout donc pour les fans de sauts c'est excellent. Seul petit bémol, le prix, comptez 32€ pour une demi-journée. Mais bon c'est La Plagne ...

Soirée

Conférence de Roberto Baldoni (University of Rome): "Scalable Publish/Subscribe Infrastructures"

Roberto commence son discours en précisant de quoi la présenatation ne parlera pas ! De Football. Il est fan de la Lazio de Rome malheureusement celle-ci ne joue pas très bien en ce moment et, pour enfoncer le clou, la Roma (ennemi juré de la Lazio) est la seule équipe italienne encore en lice en Champions League !!

Dans cette problématique, nous avons 2 entités :

• Les clients.
• Les services publiés par un tiers.

Dans le cadre, d'un réseau à grande échelle, il est impossible de centraliser les publieurs. Il faut donc mettre ne place une façon pair-à-pair pour reguler tout ça. Ainsi chaque noeud possède des informations sur d'autres noeuds du réseau. Chaque service est vu comme un espace auquel on s'abonne. Une fois intégré au groupe représenté par cette espace, le client recevra toutes les informations de mise à jour ... Avec l'utilisation de pair-à-pair se pose le problème des requêtes complexes.
Prenons un exemple : disons que je suis interessé par toutes les infos concernant La Roumanie. Je m'abonne donc au groupe news.romania.info. Je reçois maintenant une news toutes les 10 minutes sur la situation en Roumanie. Cela ne me convient pas, je ne désire recevoir plus que les informations "positives" sur la Roumanie. Que dois-je faire ? Plusieurs solutions sont possibles :

• M'abonner à newspositives.romania.info -> le problème est que l'on ne souhaite pas multiplier les services, pour qu'un groupe ait une consistance il faut un minimum d'inscrits. On ne va pas créer une groupe pour chaque demande spécifique.
• Demander au responsable de l'espace news.romania.info de ne m'envoyer que ce qui m'intéresse. Problème : la mise à l'échelle deviendrait impossible.
• Mettre en place des filtres au niveau client : c'est la meilleure solution. Ainsi je continue à recevoir toutes les infos de news.romania.info seulement je rejette toutes celles qui ne sont pas positives.

Pour l'envoi de messages, on emploie les méthodes de flooding, gossip, rendez-vous ... Nous avons ensuite vu quelques exemples de plateformes :

• Siena
• Scribe
• Tera