Discussion :

[FabaCoeur]

Bonjour,

J'ai fait une application réseau comprenant un exécutable serveur et un exécutable client qui communiquent très bien. Jusqu'a maintenant, j'ai fait les tests en local en lançant le serveur et en connectant chacun des clients à 127.0.0.1. J'utilise arbitrairement le port 1987 pour communiquer.

Ensuite j'ai fait le test sur mon réseau local avec 2 machines.
Et là déjà premières difficultés: si le par feux de Windows est activé sur une des deux machines, la communication est impossible.

Je voudrais savoir comment déployer mon application:

• Si je suis sur un réseau local dont je ne peux pas paramétrer le par feux Windows, je ne peux pas utiliser mon application. Comment passer outre ?
• Je désirerai utiliser mon application non plus seulement en réseau local, mais passer par Internet. C'est à dire qu'il serait possible de créer un serveur sur une machine, et de le rejoindre viens un client sur une machine distante via Internet. Cela est-il possible ? J'imagine que les barrières concernant le port utilisé va être plus large. Cependant certains jeux en réseau doivent bien fonctionner de la même manière, non ?

Merci de m'éclairer sur une domaine que je ne connais pas du tout.

[Obsidian]

Bonsoir,

Ensuite j'ai fait le test sur mon réseau local avec 2 machines.Et là déjà premières difficultés: si le par feux de Windows est activé sur une des deux machines, la communication est impossible.

C'est à ça qu'ils servent (ou alors, j'ai manqué quelque chose).

Si je suis sur un réseau local dont je ne peux pas paramétrer le par feux Windows, je ne peux pas utiliser mon application. Comment passer outre ?

Il faut inviter l'utilisateur à demander à son administrateur d'ouvrir le port.

Je désirerai utiliser mon application non plus seulement en réseau local, mais passer par Internet. C'est à dire qu'il serait possible de créer un serveur sur une machine, et de le rejoindre viens un client sur une machine distante via Internet. Cela est-il possible ? J'imagine que les barrières concernant le port utilisé va être plus large.

Non, à priori, cela fonctionne rigoureusement de la même façon. Seulement, il faut que l'adresse de la machine distante soit publique. C'est automatiquement le cas quand tu te connectes par le RTC avec une *box ADSL configurée par défaut en mode transparent. C'est d'ailleurs tout le paradoxe des pare-feux personnels : on met en place une pile TCP/IP qui écoute l'extérieur, avec une adresse publique faite pour pouvoir être contactée, et on met en place par dessus des logiciels pour entraver son fonctionnement. C'est comme si tu te faisais installer le téléphone et que tu ajoutais un boîtier pour empêcher les gens d'appeler. :-)

Sauf qu'aujourd'hui, la plupart des boxes ADSL sont configurées en routeur (ce qui est très bien comme çà). Le cas échéant, il faut que tu la configures pour router le trafic entrant sur ton port vers une adresse IP privée locale et que tu mettes cette adresse en fixe sur la machine concernée.

[FabaCoeur]

Bonsoir,

Et merci pour ces réponses.

Il faut inviter l'utilisateur à demander à son administrateur d'ouvrir le port.

Dans ce cas là, est-il possible de connaître les ports qui seraient ouvert par défaut? Il suffirait alors de pouvoir paramétrer le port sur l'application.

Une autre idée de fonctionnement que j'avais eu: est-il possible de faire tourner l'application serveur sur une machine distante (typiquement un hébergement web par exemple) et de s'y connecter avec un client en local ?

[Obsidian]

Dans ce cas là, est-il possible de connaître les ports qui seraient ouvert par défaut?

Pas directement. Il faut interroger le pare-feu, mais en principe, tu ne devrais pas avoir à le savoir.

Il suffirait alors de pouvoir paramétrer le port sur l'application.

D'une manière générale, c'est toujours une bonne idée d'en laisser la possibilité à l'utilisateur.

Une autre idée de fonctionnement que j'avais eu: est-il possible de faire tourner l'application serveur sur une machine distante (typiquement un hébergement web par exemple) et de s'y connecter avec un client en local ?

Absolument. C'est d'ailleurs ce que tu fais déjà sans le savoir. Ton serveur sur ta machine locale se trouve sur une machine distance aux yeux de ton client.

[FabaCoeur]

Bonjour,

Dans ce cas, je vais plutot essayer d'utiliser un serveur web.
Ce qui m'apporte pas mal de questions:
1) Il me suffit de compiler mon exe sous environnement Linux (le serveur l'est) et de le placer n'importe ou ?
2) Ensuite comment le lancer ? Je peux accèder en SSH sur mon hébergement, c'est pas là qu'il faut que je le fasse ?
3) L'exécution de tel programme est-il autorisés sur tous les hébergements ? Comment savoir si le miens l'autorise ?
4) Je suppose maintenant que le serveur est en place, et lancé. Comment connaitre l'adresse à laquelle se connecter ? Sur mon hébergement je peux ajouter des sous demaines. Est ce que je pourrais faire pointer monssdomaine.mondomaine.com sur mon serveur ?

