Discussion :

[jt-tronix]

Bonjour tout le monde,
J'ai fait quelque recherche mais je n'ai pas trouver grand chose, surtout en Delphi, qui n'ai pas très optimiser pour ce genre de logiciel, mais je connais trop mal le C/C++ pour me lancer dans la création de ce genre de logiciel dans ce language.

Un logiciel de tunneling consiste à relier deux machines distantes ou plus en réseau, par un ou plusieurs ports, en utilisant la connection Internet.
Ce qui permettrait de jouer à un jeu utilisable uniquement en réseau local.

J'espere que vous pourrez m'aider ou du moins me donner quelques pistes, merci...

[Jipété]

Ben, les composants Indy (ou d'autres) sont faits pour ça, non ?

Si tu les as pas (Delphi perso), ils sont installables, je crois, et ceux de François Piette sont sympa aussi, avec une FAQ et des exemples/démos sur le ouaibe...

J'ai pas les liens sous la main, mais google est ton ami !

Ça ira ?

Sinon,

par un ou plusieurs ports

ça signifie un ou plusieurs composants, qui vont gérer une liste de ports et tout ça... Bon courage !

JP

[Sub0]

Il ya quelques temps, j'avais étudié la question pour la réalisation d'un tchat client/serveur avec un tunnel sur le port http (80). En effet, je voulais utiliser les composants Delphi TClientSocket et TServerSocket pour établir une communication, mais comme le port 80 est déjà pris, le serveur doit utiliser un autre port, et cela est bloqué avec certains firewalls (surtout des entreprises). La solution était donc l'utilisation d'un tunnel. J'ai trouvé sur le net plein d'explications sur le fonctionnement du tunnel et même une démo sur le site d'ICS (François Piette) mais je ne l'ai pas testée...

Par contre, en relisant ton message, tu n'es pas obligé d'utiliser le port http, tu peux apparemment te permettre d'utiliser n'importe quel port. Cela revient donc à une communication directe par socket où il suffit de choisir un port de communication semblable pour les 2 machines. Le serveur reçoit l'IP du client et le serveur lui répond en lui donnant à son tour son IP, et la communication est établie. Voici une démo de Nono40 qui permet d'utiliser ce système pour transférer un fichier avec les composants standarts TClientSocket et TServerSocket, cela devrait te convenir pour commencer je pense :

http://nono40.developpez.com/sources/source0015/

Le tunneling, c'est autre chose: On utilise un port de communication pour ensuite le rediriger sur un autre. Par exemple, utiliser le port 8080 pour retransmettre des données sur le port 6000...

à+

[jt-tronix]

Merci pour votre aide, je vais essayer de me documenter sur Indy, je l'avais déjà utiliser pour faire des requetes FTP et HTTP, mais je ne savais pas qu'il pouvait me permettre ce genre d'utilisation.

[jt-tronix]

Bonjour
En fait ce que j'ai à faire est un petit peu plus compliqué :
J'ai :
une console de jeu en réseau utilisant les ports UDP/TCP 3074 et UDP 88
reliée en réseau à un ordinateur
ce dernier étant relier par internet à un autre ordinateur où est connecté ce même type de console.

J'ai donc penser utiliser les composant indy TCP serv, UDP serv, TCP client et UDP client, mais l'envoi vers l'autre ordinateur et la reception doivent se faire simultanément.

De plus, en même temps le programme doit faire marcher d'autre compos client/serveur afin de rediriger les packets vers la console.

J'aimerais donc savoir, si c'est réalisable et simple à concevoir ou si je peux abandonner tout de suite.
Et aussi, comment puis-je faire fonctionner tout sa en même temps.
Merci

[jt-tronix]

Bonjour,
J'ai trouvé dans les composants Indy les composants IdMappedPortUDP et IdMappedPortTCP (dans Indy Server).
Ces composants servent à rediriger un port vers une adresse sur un autre(ou même) port.
Cependant, je n'arrive pas à en saisir le fonctionnement, en effet, un port peut-être entrant et sortant, j'ai donc mis un composant TCP en port 3074 vers l'ip de l'ordinateur distant, donc les informations sortant de ma xbox arrivent bien (du moins je pense) a l'ordinateur distant, mais lorsque l'ordinateur distant m'envoi des information par ce même port, comment puis-je arriver à les renvoyer vers ma xbox, puisque je pense (si j'ai bien compris) que delphi va donc prendre ce qui arrive sur ce port 3074 et les renvoyer vers l'ordinateur distant, et non ps vers ma xbox.

S'il vous plait aidez moi je desespère !!!

[Sub0]

