›

TCP

LarmeLarme Membre
mai 2012 modifié dans API UIKit #1
Bonjour tout l'monde.



J'aimerais envoyer quelques sockets TCP (toujours pour contrôler mon p'tit Robot), mais je bute un peu.

J'aimerais juste envoyer une simple socket et pouvoir en recevoir, le tout en IPv4.



Cependant, j'ai l'impression que je suis obligé de passer par la lib' externe : CocoaAsyncSocket.

ça me paraà®t dingue d'avoir à  passer par un truc externe et de ne pas avoir un code simple pour faire un truc aussi courant.



C'est moi, ou je ne sais pas chercher... Pour l'instant, je dois boucler mon projet (pour mardi 8h si vous voulez tout savoir), alors je ne m'intéresse pas réellement à  comprendre toutes les subtilités, car c'est encore un prototype. Ce qui expliquerait peut-être mon empressement et mon incompétence à  ne pas chercher correctement. Si vous avez un lien de tuto basique, j'suis preneur. Oui, le client veut pas (encore) du code clean, il veut un truc qui puisse servir de démo.



Parce que là , j'hésite à  passer par du C basique, c'est vous dire... Et c'est ce que je risque de faire si je n'arrive pas à  résoudre mon problème dans les temps, avant de m'atteler d'avantage dessus.



Je vous remercie d'avance de toute aide que vous pourriez m'apporter. Le Martini comptant comme de l'aide également image/tongue.png' class='bbc_emoticon' alt=':P' />
Mots clés:
«1

Réponses

  • LarmeLarme Membre
    #2
    Je m'auto-réponds : J'ai trouvé ça qui a l'air pas mal, j'vais tester.
  • CeetixCeetix Membre
    #3
    BTW c'est quoi que tu utilises comme contrôleur pour ton robot ?
  • LarmeLarme Membre
    mai 2012 modifié #4
    Comme contrôleur ? Pas sûr d'avoir tout saisi, mais :

    Je le commande en WiFi (évidemment, c'est du TCP), j'lui donne des instructions sur un port donné qui lui part en port série.

    Mes p'tites sockets sont listées dans ma doc' (module électronique développé maison).



    Le lien que j'ai donné semble fonctionner.

    J'sais pas si c'est le plus stable, mais ça fonctionne, et on verra par la suite.

    Par contre, mon code est bien sale :/ Pas l'temps d'cleaner tout ça. J'vais juste essayer de boucher toutes les fuites mémoires que j'ai histoire que le stand puisse se dérouler toute la journée sans trop d'encombres.
  • zoczoc Membre
    mai 2012 modifié #5
    'Larme' a écrit:


    Cependant, j'ai l'impression que je suis obligé de passer par la lib' externe : CocoaAsyncSocket.

    ça me paraà®t dingue d'avoir à  passer par un truc externe et de ne pas avoir un code simple pour faire un truc aussi courant.


    NSStream a tout ce qu'il faut pour les connexions orientées flux (TCP quoi...). (En fait NSInputStream et NSOutputStream pour avoir une communication double sens)...



    Accessoirement, on n'envoie pas une socket... Une socket, c'est un objet du système d'exploitation qui représente une extrémité d'un canal de communication.
  • CeetixCeetix Membre
    #6
    Je voulais dire micro-controlleur (PIC ?)

    Tu as le robot tout monté déjà  ou tu l'as fait toi même ?
  • yoannyoann Membre
    #7
    NSStream est la solution en effet même si un modèle bien objet préfèrerais un système de socket asynchrone.



    BTW c'est quoi ce robot ? J'ai raté un truc ^^
  • LarmeLarme Membre
    #8
    Robot de la boà®te qui nous sous-traite.
  • DrakenDraken Membre
    #9
    Militaire ?
  • LarmeLarme Membre
    mai 2012 modifié #10
    Non, ludique.

    Il doit faire 20*20*20 cm.
  • DrakenDraken Membre
    #11
    "Paix et prospérité.."
  • LarmeLarme Membre
    #12
    Indeed, je ne développerais jamais pour l'armée...
  • XodiaXodia Membre
    #13
    J'ai une petite question, dans ton protocole, tu dois connaitre l'adresse IP de ton robot.

    Comment tu l'as recuperes ? (Si tu ne l'as met pas a la main...)



    Apres en C pur, les sockets sont pas trop compliquer, j'en ai deja utiliser, si tu veux des petits bout de code (UDP).
  • yoannyoann Membre
    #14
    'Xodia' a écrit:


    J'ai une petite question, dans ton protocole, tu dois connaitre l'adresse IP de ton robot.

    Comment tu l'as recuperes ? (Si tu ne l'as met pas a la main...)



    Apres en C pur, les sockets sont pas trop compliquer, j'en ai deja utiliser, si tu veux des petits bout de code (UDP).




    mDNS (Bonjour) est dispo sur pas mal de plateforme et est très pratique pour faire de la découverte de service.



    Sinon pour les socket en C pur, attention aux buffer over flow quand même. ça demande une vérification de code un peu plus poussé qu'avec un code en Cocoa qui gère automatiquement l'allocation des buffer et encapsule tout ça en NSData.
  • yoannyoann Membre
    #15
    Sinon Larme, t'as boite cherche pas des dev freelance de temps en temps ? Bosser sur de la robotique ça me plairait assez ^^
  • XodiaXodia Membre
    mai 2012 modifié #16
    'yoann' a écrit:


    mDNS (Bonjour) est dispo sur pas mal de plateforme et est très pratique pour faire de la découverte de service.



    Sinon pour les socket en C pur, attention aux buffer over flow quand même. ça demande une vérification de code un peu plus poussé qu'avec un code en Cocoa qui gère automatiquement l'allocation des buffer et encapsule tout ça en NSData.




    Bah tu fais un structure avec un buffer constant.

    Genre :
    <br />