Désolé de bombarder de question mais je suis vraiment dans le flou !

Cordialement,

[Obsidian]

Bonjour,

Dans ce cas, je vais plutot essayer d'utiliser un serveur web.

Pourquoi un serveur web ? Si tu parles d'un hébergeur, la plupart des F.A.I. ne te laisseront pas lancer un exécutable binaire sur leur propre serveur. En revanche, des applications en PHP voire en Perl, c'est plus probable. Si tu loues, en revanche, un serveur dédié, c'est possible.

Ce qui m'apporte pas mal de questions:
1) Il me suffit de compiler mon exe sous environnement Linux (le serveur l'est) et de le placer n'importe ou ?

Ça dépend de ce que tu entends par « n'importe où ». D'une manière générale, ton serveur est une application comme une autre. Si « n'importe où » se réfère au système de fichier, il y a des hiérarchies de répertoires dédiés à tous les types de ressources du système, définies par le FHS. « /usr/local/bin » est un bon choix. Si tu fais quelque chose de plus compliqué, il faudra un jour faire un package.

2) Ensuite comment le lancer ? Je peux accèder en SSH sur mon hébergement, c'est pas là qu'il faut que je le fasse ?

Tu es hébergé où ?

Si tu as un shell, tu peux lancer une application. Maintenant, tu ne seras probablement pas tout seul sur cette machine, et tu ne pourras probablement pas utiliser le réseau de manière complètement libre.

3) L'exécution de tel programme est-il autorisés sur tous les hébergements ? Comment savoir si le miens l'autorise ?

Non, la plupart du temps, tu ne peux pas exécuter de binaire (enfin c'était comme ça il y a quelques temps). Essaie d'en lancer un pour le savoir ou pose directement la question à ton hébergeur.

4) Je suppose maintenant que le serveur est en place, et lancé. Comment connaitre l'adresse à laquelle se connecter ? Sur mon hébergement je peux ajouter des sous demaines. Est ce que je pourrais faire pointer monssdomaine.mondomaine.com sur mon serveur ?

Bon. Ça, c'est deux choses différentes. L'adresse de ton serveur, c'est celle de ta machine, tout simplement. Si ta machine dispose de plusieurs adresses, elles sont toutes utilisables par défaut, sauf si ton application a choisi de n'en écouter qu'une en particulier. C'est d'ailleurs à ça que servent les numéros de port en TCP/UDP : faire le distingo entre les différentes applications.

Par contre, monssdomaine.mondomaine.com risque de te poser des problèmes. Ce que tu appelles ici monssdomaine, c'est généralement le nom de machine. Ainsi les sites web commencent généralement par « www » car « www » est le nom de la machine d'un domaine qui héberge le serveur web. Donc, en théorie, c'est la manière normale de contacter un serveur (c'est l'O.S. du client qui résout automatiquement l'URL en adresse IP en s'appuyant sur le DNS).

Sauf que dans le cas des pages web, si tout le monde peut avoir une adresse du style « obsidian.monhebergeur.fr », tu te doutes bien qu'il n'y a pas une machine par abonné, ni même une adresse IPv4 publique. En fait, toutes ces URL pointent la même adresse IP et le serveur ne peut pas savoir quelle URL a été utilisée pour l'appel. Le fait que tu te retrouves malgré tout sur le bon site est attribuable au protocole HTTP/1.1 qui spécifie « Host: ». Ça veut dire que ton navigateur redit au serveur web quel hôte il a cherché à joindre. C'est pour cela aussi que ces sites ne peuvent fonctionner en HTTPS. Tu ne pourras donc pas héberger ton serveur sur un port arbitraire par ce biais, à moins de disposer d'une adresse dédiée.