GetActiveTcpListeners() => ArgumentOutOfRangeException

Bonjour à tous,

Un petit problème se pose.
Lorsque j'appelle la méthode GetActiveTcpListeners() de la classe IPGlobalProperties, je me prends un ArgumentOutOfRangeException.
En ayant un peu recherché, il s'agirait d'une exception lancée par le framework lors de la construction des IPEndPoint, et plus particulièrement de l'assignation de sa propriété Port.
En effet la classe IPEndPoint possède deux constantes définissant les limites des ports autorisés : MinPort et MaxPort. Il suffirait alors qu'il existe une connexion TCP utilisant un port n'étant pas dans la plage autorisée, et l'exception serait lancé.

Ma question est donc quel est le moyen pour récupérer la liste des ports utilisés sur une machine sans passer par une instanciation d'IPEndPoint.

Merci d'avance :ccool:

IPGlobalProperties est une classe abstraite donc je pense que tu auras du mal à utiliser l'une de ses méthodes. Pourrais-tu vérifier et nous dire quelle classe dérivée de IPGlobalProperties tu utilises?

J'utilise ce bout de code :

Code:

---

1 2 3

IPGlobalProperties ipProperties = IPGlobalProperties.GetIPGlobalProperties(); IPEndPoint[] activeTcpListeners = ipProperties.GetActiveTcpListeners();

---

OK, donc tu utilises SystemIPGlobalProperties comme classe réelle (qui elle implémente IPGlobalProperties).

Effectivement, lors de la création d'un IPEndPoint, le framework va vérifier le port est bien supérieur ou égale à 0 et inférieur ou égale à 65535.

Par contre, en examinant le code, il est difficile de te donner une explication de pourquoi un port invalide est passé. Il serait intéressant d'activer le débugging du framework et le téléchargement de son code source afin de mettre un point d'arrêt dans la classe SystemIPGlobalProperties, méthode GetAllTcpConnections(), sur les lignes:

Code:

---

list.Add(new SystemTcpConnectionInformation(row));

---

et

Code:

---

list.Add(new SystemTcpConnectionInformation(pid2));

---

et d'inspecter le contenu de row et pid2.

Je ne peux pas t'aider plus que cela.

OK Merci ;)

Le soucis, est que je ne peux pas faire de debugging, car l'erreur se produit seulement lorsque mon application est déployée sur un serveur(CITRIX) sur lequel je n'ai pas accès, donc je fais de la correction à l'aveuglette.. Pour moi il doit y avoir un listerner TCP sur ce serveur, utilisant un port n'étant pas dans l'intervalle [0-65535]..

Ce qui est impossible vu que les ports en TCP/IP ne peuvent excéder 65535.

Je pense plutôt que le framework récupére une information qu'il l'exploite mal, dans la méthode que j'ai observée, y'a un tas d'appel externe au framework (API windows), et il se peut qu'un paramètre soit mal formaté.

Peux tu vérifier tes résultats avec un outil comme TCPView (Sysinternals)?

Chez moi, ce petit bout de code fonctionne à merveille:

Code:

---

1 2 3 4

foreach (var ep in IPGlobalProperties.GetIPGlobalProperties().GetActiveTcpListeners()) { Console.WriteLine(ep); }

---

Résultat:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

0.0.0.0:1026 0.0.0.0:1027 0.0.0.0:1028 0.0.0.0:1029 0.0.0.0:47001 127.0.0.1:1434 127.0.0.1:5354 127.0.0.1:14452 127.0.0.1:14769 127.0.0.1:47873 127.0.0.1:64295 192.168.61.6:139

---

ok.. donc là il y a effectivement un problème :koi:

Oups... répondu trop vite..
Le problème est que je n'ai pas la main sur le serveur où se déclenche l'erreur. Or quand j'execute le code en local, je n'ai également aucun soucis..

Il va falloir nous en dire plus sur ce serveur, ce qui tourne comme application dessus, et surtout quel est le but de ton développement!

Là est la question, comme j'ai dis je n'ai pas la main sur ce serveur, ce n'est pas mon équipe qui gére ce qui tourne dessus, et l'application a pour finalité d'être déployée nationalement (voir plus..) sur différent serveur suivant la région, et donc avec des choses différentes dessus suivant les cas.
Cette erreur se déclenche aléatoirement : un jour sur un serveur ça peut être OK, et le lendemain non..
Ca va être difficile pour moi de te donner plus d'éléments, et je comprends bien que ca va être compliqué de m'aider.

Donc il faudrait que je trouve un moyen de contournement me permettant de vérifier si un port est utilisé ou non sans passer par l'instanciation d'un IPEndPoint.

Essaie de recoder un bout de ton application pour obtenir une stacktrace bien documentée lorsque cela plante, ainsi on pourra plus facilement mettre le doigt sur le problème.

Sinon, il te faudra toi même récupérer les informations sur les ports en attaquant directement l'API windows.

Quoi que, la méthode bête et méchante serait te faire une boucle de 0 à 65535 et de faire un tcp connect sur chaque port pour vérifier sa disponibilité. Mais c'est très moche, ne dis à personne que c'est moi qui ai écrit cela ;-)

Après, une solution intermédiaire serait d'utiliser:

Code:

---

netstat -an |find /i "listening"

---

en ligne de commande et de parser le résultat, c'est un peu moins moche, sans être fabuleux...

Après quelques recherches, il s'agirait d'un bug du framework 3.5, corrigé en 4.0:
http://connect.microsoft.com/VisualS...nections-error

Donc pour outre-passer ce problème, on a finalement éclater le code du framework pour récupérer l'implémentation des méthodes et des classes qui nous intéressées et les réécrire à notre façon en custom, et donc ne pas passer par la vérification de l'intervalle [MinPort, MaxPort].

En tout cas merci pour ton aide Neptune :ccool:

Ce fût un plaisir de trouver une question intéressante dans le flot de question, disons, moyennement intéressantes ;-)

Passer au framework 4.0 n'est pas une option envisageable?

Et non, ça fait parti des contraintes d'un projet client ;)