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.

[FabaCoeur]

Encore merci pour tes réponses exhaustives.
Je suis hébergé chez -masqué-, un hébergeur américain qui autorise l'accès SSH.
Ce soir je tente un upload, une connexion SSH pour lancer l'exécutable, et je tente de rejoindre avec un client.

[FabaCoeur]

Ca fonctionne !
J'ai uploadé le serveur par FTP, ensuite je me suis connecté en SSH pour lancer le serveur en écoute sur mon hébergement, et je peux communiquer avec mon client en rejoignant sur mon 'www.domaine.com'.

Enfin ça semble fonctionner, en réalité je ne sais pas encore comment compiler mon projet CodeBlocks pour faire un build linux, mais la solution viendra par la suite.

En revanche, l'arborescence de mon hébergement ne contient pas de dossier particulier pour stocker mon serveur. Si j'ai bien compris l'emplacement importe peu (on cherchera toujours à 'www.mondomaine.com'), ce qui fera la différence ça sera le port en écoute, c'est bien ça ?

Une autre question: pour lancer le serveur, je me connecte en SSH (étant sous Windows, je passe par Putty). Une fois que je quitte Putty, le serveur s'arrête. Comment faire pour laisser tourner le serveur en permanence ?

[Obsidian]

Ca fonctionne ! [...] En revanche, l'arborescence de mon hébergement ne contient pas de dossier particulier pour stocker mon serveur. Si j'ai bien compris l'emplacement importe peu (on cherchera toujours à 'www.mondomaine.com'), ce qui fera la différence ça sera le port en écoute, c'est bien ça ?

C'est bien ça. Il n'y a aucune corrélation entre le réseau TCP/IP et l'arborescence locale du système de fichier de ton serveur (en revanche, il y en a avec les sockets Unix). Cela dit, c'est quand même mieux si tu prends dès le départ l'habitude de mettre les exécutables à leur place.

Une autre question: pour lancer le serveur, je me connecte en SSH (étant sous Windows, je passe par Putty). Une fois que je quitte Putty, le serveur s'arrête. Comment faire pour laisser tourner le serveur en permanence ?

Sur un système UNIX, tu peux utiliser la commande nohup dans un premier temps, mais il faudra très vite apprendre à faire un daemon, soit un processus autonome fonctionnant en tâche de fond.

L'idée est de forker, d'émanciper le processus de la session courante pour la rattacher à init, et de laisser le père se terminer normalement et rendre la main au shell.

[FabaCoeur]

Bonjour,

Très bien, je placerai l'exécutable dans /usr/local/bin pour être un peu standard.

Je ne connais pas "nohup" sous linux, mais je sais forker et faire des deamon (du moins on en a déjà fait en cours de programmation système sous Linux il y a quelque temps).

Petite question pour rappel: une fois que le deamon est crée, il est donc rattaché au processus supérieur (disons celui qui est à la base de tous les processus). Comment est ce que je peux conserver son pid si jamais je veux l'arrêter (pour relancer le serveur par exemple) ?

[ram-0000]

Un article ici pour créer un daemon Unix

En général, un démon créé un fichier /var/run/<daemon> (ou quelque chose comme cela) dans lequel il inscrit son numéro de pid

Cela permet des trucs du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

kill -HUP `cat /var/run/<daemon>`

[FabaCoeur]

à tous pour vos réponses, et en particulier à Obsidian