Définir/déterminer le numéro de port source d'un message TCP

Version imprimable

13/02/2015, 13h12
Kuroneos

Définir/déterminer le numéro de port source d'un message TCP

Bonjour,

Je suis développeur WinDev depuis moins d'un an et je rencontre "un problème" dans la gestion des sockets.

[SITUATION]
Je développe actuellement une application qui doit communiquer en TCP avec une autre (qui n'a pas été développée avec WinDev) dans un même réseau local selon le schéma suivant:

(Application 1 : Port source ) >>>> Message >>>> (Port destination : Application 2)
(Application 1 : Port source ) <<<< Réponse <<<< (Port destination : Application 2)

Comme indiqué ci-dessus, l'application 2 répond au message de l'application 1 sur le port duquel est parti le message.

[PROBLEME]
N'ayant pas accès aux sources de l'application 2, il m'est impossible de paramétrer sur quel port celle-ci peut répondre aux messages qui lui parviennent. Dès lors, est-il possible dans WinDev de paramétrer (ou même de savoir à l'avance) à partir de quel port un message TCP quitte l'application 1?

Merci pour vos réponses et éventuelles suggestions.

PS: J'ai déjà contacté plusieurs supports techniques sans succès, j'espère trouver la solution grâce à vous.
13/02/2015, 13h46
Narwe

