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
code c pour sockets (udp vers tcp et inversement)
Bonjour,
J'ai déjà fait des sockets (client et serveur) udp qui communiquent entre elles et tcp qui communiquent entre elles.
Mais là, je cherche du code en C qui me permettrait de faire communiquer via des sockets un client udp avec un serveur tcp par exemple ou bien un client tcp avec un serveur udp... Qui pourrait m'aider?
merci d'avance.
Salut,
Sauf erreur de ma part, ça n'est pas possible sauf si tu codes un truc qui prend les paquets UDP, les examine, et envoie un paquet TCP apres au serveur TCP.
Rappel : UDP mode non connecte / TCP mode connecte
donc pour moi cette manipulation n'est pas possible, en tout cas, si elle l'est je vois pas dans quelles conditions elle est utile...
Re: code c pour sockets (udp vers tcp et inversement)
Envoyé par HiT
Il faut probablement faire un routeur. Il faut au moins 2 acces réseau.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Mais si tu as une machine Linux avec 2 cartes Ethernet, ça se fait en quelques lignes de configuration de IProute...
[EDIT]
C'est complètement idiot de faire comme ça, et ça ne marchera pas.
Il faut en fait faire une 'boucle applicative' avec 2 serveurs
- TCP -> UDP
Créer une connexion 'serveur' TCP
Lorsqu'on recoit des données (recv), les réémettre en UDP à qui de droit (sendto)- UDP -> TCP
Créer un serveur UDP
a chaque trame UDP reçue (recvfrom), se connecter en TCP, emettre la trame (send), se deconnecter.
Le tout peut être fait avec un seul process grace à select() qui peut surveiller plusieurs sockets à la fois (y compris stdin pour quitter ou passer des commandes...)
Ca peut aussi être un daemon muet et invisible...
.
je pense que tu as raison, il faut faire un code qui prend les packets tcp et les renvoie en udp ou inversement. Mais je ne vois pas comment faire, donc si qq'un a deja faite ca.... ca serait cool de me faire partager du code loool... parce que je galere la...
merci
Je te conseille surtout de faire un bout de code, le peaufiner et le soumettre ensuite, s'il reste des bugs, des interrogations
On veut bien aider mais on est pas la pour faire à la place
Bonsoir,
ce projet est totallement utopique. L'une des raisons pour lesquelles ces deux protocoles sont si differents c'est parce que ils doivent permettre la mise en place d'applications dont la nature de fonctionnement est fondamentalement differente. Si un server DNS utilise UDP sur le port 53 ce n'est pas pour rien c'est parce que ca serai trop difficile (voir meme impossible) d'obtenir le meme resultat avec TCP. Meme en passant par une "passerelle IP" tel que la propose Emmanuel Delahaye car il faudra des lors mettre en place un systeme de conversion de packet ainsi que les numeros de sequences (absent en UDP), les numeros de recu et etc..... au final, tout est faisable en logiciel seulement je suis septique sur la faisabilite en terme de temps, de ressources et etc et surtout sur l'utilite! il y a t il un besoin pour une tel chose?
En tout cas bon courrage si l'auteur persiste.
A.
Absolument, voir la correction.
Re,
je ne suis pas du tout convaincu au contraire meme. Par exemple, lorsque l'on envoie un packet en TCP l'emetteur attent un numero de reception...or si l'on transforme le message en un format qui n'a que faire si le message a ete recu ou pas.... ca marche comment votre histoire? Qui plus est, tous les parametres du model ISO sont determines par les systemes en cours de communication... comment est ce que le system intermedaire va t il faire pour immiter ces comportements sans que les nodes s'en appercoivent?
Ah oui... apres lecture sur le protocol TCP je me suis appercu que si l'on faire le socket (comme suggere pour envoye 1 trame UDP cf. ci dessus) eh bien la fois suivante l'espace memoire n'est pas le meme. En clair? eh bien un message qui necessite plusieurs trames arrivent en tant que "plusieurs" trames alors qu'il aurai du etre reconstituer.
Maintenant, je ne mets pas en doute que d'un point de vue theorique ce serai possible MAIS le programmeur n'a pas le control sur tous les aspects de la communication et surtout sur le comportement des elements communiquants....
A.
A partir du moment où un paquet TCP est recu, il est complet et valide. Il suffit alors de le renvoyer en UDP. Ca ne pose pas de problèmes particulier. Evidemment ce n'est pas très efficace, car on ne peut pas anticiper, mais ça marche...Ah oui... apres lecture sur le protocol TCP je me suis appercu que si l'on faire le socket (comme suggere pour envoye 1 trame UDP cf. ci dessus) eh bien la fois suivante l'espace memoire n'est pas le meme. En clair? eh bien un message qui necessite plusieurs trames arrivent en tant que "plusieurs" trames alors qu'il aurai du etre reconstituer.
Maintenant, je ne mets pas en doute que d'un point de vue theorique ce serai possible MAIS le programmeur n'a pas le control sur tous les aspects de la communication et surtout sur le comportement des elements communiquants....
Ce n'est pas du relayage de trame, ni du routage IP, mais une sorte de relayage de niveau 4 (TCP/UDP) (il doit y avoir un nom technique que je ne connais pas).
Dans l'autre sens, c'est pareil. Chaque paquet UDP reçu est réémis en TCP.
C'est facile à mettre en oeuvre avec 2 sockets et une adresse IP interne.
Certes pour 1 paquet. Mais 1 paquet est different d'un message! Et comme le model OSI repose sur un model de transparence c'est le message qui est important pour que tout foncitonne.
Faire du relayage a plus bas niveau du model OSI est du gateau. Si il existe tant de problemes avec les par-feux, systeme de detection d'intrusions, et autre proxy cela a du a quoi a votre avis? C'est tout bete mais ces appareils ont tendance a travailler a partir de la couche 3/4 et au dessus.
Encore une fois le message serai perdu
Je demande a voir mais je ne dispute pas la faisabilite a bas-niveau cependant faire de la traduction au niveau de l'UDP et TCP (et cela avec respect total des normes), qui sont indicatifs des services appeles dans les couches superieures du model, est une chose que je ne peux pas comprendre. Cela n'a rien a voir avec la programmation mais plutot avec les notions fundamental de communication reseaux et d'utilisation de resources distribuees.
A.
bonsoir,
Je me range du coté de Emmanuel Delahaye
Pour moi si tu crée un programme qui réceptionne des paquet TCP sur une socket et envoie les donnée sur une autre socket udp cela ne cause aucun problème.
Sur la socket tcp tout les contrôle tcp (num séquences, ack) se feront sans problème
Il reste plus qu’à prendre le champs data et l envoyer sur la socket UDP (sans contrôle).
Et c’est la même chose dans le sens inverse
Mais il est vrai qu UDP n’a pas de control ce qui pourrait causé de gros problème si un paquet udp est attendu et ne parvient jamais il faut alors cree un timer pour prévenir le client du coté socket TCP que la réponse est impossible ce qui est a définir dans le protocole applicatif.
Voilà mon point de vue
Dans le cadre d'une application client serveur , c'est ridicule sachant
que les applications qui communiquent doivent se situer sur la même couche et utiliser les mêmes protocoles.
Si je ne m'abuse un client UDP se connecte à un serveur via UDP
il faut donc qu'il soit tous les deux sous UDP, pour établir une primo connection.A l'identique en TCP.
Cordialement
Répondre avec citation
Partager