typedef struct t_msg<br />
{<br />
char buf[4096];<br />
t_type typeMsg;<br />
...<br />
}<br />




    La taille de la structure restera a chaque fois la meme.

    Faudra faire un buffer tournant au cas ou tu reçois pas tout d'un coup et vu que l'ordre envoyer n'est pas forcement l'ordre reçu.
  • yoannyoann Membre
    #17
    'Xodia' a écrit:


    Bah tu fais un structure avec un buffer constant.

    Genre :
    <br />
typedef struct t_msg<br />
{<br />
char buf[4096];<br />
t_type typeMsg;<br />
...<br />
}<br />




    La taille de la structure restera a chaque fois la meme.

    Faudra faire un buffer tournant au cas ou tu reçois pas tout d'un coup et vu que l'ordre envoyer n'est pas forcement l'ordre reçu.




    Yakafokon comme on dit. Définir un buffer tout le monde sait le faire, gérer des buffer tournant ou de la réallocation dynamique en faisant attention à  ne pas laisser de vulnérabilité dans son code n'est pas forcément à  la porté d'un débutant.



    Il existe des API haut niveau pour que chacun profite de la capitalisation des connaissance de code. Il n'y a aucun avantage à  passer en socket BSD géré à  la main vis à  vis d'un NSStream par exemple (sauf optimisation extrême mais la question ne serait pas posé ici).



    C'est bien de savoir le faire à  la main, mais c'est aussi bien de savoir utiliser des API plus haut niveau et validé par plusieurs autres développeur plus que compétent (on parle de la lib Cocoa là , pas d'un truc pris sur le net), ça évite de rajouter des surfaces d'attaque inutilement sur son code.
  • LarmeLarme Membre
    #18
    'yoann' a écrit:


    Sinon Larme, t'as boite cherche pas des dev freelance de temps en temps ? Bosser sur de la robotique ça me plairait assez ^^


    En réalité, on ne bosse pas réellement sur de la robotique, ce sont plus des jouets, et le reste des projets est basé sur de la domotique.




    'Xodia' a écrit:


    J'ai une petite question, dans ton protocole, tu dois connaitre l'adresse IP de ton robot.

    Comment tu l'as recuperes ? (Si tu ne l'as met pas a la main...)


    Le module émet un réseau WiFi auquel je me connecte. Il a un adresse IP fixe, un pool DHCP pour me filer une adresse etc.


    'Xodia' a écrit:


    Apres en C pur, les sockets sont pas trop compliquer, j'en ai deja utiliser, si tu veux des petits bout de code (UDP).


    D'abord, c'est du TCP, et non de l'UDP. Ensuite, comme je l'ai signalé en fin de mon message, j'avais peur d'avoir à  passer en C, chose que je sais faire. Mais merci de ton aide tout de même.




    'yoann' a écrit:


    Sinon pour les socket en C pur, attention aux buffer over flow quand même. ça demande une vérification de code un peu plus poussé qu'avec un code en Cocoa qui gère automatiquement l'allocation des buffer et encapsule tout ça en NSData.


    Bon, dans mon cas, les sockets sont toujours de même tailles.





    J'pense avoir réussi avec ces fichues sockets via le tuto que j'ai cité. Je checke tout ça dans la journée.
  • LarmeLarme Membre
    #19
    Bon.

    Juste pour vous dire que ça marche, au moins pour l'envoi de trames, le " retour " n'étant pas encore implémenté sur le Robot.

    J'ai pratiquement utilisé tout ce qui était sur le lien précédemment cité.



    Je recommande donc ce tuto.



    Merci d'votre aide en tout cas image/wink.png' class='bbc_emoticon' alt=';)' />
  • iTogueshiToguesh Membre
    #20
    Si tu veux mon avis (projet d'école aussi ^^) ou je dois contrôler un robot, je le fait en UDP.

    Quand tu y pense, c'est beaucoup plus simple.

    Un socket ou tu reçois les données de ton robot, et une ou tu lui envoi les trames. Indirectement avec un système de Watchdog sur ton retour tu sauras si tes cmds sont bien passés.
  • LarmeLarme Membre
    #21
    TCP, c'est le bien image/tongue.png' class='bbc_emoticon' alt=':P' />

    Et au final, ce n'est pas si compliqué que ça.

    En fait, manquait juste un exemple sur lequel me baser et broder avec.

    J'ai déjà  de l'UDP pour un flux Audio (si j'arrive à  l'trouver), et encore du TCP pour de la vidéo.

    Pour l'audio en UDP par exemple, je vais me baser sur ce que j'ai fait en TCP et tenter de m'en sortir avec les classes que j'ai. En bref, me manque un truc de base à  partir duquel partir.
  • yoannyoann Membre
    #22
    'iToguesh' a écrit:


    Si tu veux mon avis (projet d'école aussi ^^) ou je dois contrôler un robot, je le fait en UDP.

    Quand tu y pense, c'est beaucoup plus simple.

    Un socket ou tu reçois les données de ton robot, et une ou tu lui envoi les trames. Indirectement avec un système de Watchdog sur ton retour tu sauras si tes cmds sont bien passés.




    Très mauvaise idée de passer par de l'UDP pour de l'envois de commande, surtout si c'est pour ensuite refaire par dessus un mécanisme d'acquittement et de retransmission...



    L'UDP serait par contre réellement utile si vous avez des caméra et micro sur le robot, là  diffuser en UDP a un réel intérêt puisqu'on cherche du temps réel, du monitoring. Si une trame est perdu on s'en fou de la récupérer, ce qu'on veut c'est du temps réel.
  • zoczoc Membre
    juin 2012 modifié #23
    'yoann' a écrit:


    Très mauvaise idée de passer par de l'UDP pour de l'envois de commande, surtout si c'est pour ensuite refaire par dessus un mécanisme d'acquittement et de retransmission...


    Surtout pour du sans fil, où tu es certain d'avoir un taux de perte non nul. Tu peux te retrouver alors avec tout un tas de cas bien tordus:
    • Commande envoyée mais pas reçue: Problème réglé coté émetteur par un timeout.
    • Commande envoyée, reçue, traitée, acquittement unique envoyé mais perdu: Cas indétectable vis à  vis du premier coté émetteur, donc désynchronisation entre l'état réel du système et l'état perçu.
    • Commande envoyée, reçue, traitée, acquittements multiples (tant que la commande est active), certains perdus: Un peu mieux, mais potentiellement déclenchement du timeout si perte des premiers acquittements, d'où une désynchronisation temporaire de l'état et un algo bien plus compliqué coté émetteur pour "retomber sur ses pattes" (réception acquittement après timeout...).
    • Commande envoyée, reçue, mécanisme d'acquittement à  base d'UDP (avec tous les problèmes de perte des paquets, donc compliqué), traitement: Là  on s'assure que la commande a bien été reçue avant d'autoriser son traitement. Oh wait ! c'est exactement ce que TCP fait !


    l'UDP, c'est bien pour les données en streaming, et à  la limite pour les requêtes qui ne modifient pas l'état du service distant (genre requêtes d'interrogation DNS, tu peux en relancer une autre si tu ne reçois pas de réponse ,sans modifier l'état du système)... Tu perds un paquet en streaming audio, tu entends un scratch, mais fonctionnellement ça ne change rien. Même chose en streaming vidéo. Paquet perdu = artefact à  l'affichage, mais on s'en fout généralement (si évidemment la méthode de compression employée supporte la reprise suite à  une perte partielle du flux).
  • iTogueshiToguesh Membre
    #24
    Non, Du moins oui mais non.

    Explications:

    Envoi cmd avec un indicateur de commande genre si c'est la 1ere commande

    CMD=1,cmd; Où 1 est le numéro de la commande envoyé et cmd la commande en elle meme.

    Avec une autre socket en UDP. Si il trouve une erreur, il t'envoi un code d'erreur, et par conséquent tu veux rectifier le numéro de commande.



    Par contre je vois pas comment vous faites pour la video en UDP. Moi je reçois mon flux video mais incapable de l'affiché. Désolé du HS ^^
  • yoannyoann Membre
    #25
    'iToguesh' a écrit:


    Non, Du moins oui mais non.

    Explications:

    Envoi cmd avec un indicateur de commande genre si c'est la 1ere commande

    CMD=1,cmd; Où 1 est le numéro de la commande envoyé et cmd la commande en elle meme.

    Avec une autre socket en UDP. Si il trouve une erreur, il t'envoi un code d'erreur, et par conséquent tu veux rectifier le numéro de commande.




    Tu n'as donc rien compris aux explications que nous venons de donner ?



    Tu es en train de refaire EXACTEMENT le fonctionnement du TCP sur de l'UDP, à  savoir des numéros de séquence avec un retour d'acquittement et un système de replay en cas de non réponse (et un système d'élimination des paquets doublé au passage).



    Il n'y a aucun intérêt à  faire ce que tu fait.
  • DrakenDraken Membre
    #26
    TCP .. chaque fois que je lis ce terme j'ai l'impression que c'est une Taxe sur les produits Pétroliers.
  • zoczoc Membre
    #27
    'yoann' a écrit:


    Tu es en train de refaire EXACTEMENT le fonctionnement du TCP sur de l'UDP


    Non, même pas, il fait un TCP au rabais, puisque sa solution ne fonctionne pas dans tous les cas que j'ai cités (pertes d'acquittements qu'il faut aussi gérer).



    Mais bon, c'est ça les étudiants, ça veut réinventer la roue sans imaginer tout ce qu'il y a derrière image/wink.png' class='bbc_emoticon' alt=';)' />
  • iTogueshiToguesh Membre
    #28
    'zoc' a écrit:


    Non, même pas, il fait un TCP au rabais, puisque sa solution ne fonctionne pas dans tous les cas que j'ai cités (pertes d'acquittements qu'il faut aussi gérer).



    Mais bon, c'est ça les étudiants, ça veut réinventer la roue sans imaginer tout ce qu'il y a derrière image/wink.png' class='bbc_emoticon' alt=';)' />


    C'est pour ça que je suis sur ce forum. Pour qu'on nous conseille et qu'on nous explique. ^^



    Quoi que, quand j'aurais développer mon décompresseur de video P264 avec l'objet qui l'affiche, y'en a bien un qui va me dire que ça existe déjà  image/grin.gif' class='bbc_emoticon' alt=';D' />
  • yoannyoann Membre
    juin 2012 modifié #29
    'iToguesh' a écrit:


    C'est pour ça que je suis sur ce forum. Pour qu'on nous conseille et qu'on nous explique. ^^



    Quoi que, quand j'aurais développer mon décompresseur de video P264 avec l'objet qui l'affiche, y'en a bien un qui va me dire que ça existe déjà  image/grin.gif' class='bbc_emoticon' alt=';D' />




    P264 ou H264 ? Si c'est du H264 oui tu as tout ce qui faut d'origine (et il vaut mieux s'en servir puisqu'il utilise du décodage matériel si je me souviens bien). Si c'est du P, jamais entendu parler, mais à  voir si c'est pas du H alléger et rétrocompatible.



    Sinon être sur un forum pour qu'on te conseil et t'explique c'est bien, mais il faut écouter aussi. 4 messages identique pour te dire qu'il faut prendre TCP au lieu de UDP c'est à  peine lourd...



    Au passage, c'est quoi ton école qui ne t'explique même pas l'intérêt de choisir TCP au lieu d'UDP ?
  • iTogueshiToguesh Membre
    juin 2012 modifié #30
    Mon école est un lycée (La Fayette) et j'ai été obligé de prendre de l'UDP parce que le fabriquant du robot (drone) n'est autre que Parrot et qu'on est obligé de se soumettre au protocole du joujou.

    Merci Parrot image/cliccool.gif' class='bbc_emoticon' alt=' :p ' /> Et c'est bien du P264 image/smile.png' class='bbc_emoticon' alt=':)' />



    J'ai exposé mon problème içi: [url="http://forum.cocoacafe.fr/topic/8984-affichage-flux-video/page__hl__+flux++vidéo__fromsearch__1&quot;]http://forum.cocoaca...__fromsearch__1[/url]



    J'prefere redirigé qu'on ne s'égare pas sur le post du garçon image/smile.png' class='bbc_emoticon' alt=':)' />



    PS: C'est vrai que je suis têtu quand je m'y met image/dry.png' class='bbc_emoticon' alt='<_<' /> image/xd-laugh.gif' class='bbc_emoticon' alt='xd' />
  • LarmeLarme Membre
    #31
    Mais t'inquiètes, mon problème est réglé vu que j'ai clairement pu contrôler mon Robot :°)
Connectez-vous ou Inscrivez-vous pour répondre.