+ Répondre à la discussion
Affichage des résultats 1 à 3 sur 3
  1. #1
    Membre régulier Avatar de tenebriox
    Inscrit en
    juin 2009
    Messages
    88
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 88
    Points : 75
    Points
    75

    Par défaut Problème client/serveur UDP (fiabilisation des transferts)

    Bonjour à tous,
    Je souhaiterais mettre en oeuvre un client/serveur en UDP mais qui soit mieux fiabilisé que le protocole de base...

    Pour des besoins principalement de temps réel, je suis obligé de passer par UDP, et je souhaiterais dans un premier temps détecter une perte de paquet.
    Voici comment j'ai décomposé mon programme :

    emetteur.c : envoie un fichier texte au serveur
    receveur.c : en attente de réception
    socket.c : permet la création de sockets udp (grâce aux fonctions d'envoi/réception) contenues dans protocole.c
    protocole.c : contient notamment les fonctions envoi/réception au lieu de send/recv.

    Ce que je veux faire concrètement, c'est dans mon protocole.c :
    - lorsque je reçois un paquet, je mets à jour le dernier num d'acquittement
    - lorsque j'envoie un paquet, j'inclus dans un nouveau header le dernier num d'acquittement

    Ceci va être un premier pas vers l'acquittement de paquets mais mon principal problème c'est que le receveur et l'émetteur fonctionnent de manière unidirectionnelle si je puis dire. C'est à dire que chacun ne fait qu'envoyer ou que recevoir.
    J'ai pensé à envoyer un message "bidon" quand le receveur reçoit un paquet.
    Et idem pour l'émetteur : après envoi d'un paquet, on scrute si des données sont dispos le socket avec select.
    Donc, vous allez me dire que tout devrait fonctionner maintenant ?!

    Et bien non !! J'ai un gros problème au niveau de la "bidirectionnalité" !
    Mon émetteur/receveur ont la même IP locale (127.0.0.1) et écoutent le même port.... Du coup par exemple mon receveur capte lui même le paquet qu'il envoie à destination de l'émetteur...

    Je peux fournir le code si besoin

    Bravo si vous m'avez lu jusqu'au bout, et si vous avez des idées, que ce soit pour implémenter les acks différemment, ou pour mon problème de bidirectionnalité n'hésitez pas, je vous attends ^^

  2. #2
    Modérateur
    Avatar de Bktero
    Profil pro
    Ingénieur systèmes embarqués
    Inscrit en
    juin 2009
    Messages
    2 762
    Détails du profil
    Informations personnelles :
    Âge : 27
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2009
    Messages : 2 762
    Points : 7 396
    Points
    7 396
    Billets dans le blog
    1

    Par défaut

    Et si tu essayes avec 2 PC distincts, il se passe quoi ? Ici, le problème vient plutôt de la méthode de tests que de la méthode d'acknowlegment.
    Si Code::Blocks vous dit undefined reference to 'socket@12', cela signifie que vous avez un problème d'édition des liens. Allez dans Projects / Build Options / Linker Settings / Add et renseignez ici les .a qui vont bien. Exemple pour les sockets : C:\Program Files\CodeBlocks\MinGW\lib\libws2_32.a

    Pour les adeptes du langage SMS, allez ici et ramenez la traduction française ^^

    Pour vos problèmes d'embarqué, utilisez le forum dédié !

  3. #3
    Membre à l'essai
    Inscrit en
    octobre 2004
    Messages
    57
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 57
    Points : 22
    Points
    22

    Par défaut

    Citation Envoyé par tenebriox Voir le message
    Bonjour à tous,
    Je souhaiterais mettre en oeuvre un client/serveur en UDP mais qui soit mieux fiabilisé que le protocole de base...

    Pour des besoins principalement de temps réel, je suis obligé de passer par UDP, et je souhaiterais dans un premier temps détecter une perte de paquet.
    Voici comment j'ai décomposé mon programme :

    emetteur.c : envoie un fichier texte au serveur
    receveur.c : en attente de réception
    socket.c : permet la création de sockets udp (grâce aux fonctions d'envoi/réception) contenues dans protocole.c
    protocole.c : contient notamment les fonctions envoi/réception au lieu de send/recv.

    Ce que je veux faire concrètement, c'est dans mon protocole.c :
    - lorsque je reçois un paquet, je mets à jour le dernier num d'acquittement
    - lorsque j'envoie un paquet, j'inclus dans un nouveau header le dernier num d'acquittement

    Ceci va être un premier pas vers l'acquittement de paquets mais mon principal problème c'est que le receveur et l'émetteur fonctionnent de manière unidirectionnelle si je puis dire. C'est à dire que chacun ne fait qu'envoyer ou que recevoir.
    J'ai pensé à envoyer un message "bidon" quand le receveur reçoit un paquet.
    Et idem pour l'émetteur : après envoi d'un paquet, on scrute si des données sont dispos le socket avec select.
    Donc, vous allez me dire que tout devrait fonctionner maintenant ?!

    Et bien non !! J'ai un gros problème au niveau de la "bidirectionnalité" !
    Mon émetteur/receveur ont la même IP locale (127.0.0.1) et écoutent le même port.... Du coup par exemple mon receveur capte lui même le paquet qu'il envoie à destination de l'émetteur...

    Je peux fournir le code si besoin

    Bravo si vous m'avez lu jusqu'au bout, et si vous avez des idées, que ce soit pour implémenter les acks différemment, ou pour mon problème de bidirectionnalité n'hésitez pas, je vous attends ^^
    Salut,

    C'est normal que tu recoives le paquet que tu as émis , il te suffit de le jeter ( de détecter que c'est toi même en regardant l'adresse de l'émetteur ), et de faire un send recvfrom pour recevoir le paquet que tu attends.

    Sinon, tu peux également positionner la socket pour ne pas recevoir tes propres paquets, cela se fait en broadcast, mais je ne vois pas pourquoi on ne pourrait pas le faire en unicast ( je ne me souviens plus de l'appel système )

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •