Discussion :

[nonozor]

Bonjour,

Je voudrais faire un processus serveur qui communiquerait avec un processus client. Cependant, il y a un problème dont je n'ai pas trouvé la solution sur internet:
Pour que mon processus client se connecte à mon processus serveur, il faut qu'il connaisse le port qu'il utilise. Il faut donc que ce port soit codé en dur dans le code du client. Or, si le port en question est déjà utilisé par un autre processus quand je lance le serveur, celui ci ne pourra se connecté. Il faut donc qu'on lui donne un un port libre de façon dynamique, mais le client ne saura alors pas à quel port est connecté le serveur.

Pourriez vous m'indiquer une solution à ce problème où m'indiquer si j'ai mal compris le fonctionnement des sockets en client/serveur, svp?

[Médinoc]

Aucun moyen.
Le n° de port doit forcément soit être fixe, soit être connu de l'utilisateur et entré manuellement par celui-ci.

Ou plutôt, il faut toujours au moins UN numéro de port connu. Avec ça, on fait généralement des serveurs de rencontre: Ces serveurs sont les seuls dont le port est fixe, et les "petits" serveurs se connectent aux serveur de rencontre pour y annoncer leur adresse et leur port. Les clients se connectent à ces mêmes serveurs de rencontre pour connaître les ports des petits serveurs...

[ram-0000]

Il existe une solution par les RPC et le portmap Unix

En gros la mécanique est la suivante:

Le serveur se lance
il possède un identifiant d'application
il prend un port arbitrairement
il s'enregistre auprès du serveur RPC en local en donnant son identifiant d'application ainsi que son port local et d'autres info (version)
il attend
lorsqu'il s'arrrête, il se déenregistre.

Le client interroge le serveur RPC en donnant l'identifiant d'application souhaitée. En général, c'est une requête en broadcast UDP, donc pas besoin de connaitre l'adresse de la machine qui héberge pour peu qu'elle soit sur le réseau local
Le serveur RPC qui connait cette application répond en donnant
son adresse IP, son port et les autres info (version)
le client qui reçoit cette réponse n'a plus qu'a ce connecter sur le serveur de l'application désirée.

les RPC sont très utilisés sous Unix, c'est ce protocole qui est utilisé pour NFS et aussi pour YP (yellow pages). C'est peut être un peu vieux maintenant mais le concept était bon. Je ne sais pas si cela existe sous Windows.

[nonozor]

D'accord, merci.

Un serveur toujours présent enregistrant et indiquant le port utilisé par mon processus serveur semble être une bonne solution.

Cependant, je suis obligé de coder sous windows et je ne sais pas si il y a un équivalent de portmap Unix sur cet OS.

D'autre part, je n'ai pas trouvé grand chose sur l'utilisation des RPC et encore moins sur les "serveurs de rencontre", en particulier pour cette utilisation. Sauriez vous me dire où je peux trouver de la documentation sur ce sujet, svp?

[Emmanuel Delahaye]

Je voudrais faire un processus serveur qui communiquerait avec un processus client. Cependant, il y a un problème dont je n'ai pas trouvé la solution sur internet:
Pour que mon processus client se connecte à mon processus serveur, il faut qu'il connaisse le port qu'il utilise.

Oui, c'est le principe. Un port / un service (mais pas un client !)

Il faut donc que ce port soit codé en dur dans le code du client.

Oui, bien sûr. Le client doit savoir ce qu'il veut...

Or, si le port en question est déjà utilisé par un autre processus quand je lance le serveur, celui ci ne pourra se connecté.

Euh, non, pas du tout. On sait écrire des serveurs multi-clients...

http://emmanuel-delahaye.developpez.com/reseaux.htm

[Médinoc]

Euh, non, pas du tout. On sait écrire des serveurs multi-clients...

http://emmanuel-delahaye.developpez.com/reseaux.htm

Je crois qu'il fallait comprendre "celui-ci ne pourra pas se lier au port"...

[nonozor]

Pour éclaircir mes pensées par rapport à la dernière réponse, je ceux dire que si mon serveur veut se connecté à un port mais que celui ci est déjà occupé, il ne pourra l'utiliser (le bind plantera). Il faut donc que le port auquel se lie le serveur ne soit pas fixé à l'avance.
Cela crée un nouveau problème, puisque mon client ne pourra pas savoir à quel port est connecté le serveur.
Une solution proposée est un serveur de rencontre.

Auriez vous des liens à me donner sur ces serveurs de rencontres (je suis sous windows et je n'ai rien trouver sur internet) ou d'autres solutions à me proposer?

[Emmanuel Delahaye]

Pour éclaircir mes pensées par rapport à la dernière réponse, je ceux dire que si mon serveur veut se connecté à un port

Pensée confuse détectée... Un serveur ne se 'connecte pas à un port'. Il écoute sur un port donné (et un seul, du moins à ma connaissance).

mais que celui ci est déjà occupé, il ne pourra l'utiliser (le bind plantera). Il faut donc que le port auquel se lie le serveur ne soit pas fixé à l'avance.
Cela crée un nouveau problème, puisque mon client ne pourra pas savoir à quel port est connecté le serveur.
Une solution proposée est un serveur de rencontre.

Gné ? Tu veux faire un serveur multiclient UDP ? Bah, c'est pas possible, vu qu'il n'y a pas de connexion. Tout ce que tu peux faire, c'est répondre à chaque demande en temps réel, c'est tout. Si une demande est formulée pendant ce temps elle reste bloqué dans le couches basses et sera traitée ensuite par le prochain recvfrom().

Si tu veux garantir une connexion de type TCP en UDP, il faut gérer un protocole au-dessus (à la main, compliqué...) ou utiliser ... TCP ! (ben oui, simple bon sens, pourquoi faire compliqué quand on peut faire simple).

Auriez vous des liens à me donner sur ces serveurs de rencontres (je suis sous windows et je n'ai rien trouver sur internet) ou d'autres solutions à me proposer?

Bah, il ne sert pas à grand chose de copier le code des autres... Au bout d'un moment, il faut commencer à penser par soi même...

Essaye de commencer par définir clairement ce que tu veux faire, et on verra ensuite quels sont les moyens exacts à utiliser.

[nonozor]

Réponse au post précédent:

Gné ? Tu veux faire un serveur multiclient UDP ?

Essaye de commencer par définir clairement ce que tu veux faire, et on verra ensuite quels sont les moyens exacts à utiliser.

Je veux que deux processus tournant sur 2 machines différentes communiquent. J'ai donc pensé à faire un processus client et un processus serveur (en TCP), comme je l'explique dans mon premier post.
Je suis assez bon en code mais très nul en réseaux, donc n'hésitez pas à me dire si il existe une meilleure solution!

Je voudrais lancer les 2 processus, chacun sur une machine, et qu'ils établissent une connexion entre eux. Or

Pour que mon processus client se connecte à mon processus serveur, il faut qu'il connaisse le port qu'il utilise. Il faut donc que ce port soit codé en dur dans le code du client. Or, si le port en question est déjà utilisé par un autre processus quand je lance le serveur, celui ci ne pourra se connecté. Il faut donc qu'on lui donne un un port libre de façon dynamique, mais le client ne saura alors pas à quel port est connecté le serveur.

(Cf mon premier post)
Il est vrai que c'est ambigu et que je n'utilise pas le bon vocabulaire: quand je dis "si le port en question est déjà utilisé par un autre processus quand je lance le serveur, celui ci ne pourra se connecté.", le processus dont je parle est un autre processus serveur qui écoute déjà ce port et qui empèche donc mon processus serveur d'écouter ce port. (Dites moi si je me trompe, je suis toujours très nul en réseaux)

Une solution proposée par Médinoc et ram_0000 est un serveur de rencontre.

Bah, il ne sert pas à grand chose de copier le code des autres... Au bout d'un moment, il faut commencer à penser par soi même...

Je ne demande pas du code mais des liens vers des infos (les serveurs existants, leur port, leur protocole...) et des tutos expliquant comment les utiliser, car je n'ai pas trouvé grand chose la dessus sur internet. Faites une recherche google "serveur de rencontre", vous verez sur quoi vous tomberez .

Sauriez vous me dire où je peux trouver de la documentation sur ce sujet, svp?

Si quelqu'un connait une autre solution, je suis aussi preneur.

J'espère que vous comprenez mieux ce que je veux maintenant. Désolé d'avoir perdu du temps pour ces incompréhensions.
Merci d'avance de vos réponses.

[wiztricks]

Bonsoir,

Soit on cable le numéro de port du serveur pour qu'il soit connu d'avance.

Soit on utilise un répertoire de services qui vont permettre au serveur d'utiliser le port (listen) qu'il obtient et au client (connect) de récupérer le numéro de port sur lequel il a démarré.

La mécanique qui fait çà (le répertoire) est RPC/portmapper.
Ca vient de DCE (fin des années 80) et c'est disponible sous windows et linux.

Il faut que tu regarder comment déclarer le serveur et comment le client pourra récupèrer l'adresse du service RPC du serveur.

- W