Dans une connexion entre 2 machines, l'une est serveur, l'autre cliente. Le client se connecte au serveur, puis le serveur lui répond. Pour le moment, tu envois les données sur l'ordinateur distant. Sur ce PC doit tourner un programme serveur à l'écoute du port qui redirigera les données reçues vers le port de la Xbox... Autrement dit, cela signifie peut-être que tu dois réaliser 2 programmes :

• Un client qui envoit des données venant de ta console émettrice vers l'ordinateur distant.
• Un programme serveur qui écoute le port et puisse rediriger les données venant de la console émettrice vers la console receptrice.

Désolé, je ne pourrais te dire comment l'obtenir avec ces composants Indy. Mais tant que tu gardes à l'esprit le principe de fonctionnement, je pense que tu trouveras la solution.

[EDIT]

Le tunneling, c'est autre chose: On utilise un port de communication pour ensuite le rediriger sur un autre. Par exemple, utiliser le port 8080 pour retransmettre des données sur le port 6000...

Selon moi, le fait que tu utilises un tunnel n'est pas forcément la bonne méthode. Peut-être que tu n'en as pas besoin : Tu devrais dans un 1er temps essayer de connecter les 2 consoles directement, chacune étant reliée à un PC dont tu connais l'IP, et comme tu connais déjà le port des consoles, il suffit de reprendre le code d'une démo de communication client-serveur et de redéfinir le port et l'IP utilisés. Selon moi, la communication console <-> PC est transparente, la redirection automatique (sauf avec un firewall). Autrement dit, ta console devrait être directement accessible avec le n° de port et l'IP de son PC où elle est connectée. Tu n'as pas à t'occuper de rediriger les données.

Attention, il se peut aussi que la console utilise un port pour l'emmision et un autre pour la reception... As-tu un moyen de vérifier que la xbox reçoit / envoit bien des données ?

ps : J'espère ne pas avoir dit de bétises, je ne suis pas un pro du réseau.

[jt-tronix]

Merci pour ta réponse sub0 !
Ma console utilise le même port en émission et reception, je l'ai trouvé à l'aide d'un logiciel montrant l'utilisation du réseau sur tel ou tel carte réseau.
Tu as peut-être raison en disant que cela peut-être transparent, je vais pour l'instant abandonner ce composant mappedport, et faire avec ta méthode : client/serveur.
Merci, je te tiens au courant si ça fonctionne.

PS :

ps : J'espère ne pas avoir dit de bétises, je ne suis pas un pro du réseau.

Moi non plus, c'est pour ça que j'ai besoin d'aide ^^

[Sub0]

Alors, ça progresse ?

[jt-tronix]

Salut,
lol, on va dire que sa progresse, même si je n'ai pas trop eu le temps, n'étant pas là en fin de semaine ^^ !
J'ai tout revu, puisque malgrès tout mes test rien ne marchait, j'ai fait un programme de chat UDP tout simple, et ça ne marchait pas non plus, donc là, j'avais un serieux problème, si déjà un programme si simple ne marche pas, je suis pas près de faire marcher le reste...
J'ai finalement trouver, en jonglant avec les ports du routeur du parefeu et de tout le bazard, ce petit programme marche, c'est déjà bien ^^. Cela m'a déjà mieux appris comment utiliser le protocole UDP, je vais donc a présent essayer de refaire mes test, dès que mon amis testeur aura enfin compris comment débloquer ces ports ^^. J'ai un peu d'espoir pour qu'en fin de semaine tout marche ^^ !

Dès que j'aurais réussi, faudra que je trouve comment faire pour le faire fonctionner, même avec un parefeu ou un routeur...

[Sub0]

Tu as lu ce sujet ?
http://developpez.net/forums/showthread.php?t=198303

[jt-tronix]

J'étais justement en train de le lire,en tapant mon message précédent ^^

[netdoor.fr]

Selon moi, le fait que tu utilises un tunnel n'est pas forcément la bonne méthode. Peut-être que tu n'en as pas besoin : Tu devrais dans un 1er temps essayer de connecter les 2 consoles directement, chacune étant reliée à un PC dont tu connais l'IP, et comme tu connais déjà le port des consoles, il suffit de reprendre le code d'une démo de communication client-serveur et de redéfinir le port et l'IP utilisés. Selon moi, la communication console <-> PC est transparente, la redirection automatique (sauf avec un firewall). Autrement dit, ta console devrait être directement accessible avec le n° de port et l'IP de son PC où elle est connectée. Tu n'as pas à t'occuper de rediriger les données..

