Discussion :

[Kuroneos]

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.

[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.

[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 :-/

[Narwe]

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.

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 ?

[Kuroneos]

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)

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

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 :

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

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")

[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 .