Discussion :

[nonozor]

Bonjour,

Je voudrais faire un processus serveur qui communiquerait avec un processus client (qu'on appellera A). Cependant, il y a un problème dont je n'ai pas trouvé la solution sur internet:

Mon serveur est connecté à un port et attend que le client se connecte. Toutefois, si il y a un autre client/serveur (qu'on appellera B) qui utilise le même port, alors le serveur B peut se mettre en attente et accepter le client A, qui croira qu'il s'est connecté au client A, ou le serveur A peut se mettre en attente et accepter le client B, en croyant que c'est le client A.

Pourriez vous m'indiquer un moyen pour que mes client/serveur sache s'ils communiquent bien avec le bon processus ou me dire si j'ai mal compris le fonctionnement des sockets en client/serveur, svp?

J'ai pensé à une sorte de protocole: à la connection, le serveur doit envoyer "bonjour, je suis le serveur de Nonozor" et le client doit envoyé "bonjour, je suis le client de Nonozor", ce qui les identifierait.

[nicolas.sitbon]

Mon serveur est connecté à un port et attend que le client se connecte. Toutefois, si il y a un autre client/serveur (qu'on appellera B) qui utilise le même port, alors le serveur B peut se mettre en attente et accepter le client A, qui croira qu'il s'est connecté au client A, ou le serveur A peut se mettre en attente et accepter le client B, en croyant que c'est le client A.

J'ai rien compris!!!

[ram-0000]

J'ai l'impression que ta question en fait est "comment être sûr que je suis connecté au bon service".

Il n'y a pas de réponse 100% sûre. En effet, rien n'enterdit que je fasse tourner mon serveur telnet (port TCP 23 normallement) sur le port TCP 80 (port réservé au serveur http normallement). C'est idiot je le reconnais mais cela peut se faire.

Il faut bien voir que principalement, ce qui lie un serveur et un client est le protocole.
Si tu me dit "bonjour" et que je te répond "je mesure 1,72m", on ne va pas se comprendre et le protocole est rompu.

Donc ton idée de message "j'implémente le protocole tartampion" et "je ne veux parler que le protocole tartampion" n'est pas idiote, d'ailleurs tous les protocoles le font. Quelque part, le numéro de port du serveur fait aussi partie plus ou moins du protocole (il y a de forte chances que sur le port TCP 23, on y parle le protocole telnet).

Après, ces échanges sont plus ou moins complexes suivant la qualité de l'assurance que l'on veut (et aussi la richesse du protocole). Ceci dit les principaux protocoles (pop, smtp, http, ftp, ...) ont des échanges protocolaires très simples donc ne te prend pas trop la tête à inventer un protocole hyper sophistiqué.

La première réponse que font la plupart des serveur en cas de rupture de protocole est de rompre la connexion (tu ne me parles pas bien alors dégage). Une autre réponse possible est le crash (cela arrive aussi)

Il y a des outils comme nmap (www.insecure.org) qui savent reconnaitre les protocoles en les "sondant". Si tu fait tourner un serveur telnet sur le port 80, nmap va quand même reconnaitre un serveur telnet. Regarde du côté des sources pour voir comment il fait.

[nonozor]

Merci de ta réponse!

Ma question est bien "comment être sûr que je suis connecté au bon service".

Le port indique qu'on est sur le bon service quand on utilise un "well known service".
Cependant, étant donné que je code une petite application dans mon coin, je pense que je suis sensé utilisé un port supérieur à 1023, par exemple 1030. Si il y a une autre application dans le même cas que la mienne, qui choisie aussi le port 1030, on se retrouve dans l'exemple que j'ai donné dans mon premier post: un client/serveur A et un client/serveur B qui utilisent le même port, ce qui crée un quiproquo, puisque le serveur ne saura pas si c'est le client A ou le B qui se connecte et que le client ne saura pas si il se connecte au serveur A ou au B.

Est ce que je ne me trompe pas?
Si je ne me trompe pas, la solution serait donc d'utiliser un protocole simple, comme celui dont je parlais dans mon premier post?

[ram-0000]

Le port indique qu'on est sur le bon service quand on utilise un "well known service".

C'est un début d'indication. Pour info aussi, il y a des well know services > 1023 (3306 est le port de MySQL par exemple)

Cependant, étant donné que je code une petite application dans mon coin, je pense que je suis sensé utilisé un port supérieur à 1023, par exemple 1030.

Par forcémment, l'avantage des ports > 1023 est qu'il ne nécessitent pas le besoin des privilège "root" ou "admin" pour les binder.

Si il y a une autre application dans le même cas que la mienne, qui choisie aussi le port 1030

Si les 2 applications tentent de se lancer en même temps, la 2eme qui tentera de binder le socket prendra une erreur ("port already used" ou quelquechose comme cela). Il est toutefois possible de passer outre avec des options dans le bind() (mais cela ne présente guère d'intérêt dans la majorité des cas). Ce cas de figure est symptomatique d'un problème de configuration.

ce qui crée un quiproquo, puisque le serveur ne saura pas si c'est le client A ou le B qui se connecte et que le client ne saura pas si il se connecte au serveur A ou au B.

Le même genre de qui proquo qu'un client http qui se connecte sur un serveur telnet mais en général, et le client et le serveur s'en rendent rapidement compte et la connexion est fermée (ou le programme crashé)

[nonozor]

D'accord.

La meilleure solution à mon problème me semble donc imposer un protocole d'identification à mon serveur et à mon client juste après la connection: le client vérifie que le serveur est le bon en regardant si il lui envoie le message "je suis le serveur de Nonozor" et ferme la connection dans le cas contraire et le serveur fait de même (il vérifie que le client connecté est le bon en regardant si il lui envoie le message "je suis le client de Nonozor").

L'avantage est que je n'aurai pas besoin de faire du code défensif dans la suite de la connection pour vérifier que les paquets envoyés sont ceux attendus puisque le client et le serveur sont forcément les bons et qu'ils envoient donc les bons paquets, une fois qu'ils ont passé le test d'identification.

Est tu d'accord?
Connais tu une meilleure solution?
Merci d'avance.

[ram-0000]

Est tu d'accord?

Oui

Connais tu une meilleure solution?

Oui, le challenge response crypté avec secret partagé mais c'est peut être un peu lourd