pb de connexion entre client et serveur

Question

Bonjour

J'essaie de m'initier à la programmation réseau et j'ai récupéré sur le Net quelques sources.

Je voudrais en tester un, mais je n'arrive pas à établir la connection entre 2 postes : je récupère l'erreur suivante :

"Aucune connexion n'a pus être établie car l'ordinateur cible l'a expressément refusée"

Voici un bout du source que j'utilise :


COTE SERVEUR
************

Public Class cServeur

    Private oEcoute As TcpListener = Nothing

    'Service d'écoute
    '****************

    Public Sub subEcoute()

        'MsgBox("Début du service")

        Try

            'Création du service
            'oEcoute New TcpListener(IPAddress.Parse("127.0.0.1"), My.Settings.Port_local)
            MsgBox("service crée")

            'Lancement
            '=========
            oEcoute.Start()
            MsgBox("service lancée")

            'Suivi
            '=====
            MsgBox("Serveur d'echo lancé sur le port " & My.Settings.Port_local)
            MsgBox(oEcoute.LocalEndpoint.ToString)


            'Boucle de service
            'Dim oClient As TcpClient Nothing
            Do

                oClient = oEcoute.AcceptTcpClient
                MsgBox("client accepté")

                .....

COTE CLIENT
***********
        Dim oClient As TcpClient = Nothing 

        Try
            'Connexion au service
            'oClient New TcpClient(My.Settings.Serveur_distant, My.Settings.Port_distant)
            MsgBox("connexion reussie")

...


Est-ce que quelqu'un a déjà eu ce problème ?
(Le port utilisé est ouvert sur le pare-feu)


jocou

lunnorey · Accepted Answer

Bonjour,
au moment de créer votre TcpListener ou votre IPEndPoint, n'utilisez pas IPAddress.Parse("127.0.0.1") mais IPAddress.Any.

Mayzz · Answer

"Aucune connexion n'a pus être établie car l'ordinateur cible l'a expressément refusée"

Ca signifie bien que le port est bloqué par un parefeu.

As-tu la même adresse IP pour le client/serveur ? Je vois que tu utilise un paramètre d'application, quelle adresse contient-il ?

Utilises-tu un réseau ou tu tente la connexion depuis la même machine ?

Conseil : Pour moi TcpClient/TcpListener => à bannir, si tu souhaites vraiment communiquer via le réseau, utilise directement les sockets. voici une très bonne source : http://www.vbfrance.com/codes/SOCKET-CLASS-SOCKET-AVEC-EVENEMENTS-MULTI-CONNEXION-CROSS_36083.aspx

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jocou · Answer

Salut
En fait, je teste sur un réseau local et j'utilise des paramètres utilisateurs pour connaitre le nom du poste distant : le client a le nom du serveur et le serveur le nom du client ...

J'ai bien vu sur le Net qu'il existait 2 méthodes (tcp ou socket) : ne sachant pas laquelle choisir, j'ai pris celle qui me paraissait la plus simple

Quelles sont les différences entre les 2 ?

jocou

Mayzz · Answer

Ah ! Donc si je comprends bien dans le client tu entre le nom du poste cible ?