La fonction SocketCree de Windev impose de définir un port (http://doc.pcsoft.fr/fr-FR/?3070011).

Je pense que vous avez déjà pris en compte ce paramètre.

Maintenant, s'il y a communication entre les 2 applications, de mes connaissances en communication réseau, je dirais que les 2 communication doivent être liés par une socket.
Une application est serveur (elle fait le SocketCréé et attend une connexion (SocketAttendConnexion : http://doc.pcsoft.fr/fr-FR/?3070006&...ttendConnexion).
L'autre application se connecte à ce serveur (SocketConnecte http://doc.pcsoft.fr/fr-FR/?3070016&name=SocketConnecte) avec l'IP du serveur et le numéro de port.
Les 2 applications doivent donc travailler sur le même port qui doit pouvoir être paramétré dans les applications (même FileZila permet de paramétrer le port).

Après pour déterminer le port sur lequel l'application doit ouvrir le port, ça me paraît délicat (voir impossible).
Sans doute en faisant un scan des port ouvert (technique de hackage, si je ne me trompe pas), il doit être possible de déterminer les ports possible.

Désolé, si j'ai répondu complétement à coté de la question.
13/02/2015, 13h54
Kuroneos

Le fait est que l'application 2 (le serveur dont le numéro de port d'écoute est bien spécifié) répond automatiquement sur le même port d'où lui provient un message.

J'ai utilisé Wireshark pour m'en assurer. Le port de départ (de l'application 1 donc) est totalement aléatoire tandis que le port de destination (sur l'application 2 donc) est bien défini d'une part dans l'application 2 elle-même (c'est un paramètre) et d'autre part dans la fonction "SocketConnecte".

Le gros problème c'est que cette application 2 répond sur le port de départ de l'application 1 qui ne pourrait être mis en écoute que si j'en avais connaissance à l'avance (ou que je puisse récupérer cette information en cours de traitement avant que l'application 2 ne renvoie sa réponse).

Tout me porte à croire que ma demande semble impossible :-/
13/02/2015, 14h06
Narwe

Citation:

Envoyé par Kuroneos

Le port de départ (de l'application 1 donc) est totalement aléatoire

A ce que j'ai compris dans votre premier message, c'est vous qui réalisez cette application 1. Si c'est bien cela, je ne comprend pas que le port de départ soit aléatoire.

Citation:

Envoyé par Kuroneos

cette application 2 répond sur le port de départ de l'application

Si l'application à fait un "SocketConnecte" pour faire son "SocketLit" et qu'elle ne s'en est pas déconnecté, elle renverrait sa réponse en faisant un "SocketEcrit", sans précisé le port (le port n'est utile que pour la connexion, il ne peut pas être modifié après).

Peut-être qu'un bout de code permettrait de mieux comprendre ce que vous souhaitez faire et où se trouve votre problème ?

Citation:

Envoyé par Narwe

A ce que j'ai compris dans votre premier message, c'est vous qui réalisez cette application 1. Si c'est bien cela, je ne comprend pas que le port de départ soit aléatoire.

Oui je m'occupe de l'application 1 et l'application 2 est le serveur (dont je ne peux spécifier que le port d'écoute)

Citation:

Envoyé par Narwe

Si l'application à fait un "SocketConnecte" pour faire son "SocketLit" et qu'elle ne s'en est pas déconnecté, elle renverrait sa réponse en faisant un "SocketEcrit", sans précisé le port (le port n'est utile que pour la connexion, il ne peut pas être modifié après).

- L'application 1 fait un "SocketConnecte pour se connecter au port d'écoute du serveur (application 2)
- L'application 1 envoie son message sur ce port d'écoute à partir d'un port aléatoire ouvert (cfr Wireshark)
- Le serveur (application 2) interprète correctement ce message et envoie la réponse sur le port d'où lui vient ce message (aléatoire lors de l'envoi du message de l'application 1)
- L'application 1 ne reçoit jamais la réponse car le port sur le lequel l'application 2 lui envoie sa réponse n'est pas mis en écoute

Citation:

Envoyé par Narwe

Peut-être qu'un bout de code permettrait de mieux comprendre ce que vous souhaitez faire et où se trouve votre problème ?

Voilà mon code initial, avant de comprendre que le serveur (192.168.0.108) répondait sur un autre port que le port spécifié (9876) dans "SocketConnecte"
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 SAI_Connexion = SocketConnecte("Serveur",9876,"192.168.0.108") SI COMBO_Messages..ValeurAffichée <> "" ALORS nXML est entier = fOuvre(fRepExe() + "\" + COMBO_Messages..ValeurAffichée) sLigne est une chaîne sMessage est une chaîne SI nXML <> -1 ALORS TANTQUE sLigne <> EOT sMessage = sMessage + sLigne sLigne = fLitLigne(nXML) FIN FIN SAI_Quest = sMessage SocketEcrit("Serveur",sMessage) SAI_Rep = SocketLit("Serveur",Faux) FIN SocketFerme("Serveur")

13/02/2015, 16h21
Narwe

L'attitude est surprenante.
Le client (l'application 1) envoie une demande au serveur (penser à vérifier le résultat de SocketEcrit !) et le serveur répondrait sur une autre socket !

Pour tester, j'essayerais de mettre un attente plus longue sur SocketLit (ou même infini en test en passant en le 2e paramètre à Vrai).
J'essayerais aussi le SocketLit avec la même attente mais en attendant 1 seul octet (affiché dans une fenêtre trace).
Je ferais des essai en changeant le mode de transmission avec la SocketChangeModeTransmission.

Pour finir, je me plaindrais auprès du développeur de ce serveur ;).
16/02/2015, 08h51
Kuroneos

Citation:

Envoyé par Narwe

Le client (l'application 1) envoie une demande au serveur (penser à vérifier le résultat de SocketEcrit !) et le serveur répondrait sur une autre socket !

L'information du client parvient bien au serveur (je le vois via des logs en temps réel). C'est grâce à Wireshark que j'ai pu déterminer où répond le serveur, il ne répond pas vraiment "sur un autre socket", il répond juste sur le port source d'où provient le message.

Citation:

Envoyé par Narwe

Pour tester, j'essayerais de mettre un attente plus longue sur SocketLit (ou même infini en test en passant en le 2e paramètre à Vrai).
J'essayerais aussi le SocketLit avec la même attente mais en attendant 1 seul octet (affiché dans une fenêtre trace).
Je ferais des essai en changeant le mode de transmission avec la SocketChangeModeTransmission.

Je ne pense pas que le temps d'attente du SocketLit ait un impact sur mon problème. En effet, dans les logs du serveur, on voit clairement qu'il répond au message du client. Cependant, vu qu'il répond sur le port source du client (qui n'est pas en écoute vu que je n'ai aucun moyen de déterminer par quel port source va partir le message), le serveur renvoie "winsock error 10053" (ce qui est normal vu que le port n'est pas ouvert).

Citation:

Envoyé par Narwe

Pour finir, je me plaindrais auprès du développeur de ce serveur ;).

Grand dieu .... j'aurais tellement de remarques négatives sur la conception de ce programme que je pourrais limite en écrire une thèse ....

Ce qui serait bien c'est d'avoir l'équivalent de la fonction SocketClientInfo mais qui renverrait les informations du SocketEcrit (par exemple)
17/02/2015, 15h22
Kuroneos

Bon ben je suis arrivé à déterminer mon port de départ.

J'ai tout simplement créé un ".bat" faisant un netstat sur le port de destination (le seul port connu).

Après quelques manipulations de chaines, j'ai pu ouvrir un port en écoute qui est le même que le port source du message TCP. Mon seul problème maintenant c'est d'arriver à capter les réponses du serveur.