Non, sub0, la transparence n'est pas assurée, il n'y a pas de routage natif des paquets, les paquets destinés à la machine x.x.x.x sur le port y seront analysés et traités (si un programme veut bien les traiter) uniquement par cette machine. La console ne recevra rien. Il faut un logiciel qui route les paquets reçus par le pc vers la xbox.

En fait, il y a une nuance importante entre le tunneling et ce dont tu parles qui consiste en fait à faire du port forwarding. Le tunneling consiste à prendre, en tout cas c'est la manière dont je le définirais, le traffic réseau qui nous interrésse et à l'envoyer tel quel dans un "tunnel" (en fait, c'est de l'encapsulation de paquet ), le port forwarding consiste à modifier l'en-tête des paquets IP.

Lorsque l'on fait du tunneling, ce qui est important, c'est la transparence, surtout vis à vis de systèmes propriétaires dont les secrets nous échappe.
(Je vous laisse imaginer que pour chaque jeu le port peut changer, et ne parlons pas du contenu de la plage de données des paquets).

Ainsi, modifier un paquet émis par la xbox est une chose périlleuse.
Ce n'est pas de modifier le paquet en soi qui est périlleux, mais c'est par cet acte de se risquer à lui oter son intégrité et son authenticité. En somme, il se peut fortement que les xbox ignorent ce paquet une fois modifié. :0(

Par ailleurs, pour modifier un paquet il faut le lire, aie, et lire est une opération couteuse en temps. Si la XBOX utilise UDP c'est parce qu'il s'agit de jeux en temps réel, et que la retransmission de paquet manquant ne nous interrésse déjà plus puisque le paquet retransmis correspondra certainement à une situation de jeu antérieure (cad dont on se fiche éperdument). Il vaut mieux éviter de modifier un paquet!

C'est pour, entre autres, ces raisons que l'émulation d'un LAN à travers Internet se fait par du pure tunneling, pour ne pas avoir à se soucier de la nature des paquets capturés.

Néanmoins, c'est à tester, si en captant un paquet de la xbox, en le routant à travers Internet vers un autre PC (cad en modifiant les ports et l'IP du paquet de la xbox), cela marche (cad que l'autre console en tient compte), tant mieux, celà évite l'overhead du tunnel (l'encapsulation est couteuse car elle rajoute des données inutiles à la console) mais conceptuellement ce n'est pas un bon choix.

Là ou le problème se corse, surtout quand on ne veut pas utiliser de tunnel ( on va dire qu'un tunnel c'est du TCP), c'est lorsque les paquets qui nous interressent sont de l'UDP (c'est le cas avec la xbox).
Pourquoi? Et bien c'est assez simple, tu prends un paquet UDP de taille supérieure au MTU autorisé vers l'autre PC, tu le modifie et tu l'envoie, et il n'arrivera jamais, et comme UDP n'est pas en mode connecté et que le protocole ne garantit pas la livraison des paquets, il n'y aura aucune correction de cette perte.
N.B:UDP marche trés bien sur un réseau local puisque le MTU est "infini".

Je l'ai testé, dans le cadre d'émission d'objets sérialisés en Java.
Je calcule la taille de l'objet avant de l'envoyer et si la perte de celui-ci n'est pas fatale au système et que sa taille est inférieur au MTU de la liaison, je l'envoi en UDP, sinon, j'utilise un tunnel TCP qui garantit la livraison de l'objet.
J'ai patogé un petit peu avant de comprendre pourquoi des paquets UDP se perdaient...

Ce qui m'embête dans cette approche avec un tunnel TCP c'est l'introduction de lag dans une partie puisque TCP redemandera la réemission d'un paquet en cas d'erreur (paquet dont nous n'aurons alors que faire hélas...) mais aussi le Naggle Algorythm et autres joyeusetés...

Alors, j'ai pensé positionner toutes les données tunnelées en URGENT_DATA sur un socket en TCP_NODELAY avec une classe de type de service IP suivante:

- 000 - Routine
- 001 - Prioritaire
- 010 - Immédiat
- 011 - Urgent
- 100 - Très urgent
- 101 - Critique
- 110 - Supervision interconnexion
- 111 - Supervision réseau

donc je dirais 1001 1000 en binaire (http://www.frameip.com/entete-ip/#3.3_-_Service)

mais néanmoins 1000 est la valeur hexa pour un délai minimal décrit dans la http://www.frameip.com/rfc/rfc1349.php

Bref j'en sais rien, faudrait tout tester...:-s

Si y'a des pros dans le coin pour configurer TCP pour tunneler de l'UDP le plus vite possible avec le moins de fiabilité possible...je suis preneur :0)