TCP

Larme · mai 2012

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

/tongue.png' class='bbc_emoticon' alt=':P' />

Larme · mai 2012

Je m'auto-réponds : J'ai trouvé ça qui a l'air pas mal, j'vais tester.

Ceetix · mai 2012

BTW c'est quoi que tu utilises comme contrôleur pour ton robot ?

Larme · mai 2012

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.

zoc · mai 2012

'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.

Ceetix · mai 2012

Je voulais dire micro-controlleur (PIC ?)

Tu as le robot tout monté déjà ou tu l'as fait toi même ?

yoann · mai 2012

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 ^^

Larme · mai 2012

Robot de la boà®te qui nous sous-traite.

Draken · mai 2012

Militaire ?

Larme · mai 2012

Non, ludique.

Il doit faire 20*20*20 cm.

Draken · mai 2012

"Paix et prospérité.."

Larme · mai 2012

Indeed, je ne développerais jamais pour l'armée...

Xodia · mai 2012

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).

yoann · mai 2012

'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.

yoann · mai 2012

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

Xodia · mai 2012

'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.

yoann · mai 2012

'Xodia' a écrit:
Bah tu fais un structure avec un buffer constant.

Genre :
 
typedef struct t_msg 
{ 
char buf[4096]; 
t_type typeMsg; 
... 
} 
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.

Larme · mai 2012

'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.

Larme · juin 2012

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

/wink.png' class='bbc_emoticon' alt=';)' />

iToguesh · juin 2012

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.

Larme · juin 2012

TCP, c'est le bien

/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.

yoann · juin 2012

'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.

zoc · juin 2012

'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).

iToguesh · juin 2012

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 ^^

yoann · juin 2012

'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.

Draken · juin 2012

TCP .. chaque fois que je lis ce terme j'ai l'impression que c'est une Taxe sur les produits Pétroliers.

zoc · juin 2012

'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

/wink.png' class='bbc_emoticon' alt=';)' />

iToguesh · juin 2012

'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 /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à

/grin.gif' class='bbc_emoticon' alt=';D' />

yoann · juin 2012

'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à /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 ?

iToguesh · juin 2012

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

/cliccool.gif' class='bbc_emoticon' alt='

' /> Et c'est bien du P264

/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"]http://forum.cocoaca...__fromsearch__1[/url]

J'prefere redirigé qu'on ne s'égare pas sur le post du garçon

/smile.png' class='bbc_emoticon' alt=':)' />

PS: C'est vrai que je suis têtu quand je m'y met

/dry.png' class='bbc_emoticon' alt='<_<' />

/xd-laugh.gif' class='bbc_emoticon' alt='xd' />

Larme · juin 2012

Mais t'inquiètes, mon problème est réglé vu que j'ai clairement pu contrôler mon Robot :°)

TCP

Réponses