UDP adapté au transfert de fichiers ?

[invite4c476a88]

Bonjour à tous,

Dans le cadre d'un projet futur, je m'apprête à réaliser une carte d'interface SDCard/Ethernet. Celle-ci consistera à venir lire des données, préalablement enregistrées en ASCII (mais non formatée en FAT) sur une SDCard, puis à les renvoyer sur un réseau IP local sous forme de paquets. L'idée est ensuite de venir récupérer ses données sur un PC Windows et les stocker dans un fichier (je n'ai pas encore déterminé comment, et si est-ce possible). Je doute sur plusieurs points et j'ai donc quelques questions :

1) De cette manière, puis-je m'affranchir de tout formatage FAT et pouvoir reconstituer les paquets de données pour les stocker dans un fichier "texte" lisible ?
2) Je pensais utiliser le protocole UDP pour sa simplicité de mise en oeuvre, et ainsi utiliser un PIC de la famille des 16F, avec le fameux chip enc28j60 pilotable directement par SPI. Est-ce pertinent et ne risque-je pas de perdre des données pendant le transfert ? (sachant que l'utilisation de fera uniquement en local et proche de la source)
3) Existe-t-il un ou des logiciels étant capable d'écouter une connexion UDP et d'enregistrer la sortie dans un fichier texte ? Si oui lequel ? (Je pense par exemple à UDP Terminal Client) Sinon je peux aussi faire un petit client UDP et rediriger le flux dans un fichier texte, mais ça me permettrait de gagner du temps qu'il en existe un tout fait .

Je vous remercie d'avance pour vos futures réponses !
-----

[invitef9ccb542]

Bonsoir,

Le protocole udp te permettra d'envoyer ou de recevoir des données (datagrammes, UDP= User Datagram Protocol) avec des appels de fonctions simples du genre "sendto" et "recvfrom" cf exemple.
Bien évidemment on peut utiliser ce protocole pour transférer le contenu d'un fichier.
En revanche il n'y a aucune vérification de la bonne transmission des données, ce qui signifie que le récepteur peut rater un bloc provenant de l'émetteur.

Pour garantir la bonne transmission des données on préfère utiliser le protocole TCP (Transmission Control Protocol, Exemple complet d'une communication client serveur).

Le seul intérêt d'utiliser UDP plutôt que TCP réside dans la vitesse de transmission des données (car le protocole TCP peut être trop lourd pour les vérifications), mais il nécessite la mise en place d'un mécanisme de validation des données pour être fiable.

La pile microchip dispose de TCP ... donc à utiliser.

[RISC]

Salut,

Pour gérer une carte SD il va te falloir un File System...
Y a-t-il une raison spéciale pour laquelle tu veux te passer du formatage FAT ??

Concernant l'UDP, il est tout à fait possible de transférer des fichiers au niveau applicatif mais...tu devras gérer toutes les erreurs possibles ...ce que fait, comme l'a mentionné jlcms, le TCP au niveau protocole ;=)

Si tu veux faire du TCP/IP, oublie la famille PIC16...(FLASH et RAM beaucoup trop petites)
Utilises plutôt un PIC18. D'ailleurs il y en a qui ont l'ethernet intégré (PIC18F97J60).

a+

[invite4c476a88]

Bonjour à tous,

Merci de m'avoir répondu si clairement sur le sujet. La raison pour laquelle je n'utilise pas de formatage FAT sur la carte est que l'écriture sur celle-ci n'est pas de mon ressort. Je suis juste censé lire les données brutes (mais organisées malgré tout) enregistrées par une autre carte électronique provenant de différents capteurs... Je ne suis pas sûr qu'il faille obligatoirement un FileSystem étant donné que le micro la liera simplement et enverra les différents paquets au PC, qui lui, les reconstituera en fichier.

Pourquoi avoir besoin de gérer toutes les erreurs possibles ? Une adaptation simple du protocole UDP ne peut-elle pas être envisageable pour faire du simple transfert de données ? L'intérêt de l'UDP c'est qu'il est selon moi, bien plus SIMPLE et rapide à mettre en oeuvre que TCP. J'ai lu plusieurs personnes qui utilisait justement ce protocole (et construisait une pile simpliste en partant de 0 avec l'enc28j60) et s'en sortait apparemment bien.

Ce que je compte faire, c'est d'écrire les différentes fonctions pour communiquer avec l'enc28j60 et d'établir une pile simpliste incluant juste IP, ARP et UDP. En revanche, je compte prendre un micro-contrôleur capable d'accueillir également la pile TCP/IP (allégée malgré tout) me laissant ainsi cette possibilité de secours dans le cas où je n'arrive pas à parvenir à mes fins, du coup, du 18F. (Par ailleurs, lequel me conseilleriez-vous ? Je voudrais avoir le module enc28j60 en stand-alone, ça me laisse la possibilité d'avoir un soft exploitable avec d'autres micros et de ne pas dépendre du 18F97j60)

