Discussion :

[ced600]

Je voudrais que mon application ne fasse rien jusqu'à temps qu'un port TCP précis soit libéré.
voici le code que j'ai utilisé :

Code :

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

1
2
3
4
5
6
7
System.Net.IPEndPoint t = new IPEndPoint(System.Net.Dns.Resolve(Dns.GetHostName()).AddressList[0], 5070);
Socket g = new Socket(t.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
g.Bind(t);
while(g.Connected)
{
	System.Threading.Thread.Sleep(5000);
}

Le port en question est ouvert par une autre application (je n'ai pas le code de cette application en question).

J'ai fait des recherche à l'aide de et je suis désespéré de voir que très peut de page traite du sujet (alors qu'il y en a tout plein pour les autres langages) à croire qu'en c# on ouvre pas les ports sois même .

Sur le forum c# je n'ai pas trouvé grand chose à l'aide de la recherche .

L'équivalent d'un netstat devrait me suffir, d'ailleurs demain je vais voir si je peut récupérer la valeur retour d'un netstat, et dans ce cas je passerais par cela .

[StormimOn]

Pour récupérer les ports utilisés (en écoute ou connectés), tu auras tout ce qu'il te faut ici avec les méthodes GetActive....

[ced600]

Merci pour ton aide, mais j'ai oublié de préciser que je suis en .Net 1.1 et je n'ai pas le namespace System.Net.NetWorkInformation ce qui est bien dommage .

Actuellement je suis en train de lire ce tutorial et j'essaye d'obtenir ce que je veux en passant par la méthode pool.
Mais cela ne fonctionne toujours pas .
Bon je pense que mon code n'est pas encore bon, je suis en train de voir pourquoi.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
System.Net.IPEndPoint t = new IPEndPoint(System.Net.Dns.Resolve(Dns.GetHostName()).AddressList[0], 5070);
Socket g = new Socket(t.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
bool free = false;
while(!free)
{
	if (g.Poll(10,SelectMode.SelectRead) && g.Available == 0)
		free = true;
	else
		free = false;
	System.Threading.Thread.Sleep(5000);
}

[ced600]

Bon une avancée :

Code :

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

g.Poll(10,SelectMode.SelectRead)

me renvois toujours false même lorsque le port est libéré (observation avec netstat).

Code :

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

g.Available

me renvois toujours 0 mais vu ma condition ce n'est pas génant.

Je ne sais pas si je suis partis sur la bonne voix : Utiliser une socket pour me connecter à un port qui est déjà occupé pour savoir quand il ne le sera plus.

J'ai vu que je peut aussi utiliser bind qui me renvois une exception si le port est utilisé par un autre, mais je preférerais éviter de gérer cette détection par une exception.

[tomlev]

j'ai oublié de préciser que je suis en .Net 1.1 et je n'ai pas le namespace System.Net.NetWorkInformation

Tu as une raison particulière de rester en 1.1 ? Cette version est carrément obsolète, on en est quand-même à la 3.5 (beta)...

[cinemania]

Il y a plus simple pour tester si le port est libre sans utiliser dotnet2
c'est pas propre mais ca marche.

Quand tu créé une socket et la bind sur un port, a ce moment elle est juste initialisée et créée par le système mais en aucun cas, celle-ci n'a encore d'insidence sur la pile TCP/IP.

Si tu essaie d'écouter un port "occupé, en activant la socket en mode écoute... elle va directement quitter en t'expliquant son mécontentement...
Selon les méthodes par une exception ou un résultat. Tu traite ce résultat, ou si c'est une exception tu l'attrape avec un try catch...
certes le mécanisme des exceptions est lent, mais dans ton cas, je crois qu'on s'en tappe un peu, si je puis m'exprimer ainsi.

Si le résultat est une exception où le fait que le port soit pas dispo... tu as gagné tu attend et refait l'opération, sinon tu passe à la suite.
Attention toutefois avec le caractère blocant des sockets sous dotnet. Je ne sais plus si la mise en écoute bloque l'appelant en dotnet, normallement non, si le modele de fonctionnement de sockets, en temps normal, a été préservé.

Sinon je suis d'avis comme les autres que tu change enfin de technologie... dotnet 1.1 est plus qu'obsolete de nos jours, déjà meme dotnet 2.0 est obsolète si l'on veut bien (si on fait abstraction du fait que le 3 soit la meme chose que le 2 plus des ajouts par ci par la).

Je ne saurais trop te conseiller un passage à dotnet 3.0. Après tout si tu n'utilise pas les namespace spécifiques à dotnet 3... il est possible (sous certaines contraintes) de faire fonctionner les appli ainsi générée avec dotnet2.

Il n'est pas fondamentallement nécessaire de passer à dotnet 3.5... surtout que le mieux pour cela, serait de passer à Orcas sous vista (VS2008).

[ced600]

Oui.
Dans l'entreprise où je travaille, tous les postes sont restés en framework 1.1
Passé ne serait qu'au 2.0 m'obligerais à rajouter à mon installeur l'update du framework.
Donc je passerais d'un installeur de taille < à 1000 KO à un installeur de taille > à 60 MO.
Cela poserais pas mal de difficulté d'avoir un installeur de cette taille et en dehors du problème que j'ai actuellement, je n'avais pas besoin des nouvelles fonctionnalités, présentent à partir du 2.0, pour mon outil.
En plus de cela, mon outil est installé sur une plateforme de pré-production sensible et que je ne maitrise pas (dans le sens où c'est pas moi qui m'occupe de la plateforme et qui installe mon outil, je ne fait que livrer), donc rajouter une installation supplémentaire, même si elle n'est sensé posé aucun problème (jamais vu planté l'update du framework), c'est rajouté un risque potentielle d'erreur.

[ced600]

Quand tu créé une socket et la bind sur un port, a ce moment elle est juste initialisée et créée par le système mais en aucun cas, celle-ci n'a encore d'insidence sur la pile TCP/IP.

Si tu essaie d'écouter un port "occupé, en activant la socket en mode écoute... elle va directement quitter en t'expliquant son mécontentement...
Selon les méthodes par une exception ou un résultat. Tu traite ce résultat, ou si c'est une exception tu l'attrape avec un try catch...
certes le mécanisme des exceptions est lent, mais dans ton cas, je crois qu'on s'en tappe un peu, si je puis m'exprimer ainsi.

Ouais j'ai vu cela hier soit, mais cela me géne de passer par les exception (bind envois une exception en cas d'occupation du port d'apès le tutorial que j'ai regardé.).
Enfin si je ne peut faire autrement j'utiliserais cette solution. Je n'ai rien contre les exceptions mais je me dit qu'utilisais les exceptions pour faire un simple test c'est un peu dommage .
Je vais quand même regardais ce que je peut faire avec netstat.

Je ne sais plus si la mise en écoute bloque l'appelant en dotnet, normallement non, si le modele de fonctionnement de sockets, en temps normal, a été préservé.

C'est pas trop grave dans mon cas. Je vérifie que le port est libre après le plantage d'une autre application qui lance un sous process java, qui ouvre ce fameux port et qui met du temps à le libérer en cas de plantage de l'application qui l'a lancé. (Peut être pas très claire )

Sinon je suis d'avis comme les autres que tu change enfin de technologie... dotnet 1.1 est plus qu'obsolete de nos jours, déjà meme dotnet 2.0 est obsolète si l'on veut bien (si on fait abstraction du fait que le 3 soit la meme chose que le 2 plus des ajouts par ci par la).

Je ne saurais trop te conseiller un passage à dotnet 3.0. Après tout si tu n'utilise pas les namespace spécifiques à dotnet 3... il est possible (sous certaines contraintes) de faire fonctionner les appli ainsi générée avec dotnet2.

Il n'est pas fondamentallement nécessaire de passer à dotnet 3.5... surtout que le mieux pour cela, serait de passer à Orcas sous vista (VS2008).

Je répondais à cela pendant que tu ecrivais ton message .

[cinemania]

Le package redistribuable de dotnet2 fait 26mo... pas 50 passé du moins sous sa forme packagée (c'est sure une fois installé ca dépasse les 50mo...).
c'est le package redistribuable de dotnet3 qui fait plus de 50mo.

Cependant si tu compile avec dotnet3, il y a toujours moyen d'inclure seulement l'updater "distant" qui fait moins d'1mo, il se chargera d'aller chercher le redist sur le site de microsoft au moment de l'install.

[ced600]

[QUOTE]Le package redistribuable de dotnet2 fait 26mo... pas 50 passé du moins sous sa forme packagée (c'est sure une fois installé ca dépasse les 50mo...).
c'est le package redistribuable de dotnet3 qui fait plus de 50mo.
[QUOTE]
Excuse pour les 60 Mo mais 26 Mo c'est toujours trop gros

Cependant si tu compile avec dotnet3, il y a toujours moyen d'inclure seulement l'updater "distant" qui fait moins d'1mo, il se chargera d'aller chercher le redist sur le site de microsoft au moment de l'install.[/

Nop pas possible à cause de la compléxité du réseau.

Merci quand même masi si je passe en 2.0 ou 3.0 faut que j'embarque l'updater et .... On revient à ce que j'ai expliqué plus haut.

Je suis en train de regarder en ce qui concerne netstat avec redirection de la sortie dans un stream et l'analyse de ce stream.

[ced600]

Bon au final je suis passé par l'utilisation de netstat.
Je lance la commande avec l'option -a grâce à l'objet Process et je redirige la sortis dans un streamreader.
Je récupère le contenu du stream en string et là il n'y a plus qu'à analyser le string pour vérifier si le port est présent.
Le tout dans une boucle avec un sleep d'une seconde à chaque tour de boucle pour éviter de consomer trop de ressources.

Voila cela marche très bien, cela ne prends pas beaucoup de ressources et cela me suffit, donc je vais fermer la discussion.
Merci de votre aide.

PS: si quelqu'un veut le code qu'il me le demande je le posterais.