IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Réseau et multijoueurs Discussion :

[UDP] Connexion et UDP


Sujet :

Réseau et multijoueurs

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2009
    Messages : 13
    Points : 18
    Points
    18
    Par défaut [UDP] Connexion et UDP
    Bonjour !

    J'étais en train de me poser une question existentielle à propos de l'utilisation du protocole UDP : après m'être expliqué avec d'autres personnes un peu plus calé niveau réseau que moi, on a fini par s'entendre et comprendre qu'effectivement, quelque chose nous échappait.

    Dans le cas d'une connexion TCP, en tant que développeur, les socket que nous fournissent le système nous permettent d'avoir la main-mise sur quelque chose de persistant.
    Il n'y a donc que le serveur qui doit être, depuis le port spécifié, directement accessible via Internet.

    Dans le cas d'UDP, en tant que développeur, on ne dispose pas d'un socket par client mais d'un socket tout court (ou un pour l'écriture et un pour la lecture) : et lorsque l'on envoi une réponse, on spécifie une IP et un port de destination.
    Mais alors, si le client se trouve derrière un routeur qui ne redirige pas le port vers lui, il ne recevra pas les paquets envoyés par le serveur.

    Je me demande alors comment font des serveurs de jeux comme ceux de Warcraft III ou Counter Strike pour communiquer avec leurs clients ?

    Je code un jeu ou la connexion se fait en UDP en ce moment : ça ne me pose aucun problème que le serveur ne soit accessible que depuis mon sous-réseau, mais qui sait, si dans le futur je souhaite propager ma création, ça m'arrangerait pas mal de pouvoir simuler une connexion.

    Quelqu'un peut-il m'éclairer sur le sujet ?

  2. #2
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 74
    Points : 80
    Points
    80
    Par défaut
    Un serveur UDP possède une seule socket à l'écoute sur un port donné.

    Un client qui souhaite envoyer un message au serveur devra l'envoyer sur le port d'écoute du serveur. Lors de l'envoi du message, un port s'ouvre automatiquement sur le client.

    Lorsque le serveur souhaite répondre au client, il regarde la provenance du message (IP et port de l'expéditeur) et envoi sa réponse sur le port ouvert du client.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    |-------------------------------------|
    | IP DESTINATAIRE | PORT DESTINATAIRE |
    |-------------------------------------|
    |  IP EXPEDITEUR  |  PORT EXPEDITEUR  |
    |-------------------------------------|
    |                                     |
    |              MESSAGE                |
    |                                     |
    |-------------------------------------|
    Les routeurs ne se préoccupent pas du port. Ils ne font qu'acheminer le message vers la machine, il ne regarde que l'IP, pas le port. Dans le cas d'une NAT (LiveBox, FreeBox...) en revanche, les entête ip et port des messages sortants sont tous réécrit avec l'IP et le port choisi pour le nattage.

    Voici un exemple :

    Envoi d'un message :

    Supposons une machine "C", caché derrière une NAT, possède un IP en 192.168.1.10 et souhaite envoyer un message au serveur "S" en 88.124.92.88 sur sont port 2500.

    Une NAT possède deux IP :
    - Une IP privé connu du réseau local uniquement
    - Une IP publique connue du réseau Internet

    L'IP de la NAT sur le réseau local est 192.168.1.20 tandis que son IP publique est 66.43.21.66.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    |---|                               |-----|                                         |---|
    | C |192.168.1.10 ----- 192.168.1.20| NAT |66.43.21.66 ---(Internet)--- 88.124.92.88| S |
    |---|                               |-----|                                         |---|
    Lorsque le client envoi un message au serveur, il envoi ce message à la NAT :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    |-------------------------------------|
    |  88.124.92.88   |        2500       |
    |-------------------------------------|
    |  192.168.1.10   |        1555       |
    |-------------------------------------|
    |                                     |
    |              MESSAGE                |
    |                                     |
    |-------------------------------------|
    Ce message ne pourrait pas circuler sur le réseau Internet car le champ IP EXPEDITEUR est un IP de réseau local inaccessible depuis l'extérieur. La NAT va donc réécrire ce champs en se désignant comme expéditeur. Elle en profite au passage pour réécrire le numero de port qu'elle mémorise dans une table de correspondance (local <---> internet).

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    |-------------------------------------|
    |  88.124.92.88   |        2500       |
    |-------------------------------------|
    |   66.43.21.66   |        1444       |
    |-------------------------------------|
    |                                     |
    |              MESSAGE                |
    |                                     |
    |-------------------------------------|
    Table de correspondance à l'intérieur de la NAT :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1444 <---> 192.168.1.10:1555
    Le message sera ensuite acheminé de routeur en routeur vers la machine serveur 88.124.92.88.

    Retour de la réponse :

    Le serveur, ayant reçu le message, découvre que l'expéditeur est 66.43.21.66:1444. Il s'agit de la NAT mais il n'a aucun moyen de savoir que c'est la NAT. Pour lui, son client c'est 66.43.21.66:1444 et il répondra à 66.43.21.66:1444.

    Il envoi sa réponse en permutant les champs DESTINATAIRE et EXPEDITEUR :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    |-------------------------------------|
    |   66.43.21.66   |        1444       |
    |-------------------------------------|
    |  88.124.92.88   |        2500       |
    |-------------------------------------|
    |                                     |
    |              REPONSE                |
    |                                     |
    |-------------------------------------|
    Le message passe de routeurs en routeurs jusqu'à arriver à la NAT du côté Internet. La NAT regarde le champs PORT DESTINATAIRE et lit ceci :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    |-----------|
    |   1444    |
    |-----------|
    Elle regarde dans sa table de correspondance et vois ceci :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1444 <---> 192.168.1.10:1555
    Elle réécrit les champs DESTINATAIRE et envoi le message du côté local :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    |-------------------------------------|
    |  192.168.1.10   |        1555       |
    |-------------------------------------|
    |  88.124.92.88   |        2500       |
    |-------------------------------------|
    |                                     |
    |              REPONSE                |
    |                                     |
    |-------------------------------------|
    Le client reçois alors le message de réponse en provenance du serveur. Il ignore d'ailleurs l'existence de la NAT.

    J'espère que mes explications t'auront parue claire. J'ai passé certaines choses sous silence pour clarifier les explications. Si un jour tu entends parler du modèle OSI, sache que mes explications se sont limité volontairement au couche 3 et 4. En réalité, une couche 2 permet au client de connaitre et de communiquer avec la NAT. Cette couche 2 d'appui elle même sur une couche 1 : la couche physique (Wifi, Ethernet).

  3. #3
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 33
    Points : 32
    Points
    32
    Par défaut
    Bonjour.

    Je me permets de faire remonter ce sujet car il tombe pile sur le problème que nous avons.

    Nous développons actuellement un jeu en P2P utilisant UDP pour les communications interclient.
    Pour l'instant, afin que le jeu marche, nous sommes obligés de rediriger le port utilisé par l'application sur la box/routeur vers le client qui veut jouer.

    Existe-t-il un moyen de faire en sorte que l'utilisateur n'ait pas à faire ça?
    D'après ce que je comprends de votre explication, le NAT se fait tout seul ? Est-ce ce dont nous avons besoin ?

    Devons nous changer de protocole ou de méthode de communication pour enlever cette contrainte de redirection de port ?

    Merci d'avance,

    Nieli

  4. #4
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut
    Hello,

    les NAT 'classiques' le feront tout seuls à partir du moment où on leur a déjà demandé d'envoyer des paquets vers une destination identique (ie. IP et port) à l'expéditeur du paquet reçu.

    Si un ordi [A] du réseau local (derrière le NAT) envoie un paquet à destination de l'88.111.222.123 sur le port 1234 et que quelques temps après le NAT reçoit un paquet de 88.111.222.123 sur le port 1234, il peut logiquement conclure que le paquet a toutes les chances d'être destiné à l'ordi [A] et pas un autre. Il va donc forwarder le paquet à [A].

    Par contre, si le NAT n'a jamais relayé auparavant de paquet émis par [A] à destination de 88.111.222.123 : 1234, il n'a aucun moyen de deviner que le paquet qu'il vient de recevoir est destiné à [A] plutôt qu'un autre ordi de ton sous-réseau ; le paquet sera donc purement et simplement filtré.

    Tu peux trouver plus d'infos en te renseignant sur la notion de 'UDP Hole Punching' qui consiste justement à "percer" les barrières pour que deux machines NATées puissent communiquer directement ensembles en UDP sans redirection de port
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  5. #5
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 33
    Points : 32
    Points
    32
    Par défaut
    Merci pour votre réponse.

    Cependant, en enlevant la règle de redirection de la box (liveBox), il ne semble pas y avoir de redirection automatique, alors que c'est bien le client derrière la liveBox qui initialise la connexion.

    Est-il possible qu'il y ait un rapport avec le fait que le client soit en wifi ? (redirection nat bloquée par sécurité en wifi ?)

  6. #6
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut
    Citation Envoyé par Nieli Voir le message
    Est-il possible qu'il y ait un rapport avec le fait que le client soit en wifi ? (redirection nat bloquée par sécurité en wifi ?)
    Je ne pense pas: la notion de WiFi intervient sur des couches réseau plus basses (couche physique, ...) qui typiquement encapsulent ce qui se passe aux couches plus hautes (typiquement IP, UDP). Donc c'est transparent pour le NAT.

    Pour le reste, je ne vois pas à priori ce qui pourrait poser souci.
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  7. #7
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 33
    Points : 32
    Points
    32
    Par défaut
    Merci de votre aide !
    En effet, nous avions mal saisi la notion de NAT, maintenant c'est beaucoup plus clair et en effet les règles NAT s'ajoute automatiquement.

    Cependant, nous avons un autre problème inhérent à ces règles NAT, lorsqu'il y a 2 client dans le même réseau local:

    Nous avons deux clients dans un réseau local : C1 et C2. Ces 2 clients se connectent à un serveur S sur le port P.
    Nous avons compris que lorsque C1 initiait une connexion vers S, une règle NAT se mattait en place automatiquement sur son routeur (tout ce qui vient du serveur S et sur le port P est redigiré vers C1).
    Cependant, si C1 et C2 font la même chose vers le même serveur (même ip serveur et même port), il faudrait alors 2 règles, du coup comment fait le routeur pour s'y retrouver et savoir s'il doit envoyer à C1 ou à C2 ?

    D'après les tests que nous menons sur notre propre jeu, si C1 et C2 se connectent, seul le premier à s'être connecté reçoit les messages. Que doit-on faire pour que cela marche ?

    Merci d'avance,

    Cordialement

  8. #8
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut
    Citation Envoyé par Nieli Voir le message
    Cependant, si C1 et C2 font la même chose vers le même serveur (même ip serveur et même port), il faudrait alors 2 règles, du coup comment fait le routeur pour s'y retrouver et savoir s'il doit envoyer à C1 ou à C2 ?
    Réponse: il ne peut pas ; donc on observe le souci que tu mentionnes dans le reste de ton post.

    Que doit-on faire pour que cela marche ?
    Bidouiller: Multiplier le nombre de ports différents auxquels les clients peuvent se connecter et se débrouiller pour que lorsque deux clients sont derrière le même NAT non seulement ils le sachent mais qu'en plus ils aient les moyens de choisir deux ports différents.
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  9. #9
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 33
    Points : 32
    Points
    32
    Par défaut
    D'accord, c'est bien ce que nous redoutions. Nous avons déjà un peu bidouiller mais on voulait être sûr qu'il n'y avait pas de solution simple.

    Merci encore

  10. #10
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 74
    Points : 80
    Points
    80
    Par défaut
    Cependant, si C1 et C2 font la même chose vers le même serveur (même ip serveur et même port), il faudrait alors 2 règles, du coup comment fait le routeur pour s'y retrouver et savoir s'il doit envoyer à C1 ou à C2 ?
    Attention, je me permet de revenir sur ce sujet pour ajouter une explication.

    Lorsque C1 et C2, derrière une même NAT se connecte à un serveur, deux cas possibles :

    - C1 et C2 sont sur deux machines différentes.
    - C1 et C2 sont sur la même machine.

    Voyons ces deux cas de plus près.

    C1 et C2 sont sur deux machines différentes

    Dans ce cas, le NAT saura différencier les machines par leurs adresses IP distincts. Lorsque les paquets de C1 et C2 seront nattés, la NAT prendra soins de réécrire des ports sources différents. Ainsi, lors de la réponse, la NAT saura à qui est destiné le message par le port destination de la réponse sera différent.

    Prenons un exemple :

    Les machines A (192.168.0.10) et B (192.168.0.11) sont derrière la NAT N donc l'IP publique est 88.222.222.222 et souhaitent se connecter au serveur S (88.111.111.111) sur son port 1234.
    Lorsque la machine A va se connecter au serveur S, la machine A va ouvrir un port automatiquement, choisi par le système, par exemple 5550. La NAT, située entre les clients et le serveur, va analyser le paquet de générer un numéro de port, par exemple 7770. Dans sa table, elle va donc associer 7770 à 192.168.0.10:5550. De plus la NAT va réécrire le champs source du message par son IP et son port généré de telle sorte que le serveur voie le message en provenance de 88.222.222.222:7770.

    Tuple ajouté à la table de la NAT :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    7770 -> 192.168.0.10:5550
    Maintenant, la machine B envoie un message au serveur (même IP, même port). La machine B va ouvrir un port automatiquement, choisi par le système, par exemple 5550 (pas de bol, en plus il est identique). La NAT, située entre les clients et le serveur, va analyser le paquet de générer un numéro de port, par exemple 7771. Dans sa table, elle va donc associer 7771 à 192.168.0.11:5550. De plus la NAT va réécrire le champs source du message par son IP et son port généré de telle sorte que le serveur voie le message en provenance de 88.222.222.222:7771.

    Tuple ajouté à la table de la NAT :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    7771 -> 192.168.0.11:5550
    Voici donc la table de la NAT :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    7770 -> 192.168.0.10:5550
    7771 -> 192.168.0.11:5550
    Le serveur a reçu deux messages en provenance de la même IP, mais de deux port différents. (88.222.222.222:7770 et 88.222.222.222:7771). Il peux donc répondre à l'un comme à l'autre sans que ces messages soit mélangés. Il répond donc aux deux clients.

    La NAT, toujours entre les deux, reçois donc deux messages : l'un sur son port 7770 et l'autre sur son port 7771.

    Elle regarde sa table :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    7770 -> 192.168.0.10:5550
    7771 -> 192.168.0.11:5550
    ... et sais que le message reçu sur le port 7770 doit être acheminé vers 192.168.0.10:5550 et l'autre vers 192.168.0.11:5550.

    Il n'y a donc pas de problème à avoir deux machines derrière une même NAT qui se connecte au même serveur, sur le même port.

    C1 et C2 sont sur la même machine

    C'est typiquement ce qu'il se produit lorsqu'on ouvre deux navigateurs et qu'on les connecte au même site.

    Dans ce cas, la NAT fonctionne toujours de la même manière et le système, qui attribut les ports automatiquement, fonctionne également de la même manière. Seulement, lorsqu'un programme client demande l'ouverture d'un port au système, ce dernier lui en attribut un nouveau à chaque fois (bien souvent, c'est celui qui est immédiatement après), si bien que si C1 et C2 veulent se connecter au même serveur, le port source sera différent.

    Prenons un exemple :

    C1 (192.168.0.10) envois un message au serveur (88.111.111.111:1234). Le système génère un numéro de port, par exemple 6660. Le message sort de l'ordinateur avec comme adresse 192.168.0.10:6660.

    La NAT fait le même travaille que tout à l'heure, génère par exemple le port 7770, et mémorise dans sa table :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    7770 -> 192.168.0.10:6660
    Ensuite, C2 fait la même chose, le système lui attribut le numéro de port 6661, le message sort de l'ordinateur avec comme adresse 192.168.0.10:6661. C'est la même machine mais pas le même port.

    La NAT fait le même travaille que tout à l'heure, génère par exemple le port 7771, et mémorise dans sa table :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    7771 -> 192.168.0.10:6661
    Voici donc le contenu de la table de la NAT :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    7770 -> 192.168.0.10:6660
    7771 -> 192.168.0.10:6661
    Pour le dialogue avec le serveur, c'est exactement la même chose que tout à l'heure, le serveur à affaire à la même IP, mais de deux port différents. (88.222.222.222:7770 et 88.222.222.222:7771). Il peux donc répondre à l'un comme à l'autre sans que ces messages soit mélangés. Il répond donc aux deux clients.

    La NAT, toujours entre les deux, reçois donc deux messages : l'un sur son port 7770 et l'autre sur son port 7771.

    Elle regarde sa table :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    7770 -> 192.168.0.10:6660
    7771 -> 192.168.0.10:6661
    ... et sais que le message reçu sur le port 7770 doit être acheminé vers 192.168.0.10:6660 et l'autre vers 192.168.0.10:6661.

    Dans les deux cas, ce sera la même machine qui recevra les deux messages (tout comme c'était la même NAT qui a reçu les deux messages tout à l'heure). C'est ensuite dans le système que les deux messages sont être aiguillé vers le bon programme (C1 ou C2) car lors de la création de leur socket respectif, le système leur a affecté des ports différents (bien que ces programmes soit identique). Ainsi, le programme C1 récupèrera le message qui arrivera sur le port 6660 de la machine tandis que le programme C2 récupèrera le message qui arrivera sur le port 6661 de cette même machine.

    D'accord, c'est bien ce que nous redoutions.
    Il n'y a rien à redouter. Il n'y a que dans le cas du P2P ou il faut procéder à une "bidouille" : soit effectuer un UDP Hole Punching ou paramétrer la NAT à l'aide d'un protocole spécifique comme UPNP ou STUN. Mais dans le cas d'une communication exclusivement client/serveur, tu n'as rien à faire de particulier, sauf, bien évidement, paramétrer le routeur derrière lequel se situe ton serveur (une seule fois) si tu veux qu'on puisse y accéder depuis l'extérieur.

  11. #11
    Rédacteur

    Avatar de ram-0000
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Mai 2007
    Messages
    11 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant en sécurité
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2007
    Messages : 11 517
    Points : 50 367
    Points
    50 367
    Par défaut
    Excellente explication (même si le post date un peu) !!
    Raymond
    Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi

    Cafuro Cafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
    e-verbe Un logiciel de conjugaison des verbes de la langue française.

    Ma page personnelle sur DVP
    .

Discussions similaires

  1. Connexion protocole UDP
    Par Guyome41 dans le forum VB.NET
    Réponses: 4
    Dernier message: 16/07/2013, 16h38
  2. problème connexion port UDP
    Par Darkaurora dans le forum Développement
    Réponses: 1
    Dernier message: 01/07/2011, 22h17
  3. Cherche hébergement PHP acceptant connexions UDP ?
    Par supergrey dans le forum Hébergement
    Réponses: 1
    Dernier message: 05/12/2007, 15h19
  4. Choix entre TCP/UDP, sécurité du UDP
    Par coyotte507 dans le forum Développement
    Réponses: 5
    Dernier message: 21/05/2007, 23h28
  5. Connexion UDP
    Par theflamme dans le forum Développement
    Réponses: 2
    Dernier message: 06/01/2003, 15h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo