Bonjour à tous,
Une fois n’est pas coutume, ce ticket traitera de la technologie Silverlight et vous montrera via un petit exemple comment bouger simplement une image avec la souris (Surface-Like).
Commencez tout d’abord par créer un Canvas ainsi qu’une image à l’intérieur de celui-ci.
<Canvas x:Name="diapcontain" Margin="-326,-78,-238,-174">
<Image x:Name="diap1"Source="SIMG.JPG" Opacity="0.7" MouseLeftButtonDown="Image_MouseLeftButtonDown" MouseLeftButtonUp="diap1_MouseLeftButtonUp" MouseMove="diap1_MouseMove" />
</Canvas>
Attribuez aussi les event handler MouseLeftButtonDown/Up ainsi que MouseMove.
Une fois ceci fait nous allons demander à l’image de suivre les déplacements de la souris. Seulement l’image suit la souris dès que celle-ci la survole.
Canvas parent = (Canvas)this.diap1.Parent;
Point p = e.GetPosition(parent);
double x = p.X - offsetX;
double y = p.Y - offsetY;
diap1.SetValue(Canvas.LeftProperty, x);
diap1.SetValue(Canvas.TopProperty, y);
Pour remédier à cela, il suffit de regarder l’état actuel du bouton de la souris. Nous allons alors nous servir des deux autres évènements afin de mettre à jour un Booléen.
private void diap1_MouseLeftButtonUp(object sender, System.Windows.Input.MouseButtonEventArgs e)
{
diap1clicked = false;
}
private void Image_MouseLeftButtonDown(object sender, System.Windows.Input.MouseButtonEventArgs e)
{
diap1clicked = true;
Point offset = e.GetPosition(diap1);
offsetX = offset.X;
offsetY = offset.Y;
// TODO: Add event handler implementation here.
}
Ce qui nous donne finalement pour l’évènement MouseMove :
private void diap1_MouseMove(object sender, System.Windows.Input.MouseEventArgs e)
{
if (diap1clicked)
{
Canvas parent = (Canvas)this.diap1.Parent;
Point p = e.GetPosition(parent);
double x = p.X - offsetX;
double y = p.Y - offsetY;
diap1.SetValue(Canvas.LeftProperty, x);
diap1.SetValue(Canvas.TopProperty, y);
}
}
Je n’explique pas trop le fonctionnement, mais le code me parait assez simple. Si vous avez des questions, n’hésitez pas, posez les en commentaire de ce billet.
Voilà,
Stay Tuned.
Comme vu précédemment, lorsque l’on choisit une architecture décentralisée, le problème ne vient pas du manque de puissance ou de bande passante, mais de la façon d’en utiliser le maximum.
Il faut ainsi choisir une architecture qui permette d’utiliser le maximum de chaque client. Pour cela, il faut créer une topologie dynamique (qui se met à jour en temps réel en fonction de l’environnement actuel et des clients connectés ainsi que leurs positions).
Petit détail technique : les connexions entre les clients sont effectuées en UDP et non TCP. On ne vérifie certes pas l’ordre d’arrivée ni si le paquet arrive bien, mais les connexions sont bien plus rapides (même si non persistante). Pour en comprendre les différences je vous invite à lire : http://www.devmaster.net/wiki/UDP_vs_TCP
Pour le moment rien de bien compliqué, il suffit que le contrôleur maitre attribue à chaque client une liste de diffusion. Cependant, il faut tenir compte des contraintes techniques liées au MMOx, en l’occurrence garder un ping bas entre les joueurs. Pour cela il faut limiter le nombre de « saut »/ le nombre de clients qu’un paquet devra parcourir avant d’arriver à destination.
Dans un MMOx, cette contrainte n’est importante que pour les joueurs proches (ceux qui peuvent nous voir) . Peu importe si la personne à l’autre bout de la map ne reçoit nos changements de position que 500ms après.
Pour cela, il faut créer un algorithme capable de calculer la liste de diffusions pour chaque client, ainsi que sa liste de rediffusion c'est-à-dire la liste des clients auxquels ce client renverra les paquets qu’il recevra.
Avec l’algorithme actuel (qui ne tient compte que des listes de diffusions), on obtient la topologie suivante :
Dans le cas présent, il y a 50 clients créés aléatoirement, pour un total de bande passante disponible de 18Mbit/s.
Pour la création des listes de diffusions, rien de plus simple, on choisit les n clients (ou n est définie en fonction de la capacité d’upload du client) les plus proches.
Le code permettant ceci est le suivant.
public void MakeTopology(PeerList peers)
{
for (int i = 0; i < peers.Peers.Count; i++ )
{
distancemaxCo = 0;
for (int j = 0; j < peers.Peers.Count; j++)
{
if (j != i)
{
distance = Convert.ToInt32(Math.Sqrt(Math.Pow((peers.Peers[j].posx - peers.Peers[i].posx), 2) + Math.Pow((peers.Peers[j].posy - peers.Peers[i].posy), 2)));
if (peers.Peers[i].ConnectedUpPeer.Count < peers.Peers[i].Upslot)
{
peers.Peers[i].ConnectedUpPeer.Add(peers.Peers[j]);
if (distancemaxCo < distance)
distancemaxCo = distance;
}
else if (distance < distancemaxCo && peers.Peers[i].ConnectedUpPeer.Count >= peers.Peers[i].Upslot)
{
for (int k = 0; k < peers.Peers[i].ConnectedUpPeer.Count; k++)
{
distance2 = Convert.To
Int32(Math.Sqrt(Math.Pow((peers.Peers[i].ConnectedUpPeer[k].posx - peers.Peers[i].posx), 2) + Math.Pow((peers.Peers[i].ConnectedUpPeer[k].posy - peers.Peers[i].posy), 2)));
if (distance2 == distancemaxCo || distance2 > distancemaxCo)
{
peers.Peers[i].ConnectedUpPeer[k] = peers.Peers[j];
distancemaxCo = 0;
for (int l = 0; l < peers.Peers[i].ConnectedUpPeer.Count; l++)
{
distance3 = Convert.ToInt32(Math.Sqrt(Math.Pow((peers.Peers[i].ConnectedUpPeer[l].posx - peers.Peers[i].posx), 2) + Math.Pow((peers.Peers[i].ConnectedUpPeer[l].posy - peers.Peers[i].posy), 2)));
if(distance3 > distancemaxCo)
distancemaxCo = distance3;
}
break;
}
}
}
}
}
}
}
Maintenant que chaque client sait à qui envoyer ses informations, il faut créer les listes de rediffusions.
Pour créer celles-ci, l
Le code est bien plus compliqué, c’est ce que nous verrons la semaine prochaine.
Sur ce Stay Tuned, je reste ouvert à toute suggestion ainsi qu’à toutes questions posées en commentaire.
A la semaine prochaine !
Comme convenu, voici le 3ème article de la série. Aujourd’hui, nous allons voir l’application de la technologie P2P dans un environnement critique : le jeu en ligne (contraintes multiples que nous allons voir un peu plus loin).
Le jeu vidéo en ligne (MMOx) a des contraintes bien plus importantes que le simple transfert de fichier.
Tandis qu'un transfert de fichier d'un pair à un autre ne demande que très peu de ressources, le jeu en ligne demande un TTL bas, un ping inférieur à 200 et une bande passante importante afin de ne pas retarder l'arrivée des paquets.
Si une de ces conditions n'est pas respectée, l'expérience de jeu s'en trouvera extrêmement dégradée. C'est pourquoi les jeux vidéo en ligne continuent d'adopter une architecture client-serveur centralisée.
Cependant, avec les débits et la latence toujours meilleure de nos lignes ADSL, l'hypothèse de faire un MMOx avec une architecture décentralisée devient de plus en plus réaliste et aujourd'hui, ce système est totalement réalisable comme nous allons le voir par la suite !
J'ai parallèlement développé un petit simulateur permettant de tester la solution que je vais vous exposer par la suite, ainsi toutes les solutions ont été testées dans un environnement virtuel. (Ainsi que par la théorie, mais je sais que la théorie ne vaut rien pour beaucoup d'informaticiens. Les Tests réels arriveront en même temps que le jeu.)
Commençons par les chiffres :
On sait qu'un serveur dédié "de base" a une bande passante d'environ 100Mbit/s.
Avec environ 200 clients (et une moyenne d'upload de 50ko/s par client : moyenne francaise) on arrive déjà à 80Mbit/s de bande passante disponible.
On sait qu'un serveur dédié "base" a entre 4 et 8 processeurs donc une puissance de calcul limité.
Avec environ 200 clients (2 processeurs par client dont 1 utilisable) on arrive à 200 Processeurs.
Tandis que l'architecture client-serveur est limitée par la puissance et la bande passante disponible sur le serveur, l'architecture décentralisée évolue et s'adapte en même temps que le nombre d'utilisateurs évolue.
Ainsi pour 5000 clients connectés, la bande passante dépasse fortement celle d'un serveur dédié : 1754 Mbit/s. (Chiffre obtenu via le simulateur précédemment développé.)
Petit encart pour montrer la création de peers dans le simulateur (création random englobant les moyennes françaises.) :
public Peer(Random rand)
{
posx = rand.Next(0,500);
posy = rand.Next(0,500);
lastping = rand.Next(20,70);
debit = rand.Next(8,80);
id = rand.Next(1,10000);
Upslot = Convert.ToInt32(debit / 4); //Défini le nombre de connexions que le peers pourra établir
}
Maintenant que l'on sait que la puissance et la bande passante ne vont pas manquer, il faut trouver un moyen de l'utiliser. Le principal problème dans un système décentralisé étant d'utiliser les ressources à dispositions. Certains peers ne vont disposer que de quelques Ko/s pour envoyer leurs informations aux autres peers tandis que d'autres vont disposer de plusieurs dizaines de Ko/s.
Un autre choix doit alors être fait : quelle architecture décentralisée allons-nous utiliser ? Comment les pairs vont-ils communiquer entre eux ?
Encore plein de questions auxquelles nous allons répondre dans les prochains articles, donc Stay Tuned !
ps : Prochain article courant de semaine.
Comme vu précédemment, le système décentralisé a de nombreux avantages, mais il a aussi ses inconvénients.
Le principal point noir de ce système est la sécurité. Sachant que tous les paquets ne passent que par les clients, un client mal attentionné peut modifier les paquets à sa guise.
De plus, les clients acceptants les paquets des autres clients, si un utilisateur décide de faire passer un code malicieux par le biais du logiciel, celui-ci se propagera rapidement au travers de toute la communauté.
Petit exemple : Un utilisateur de messagerie décentralisé décide de faire passer une image contenant un code malicieux de sa fabrication (non reconnu par l’antivirus), celui-ci se propagera sans aucune vérification d’intégrité de l’image. Pour contrer cet éventuel problème, de nombreuses dispositions sont à prendre lors du développement du système.
Première décision à prendre, y’aura-t-il un contrôleur maitre ?
Le Contrôleur maitre est un serveur (ou client) vérifiant les opérations importantes. Dans la suite de l’article nous allons prendre la solution la plus simple pour la sécurité, une architecture avec la présence d’un contrôleur maitre. (si vous avez des questions sur la sécurité sans l’utilisation d’un contrôleur maitre posez moi les question en commentaire).
Le contrôleur maitre vérifiera l’intégrité des paquets et tiendra à jour une liste des peers (clients) potentiellement dangereux. Quant un paquet arrivera d’un client et qu’un doute se pose sur l’intégrité de celui-ci (nous verrons le contrôle de l’intégrité dans un article prochain), il demandera simplement au contrôleur maitre de vérifier ce paquet. Ainsi, si le paquet est valide (si il respecte une architecture spéciale, que le hash est bon et que l’analyse anti-virus + malware n’a rien donné) il renverra un signal au client. Dans le cas contraire un message général sera envoyé à la totalité des peers mettant en garde contre ce client. Au bout du deuxième avertissement, ce client ne sera plus autorisé à émettre sur le réseau.
Ces petites vérifications peuvent être très utiles afin de ne pas se retrouver avec un réseau poubelle.
Dans le cadre d’une application demandant un haut niveau de sécurité toutes les transactions importantes doivent être vérifiées par des contrôleurs maitres. Dans certains cas il est possible d’assigner certains utilisateurs comme contrôleurs maîtres (afin d’éviter la location d’un serveur).
Il est aussi recommandé d’utiliser des coverts channels dans le cadre d’applications à haute sécurité (un article sur le sujet verra le jour prochainement).
Maintenant que les présentations faites, nous allons maintenant voir les fonctions d’un Contrôleur maitre (C#/.NET) et comment procéder à son intégration sur un réseau.
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 un autre billet (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 ».
Prochain Billet, fin de semaine, avec l'application théorique à un MMOx ainsi qu'un petit programme en C# afin de tester cette solution.
(aperçu de la version actuelle du logiciel)
Stay Tuned !
Aujourd’hui plus que jamais, les serveurs sont les pierres angulaires de la toile mondiale. Le plus petit chaos physique (pannes d’électricité dans un DataCenter) a des répercussions de grandes ampleurs sur le nuage (nb. Internet).
Pour palier à ces problèmes les entreprises mettent en place des architectures redondantes extrêmement onéreuses, autant à l’achat qu’a l’entretien (Par exemple la firme Google totalisera bientôt près d’un million de serveurs (d'ici a 2011), tandis que Microsoft de son côté mets des milliers de nouveaux serveurs en ligne chaque mois pour supporter ses applications).
De même, l’espace de stockage et la bande passante nécessaires sur les serveurs sont de plus en plus importants car les applications lourdes augmentent les coûts de l’infrastructure. C’est pourquoi un nombre croissant d’entreprises se tournent vers les réseaux décentralisés, pour leurs applications secondaires (mise à jour ou autre) sachant que la technologie n’est pour le moment pas bien maitrisée pour des applications exigeantes.
Plusieurs exemples de réseaux décentralisés sont utilisés par beaucoup (en le sachant ou pas) :
- Mise à jour de beaucoup de jeux en ligne (WOW, ...)
- Emule et autres logiciels de partage communautaire (DC, le défunt Kazaa,…)
- Le téléchargement de beaucoup de fichier lourd (release Linux, démo,…)
- La voix sur les jeux supportés par la plate-forme Steam (cf Valve)
Ainsi on peut prédire le meilleur pour cette technologie, qui permet de réduire grandement l’utilisation serveur, et ainsi réduire son parc serveur.
Une petite explication sur le système s’impose alors :
Dans un réseau décentralisé, la majorité des données sont échangées directement entre utilisateurs et ne transitent pas (ou peu) par le serveur. On a ainsi le plan suivant :
Comme vous pouvez le constater les interactions ne sont pas les même dans ces deux schémas. Ce c’est justement cette différence qui permet au système de réseau décentralisé de consommer 10x moins de ressources serveurs. Un exemple simple : si 100 personnes souhaitent télécharger un fichier, sur un système centralisé le serveur va lui-même redistribuer le fichier aux 100 personnes (si le fichier fait 100Mo, cette opération va consommer 10Go de bande passante et occuper le serveur pendant un bon moment (accès disque, traitement des requêtes,…)). Tandis qu’avec un système décentralisé, le serveur aurait coupé le fichier en 10 parties, qu’il aurait distribué à 10 personnes, et ces 10 personnes se seraient alors échangé les parties afin de reconstituer le fichier entier.
Donc, dans l’absolue théorie, le serveur n’aurait diffusé qu’une fois le fichier, et 100 personnes l’auraient eu (utilisation minime du disque et de la bande passante serveur, mais utilisation de la bande passante client qui est la plupart du temps inutilisé dans le sens montant/upload).
Ce système est de plus en plus efficace avec l’avènement du haut débit en France (et bientôt très haut débit), avec plus de 1Mbit/s d’upload dans la plupart des offres (soit 128 ko/s). Ce n’est pas grand-chose me direz-vous mais la force d’un réseau décentralisé est la communauté connectée, ainsi lorsque 100 utilisateurs ont acquis le fichier, la bande passante disponible est équivalente à celle d’un serveur de production.
Principal exemple (on y revient souvent pour la présentation car cela parle à de nombreuses personnes) : le réseaux eDonkey, avec ses serveurs dépassant la barre du million d’utilisateurs connectés sur un seul nœud (serveur) ce qui est impensable sans cette technologie. Dans ce cas précis le serveur ne fait que rediriger les clients les uns vers les autres en fonctions des fichiers demandés, ensuite le transfert de fichier ne passe pas par le serveur (et le flux de données est bien plus important que s’il passait par celui-ci : plusieurs TB/s).
Maintenant que l’idée générale est posée, et que celle-ci est claire (je l’espère, sinon posez vos questions en commentaire) dans l’esprit de tous nous allons voir les avantages et les inconvénients de ce système et optionnellement comment y remédier.
Le principal avantage est, comme dit précédemment, qu’il permet un fort gain de bande passante (car celle-ci n’est pas illimités, la liaison inter-atlantique à une limite fixe, et il est très onéreux de « tirer » de nouveaux câbles au travers d’un océan).
Viens ensuite le fait qu’une panne de serveur ne pénaliserait pas forcément les services hébergés (grâce à la persistance due au cache de tous les utilisateurs connectés). Les données seraient alors encore disponible le temps de repérer la panne.
Bien sur, tout n’est pas rose dans le monde merveilleux du décentralisé. La sécurité, l’intégrité des données et la validité des clients sont les principaux inconvénients/problèmes techniques que le système pose. Mais comme tout à une solution, nous verrons plus tard comment palier à ces problèmes.
Parlons maintenant applicatif (en toute théorie) afin que l’image de ce système n’en soit que plus forte dans votre esprit :
Comme vous le savez certainement, les MMOx (jeux permettant de jouer avec des milliers de joueurs simultanément) demande une infrastructure importante.
L’utilisation en bande passante serveur est titanesque, alors que les clients, eux n’utilisent que 2-5ko/s de leur bande passante montante (upload) soit moins 10%.
Le but dans cette application serait de se dire, aucune bande passante ne doit être perdue. Ainsi lorsqu’un millier de joueurs seraient connectés la bande passante disponible serait largement supérieur à ce qui est nécessaire, et les serveurs serait ainsi plus qu’allégés. (Économie de plusieurs To de bande passante).
Autre application possible, directement liée au web, faire un navigateur qui partagerai le cache des utilisateurs. Ainsi lorsqu’un serveur serait surchargé, il suffirait de demandé à la communauté qui a consulté cette page dernièrement afin qu’il nous l’envoi.
Le P2P n'est valide que pour du contenu "statique", donc pour du contenu dynamique il faut tout d'abord demander une validation sur le contenu de la page (par exemple pour un forum savoir si une discussion a évoluée).
IlDe même pour les MMOx, ce système engendrait des incohérences, mais je m'expliquerais sur cela plus tard, car il y a aussi une solution.
Enfin bref, passons sur toutes les possibilités (utopique ?) offerte par cette technologie, elle a un autre atout de taille : savez combien d’énergie utilise une ferme de serveur (autant pour tourner que pour refroidir ?) ? Il ne vaut mieux pas le savoir...
Donc si l’on peut réduire le parc de serveur mondial (ou continuer à développer le web sans pour autant étendre ce parc), d’énorme économie peuvent être réalisée.
Voila, c’est la fin de cette petite présentation (généraliste) de ce système.
Nous verrons les aspects plus techniques (sous plateforme .net) dans les billets qui viendront.
Si vous avez des questions n'hésitez pas !
Bonjour à tous,
comme la coutume le souhaite, je vais me présenter avant d'entrer dans le vif du sujet.
Sylvain Mura, 20ans, actuellement directeur de ma société de service (Freelance principalement), je suis déjà passé par une société de développement de jeux vidéo (MMORPG principalement), spécialisé en technologies .NET ce qui m'a permis d'acquérir une certaines autonomie ainsi qu'une certaine connaissance de la programmation multimédia en .NET.(d'autres sociétés ont suivi mais c'est la seule expérience professionnelle qui sort du lot).
Mes compétences se limitent en grande partie à la programmation, je suis dev. .NET(comme dit précédemment), mais j’utilise aussi les technologies web (php,…) et quelque fois je me laisse tenter par le JAVA quand le cœur m’en dit ! (à contrario, ne venez pas me parler du C++ que je ne supporte pas, avec ses histoires de pointeurs et autres gestion de mémoire horrible due à l’absence de GC (garbage collector) digne de ce nom.). Je manie aussi 3DS Max, mais une phrase que j'apprécie me corresponds très bien en ce domaine : "Je suis à la 3D ce que la clé à molette est au pâtissier"...
Pour ceux qui aurait des doutes, .NET signifie C# et non Visual Basic pour moi. Le visual basic c’est marrant, mais on arrive vite à saturation.
Pour répondre à ceux qui se demandent ce qu'il va y avoir sur ce blog je vais répondre simplement :
*La révolution du décentralisé
*Dev. Indie XNA afin de suivre le dev. d'un jeu vidéo de A à Z (pré-prod --> distribution)
Voici pour la rapide présentation, si vous avez des questions, n'hésitez pas !
ps : Merci à DF pour l'hébergement !