J'ai trouvé plusieurs liens mettant en oeuvre l'enc28j60 sans se taper toute la pile microchip super chiante à mettre en oeuvre :
- Le projet EtherShield qui contient une librairie pour l'enc28j60 directement exploitable ainsi que quelques sources de différents protocole (DHCP, UDP, IP, ARP, TCP...) mais c'est une librairie pour µC AVR ... (https://github.com/thiseldo/EtherShield)
- Sur le site Tuxgraphic, l'auteur de l'article a écrit une librairie complète et bien faite pour l'enc28j60 mais c'est une librairie également pour AVR... (http://tuxgraphics.org/electronics/2...cle06061.shtml)
- Une autre librairie gérant l'enc28j60, cette fois-ci sur PIC, mais cette librairie est incluse dans le compilateur MikroC qui lui coûte 250€... (http://www.micro-examples.com/public...0-library.html) j'utilise pour ma part CCS mais je n'ai pas trouvé d'équivalent (j'ai pas beaucoup cherché)
- Sur ce site, l'auteur a créé plusieurs carte électronique mettant en scène l'enc28j60 sans la pile microchip. C'est cet auteur qui, à vrai dire, m'a donné cette idée de partir de 0. Selon lui, l'UDP est exploitable facilement sans trop se casser la tête, comme il l'écrit, en ayant même la possibilité de programmer sur du 16F, puisque ne demandant pas beaucoup de mémoire programme... (http://kudelsko.free.fr/ENC28J60/ENC28J60.htm)

Je pense donc m'inspirer de ces différentes ressources pour écrire une petite librairie pour l'enc28j60 via CCS, pensez-vous cela pertinent ? Existe-t-elle déjà toute faite ?

Je vous remercie *vivement* d'avance pour vos futures réponses.

[A voir en vidéo sur Futura]

[invitef9ccb542]

Bonsoir,

Non UDP n'est pas forcement plus simple à mettre en oeuvre que TCP.
En effet lors d'une communication TCP on franchit certaines étapes:
- avant d'établir la communication: à ce stade le serveur (à priori ton PIC) et en mode "listen" à l'écoute et il attend qu'un client (ton PC) cherche à se connecter (avec une fonction connect)
- une fois le client ayant demandé le "connect" chaque partie, le serveur et le client, sont connectés. Ils disposent alors d'un "socket", socket signifie chaussette, c'est en fait au sens d'un demi tuyau bouché. Il faut deux sockets (celui du serveur et celui du client) pour former un tube de communication complet. Le socket identifie totalement la liaison avec le numéro de port et l'adresse IP de chacun des connectés.
- pour envoyer des données il suffit juste de faire un "send" sur le socket d'un coté et un receive de l'autre (ça marche dans les deux sens).
- pour structurer ta communication il faut que tu mettes en place une syntaxe de message depuis le client vers le serveur. Ainsi le client peut envoyer une chaine de caractère avec un truc du genre "envoie_des_donnees <index des données> <nombre de données>"; le serveur doit attendre avec un "recv" ce type de message , ensuite le décoder et enfin, renvoyer les données correspondantes avec un format que tu choisira à ta guise.
- dans le cas où une déconnection se produit, à la fois le serveur et le client en sont informés par des code d'erreur dans les fonction recv ou send.

Si tu exécute cela en mode UDP plusieurs problème vont se rajouter:
- d'abord tu ne saura pas du coté de ton serveur si tu a un demande de connection (la notion de connection n'a pas de sens en UDP); par extention tu ne saura donc pas si tu doit attendre une demande de donnée ou si ton client attend encore des données perdues suite à un problème de connection. Il faudra donc rajouter l'échange de message pour vérifier le status de chacune des parie.
- ensuite les données qu'envoie le serveur ne seront pas forcément reçues, il faudra peut être les réémettre. Ceci se produit rarement avec des liaisons entre PC, car les PC sont beaucoup plus rapide que ce que permettent les liaisons physiques. En revanche avec un PIC dans le circuit je ne suis pas sûr que tous les datagrammes arriveront du PC vers le PIC.

Ensuite je pense que c'est vraiment une mauvaise idée de ne pas utiliser un pic18 et je pense qu'il faut suivre les conseils de RISC qui est assez expérimenté sur le sujet. Microchip propose une pile TCP/IP ici, comme tu l'as indiqué. Je pense réellement qu'il est judicieux de l'utiliser..
N'oublie pas qu'il n'y a pas que la couche de "transport" à mettre en oeuvre (TCP ou UDP) mais il y a aussi la couche de "réseaux" (IP), et attention dans la couche IP il y a tous les problèmes d'adressage à résoudre...

En conclusion je pense que, même si la pile microchip est "super chiante à mettre en oeuvre", ce sera tout de même moins pénible que de réécrire une partie de IP.

[invite4c476a88]

Bonsoir jlcms,

Merci pour ton post très clair . Effectivement, j'avais conscience du problème de "non-compréhension" de session par UDP, j'avais pensé mettre un bouton poussoir sur la carte pour lancer l'envoi des données, et que le PC soit en receive en mode "attente". Tout compte fait, ayant déjà mis en oeuvre la pile microchip (de manière très fastidieuse je l'avoue) sur un 18F67J60, je vais probablement réutiliser cette méthode. Cela dit, je ne sais pas si toi tu as déjà essayé/réussi, mais perso, je n'ai jamais réussi l'implémenter en partant d'un code source vierge, et ce, même avec les utilitaires de configuration fourni par microchip, la documentation de la pile TCP/IP, etc. J'ai du partir d'un exemple d'application mettant en oeuvre le 18F67J60 par Microchip et bidouiller/épurer les sources pour arriver au final à quelque chose de fonctionnel.

Qu'en est-il de vous autres ?

Sinon, que me conseillez-vous pour la manière dont gérer l'émission/réception ? D'implémenter bien entendu les couches les plus basses (IP, requêtes ARP, TCP) mais existe-t-il par exemple coté réception un (ou des) logiciel(s), comme un terminal TCP (ou par exemple Wireshark ?) qui puisse être en attente de l'établissement d'une connexion TCP (adresse IP + port) et me permettant d'extraire les données reçues dans un fichier ? Sinon je pourrais éventuellement le coder mais c'est également d'une autre paire de manche.

[invite4c476a88]

up ?

temp111

[invitef9ccb542]

Bonjour,

Si c'est un poussoir sur la carte avec le pic, alors:
1 - le PC intègre un petit serveur TCP (consulte l'exemple frameip ou celui de microsoft). Les étapes sur le serveur sont:

• Démarrage de la librairie Winsock avec la fonction WSAStartup
• Creation d'un socket d'écoute avec la fonction socket
• Récupération de l'interface IP avec la fonction getaddrinfo
• lien entre le socket d'écoute et l'interface (l'adresse IP) avec la fonction bind
• place le socket d'écoute en mode "écoute" avec la fonction listen
• attends qu'un client se connecte au serveur avec la fonction accept. Attention cette fonction est bloquante et on n'en sort que si un client se connecte. A l'issu de cette connection on récupère un socket de communication
• mets une boucle de réception pour recevoir tout les messages du client avec recv

2 - le pic est le client et il doit faire:

• création d'un socket et connection au serveur avec TCPOpen
• envoi des messages avec la fonction TCPPutArray

C'est à toi de décider ce que tu mets dans les messages, et bien évidemment si tu veux envoyer un bloc de x octet il faut d'abord envoyer un message du genre "envoi x" et ensuite envoyer un message avec uniquement les x octets. Le serveur pourra alors décoder le premier message et récupérer le nombre x pour savoir combien il faudra recevoir d'octets. Les fonctions recv et send ne reçoivent et n'envoient pas forcement tous les octets d'un coup, c'est à toi de faire une boucle et de vérifier les octets réellement envoyés pour tout envoyer. Pour les message de commande ("envoi x") il est préférable d'utiliser une taille fixe et connue de caractères.

Perso je ne mettrais pas le serveur du coté du PC. Je le mettrais plutôt du coté du pic car il sera plus facile de trouver l'adresse IP du pic depuis le PC que le contraire. Je n'ai jamais utiliser la pile microchip donc ceci reste des conseils théoriques, mais sur PC sur pic ou sur n'importe quoi TCP/IP est toujours le même protocole, et je ne pense pas à la lecture de la doc microchip que ce soit plus compliqué qu'ailleurs.

Enfin tu peux alternativement faire de ton pic un serveur ftp, microchip en donne un exemple ici. Je pense que cette solution est à creuser car elle est toute développée, mais dans ce cas le pic est le serveur.

[polo974]

Pour fiabiliser un échange udp (sur une liaison suffisamment fiable), il suffit de numéroter les paquets, de transmettre un checksum qui sera retourné pour "mériter" le bloc suivant.
On ne passe au suivant que si le checksum retourné est correct.

Pour le coté PC, il est très facile de faire un truc fonctionnel avec quelques lignes en python.

On peut même faire un maquettage entre 2 PC en python (pour blinder le protocole) avant de coder sur le pic.