Voila pourquoi cela ne fonctionne pas. Pour la connexion le protocole TCP utilise le protocole IP (en fait c'est une couche supérieure). Donc pour la communication TCP identifie les postes par leur adresse IP et non par leur nom réseau.

Au pire des cas, tu peux spécifier un nom de domaine comme vbfrance.com si celui-ci est inscrit chez un registar uniquement, car le TCPListeneur enverra alors une requête DNS permettant de résoudre l'adresse IP associée à ce nom de domaine. 
Mais ne pas confondre un nom d'ordinateur local avec un nom de domaine ce sont deux choses tout à fait différentes. 

Donc il ne te reste qu'à saisir sur ton client l'adresse 127.0.0.1 pour établir la connexion.

Attention cette adresse ne fonctionne que si le serveur et le client se trouvent sur le même poste. Dans le cas contraire il faut utiliser les IP des interfaces réseaux qui relient les machines.


Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jocou · Answer

Non, l'erreur ne vient pas de là, les méthodes utilisées (tcpClient et tcpListener) font bien la résolution de nom.

J'en suis sûr car dans le message d'erreur, je n'ai plus le nom de l'hôte mais bien son adresse IP :

l'hôte de connexion n'a pas répondu 10.43.241.35:222


jocou

Mayzz · Answer

Heu... Attend je comprends plus trop, ce message d'erreur est différent de celui posté plus haut ? Qu'as-tu changé entre temps ?

Sinon niveau pare-feu, t'as ouvert le port sur ton routeur et aussi sur la machine cible ?

L'adrese IP est de classe A plutôt rare pour un réseau local à moins que tu ne soit dans un résau d'entreprise dans ce cas il est possible qu'il y ai plusieurs pare-feu, passerelles et routeurs.

Aussi il est recommandé d'utiliser des ports sup. à 49152 pour les programmes perso.

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jocou · Answer

Non, je n'ai rien changé, le message est toujours le même, mais effectivement je ne l'affiche pas en entier dans les différents mails

Le message d'erreur exaustif est le suivant :

"Aucune connexion n'a pus être établie car l'ordinateur cible l'a expressément refusée 10.43.241.5:22222" 

Je teste effectivement dans ma boîte, et il se peut que des pare-feux sur des routeurs empêchent la communication

En tout cas, je vais essayer avec le port 49153



jocou

Mayzz · Answer

Oui si tu es dans une boite qui à un réseau avec des adresse de classe A j'imagine que celui-ci n'est pas petit, mais ca il n'y a que toi pour le confirmer.

Autre chose, comme je te l'ai dis l'adresse 127.0.0.1 est une adresse spécifique. Si tu veux que ton serveur (démon) se mette sur écoute utilise l'adresse de sont interface le reliant au réseau soit 10.43.241.5.

Ou alors pour vérifier en local, met le programme serveur et le programme client sur le même poste et utilise l'adresse 127.0.0.1 pour les deux ce qui simulera un comportement réseau.

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jocou · Answer

J'ai essayé en modifiant le no de port (49153) mais c'est pareil

J'ai récupéré WireShark pour tracer la communication et la lecture de la trace me laisse dibutatif :

Source_______Destination__Protocol_Info
10.43.241.35_10.43.241.5__TCP______2587 > 49153 ...
10.43.241.5__10.43.241.35_TCP______49153 > 2587 ...
10.43.241.35_10.43.241.5 _TCP______2587 > 49153 ...
10.43.241.5__10.43.241.35_TCP______49153 > 2587 ...

Je ne comprends pas ce qui se passe :
Dans mon programme, les 2 ports client et serveur sont initialisés à 49153
Quand le client contacte le serveur, la trace semble montrer que le port source a été transformé de 49153 à 2587 ???

Comment expliquer celà ?

jocou

Mayzz · Answer

Non pas du tout.

En fait lors ce que tu initialise une connexion TCP cliente vers l'adresse et le port d'un serveur, il faut bien que ce client communique aussi via un port ? 

Et ce port client ne peut être le même que celui appelé pour la connexion car ce qui voudrait dire que lors ce que tu ouvres une page web pour aller sur internet (et que tu te connect au port 80 du serveur) le port 80 de ton interface réseau serait lui aussi utilisé. Du coup celui qui installerait un serveur web comme apache ou ISS ne pourrait plus naviguer sur le net. 

Alors pour palier à cela le socket client se sert d'un port aléatoire inutilisé.

Pour ton problème. Wireshark ne dis rien. Déjà on ne peu pas deviner étant donnée le peu d'infos affichés.

As-tu essayé comme je te l'ai dis en local ?

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jocou · Answer

Je viens d'essayer en local et là effectivement ça marche

Un équipement quelconque du réseau doit donc bloquer la communication

jocou

bouchraoui · Answer

à Mon avis le port est occupé par un Parfeu ou skype

Mayzz · Answer

Oui si t'es en entreprise il est probable qu'il y ai un ou plusieurs parefeu ce n'est pas la solution idéale pour tester ton programme. Je te conseille de le développer en local dans un premier temps et de demander à ton administrateur réseau de débloquer le port lors ce que tu souhaiteras utiliser le logiciel au boulot.


Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jocou · Answer

J'ai testé en local, ça marche.
Il ne reste plus qu'à faire débloquer le port

Merci pour votre aide

jocou

Pb de connexion entre client et serveur

14 réponses

Votre réponse

Discussions similaires