Version imprimable
Bonjour, je viens vers vous pour un problème un peu spécifique:
je souhaite tester un grand nombre de lien (environ 500) https (pas de ping de windows) en même temps ou dans un intervale de temps réduit...
je n'ai jamais utilisé de socket je voudrais savoir quelles classe utiliser pour dans un premier temps tester le lien https et avoir une réponse (true/false) si le lien répond ou pas .
Dans un second temps, exécuter ces test sur 500 liens différents ?
merci beaucoup
Soit un socket http://msdn2.microsoft.com/fr-fr/lib...84(VS.80).aspx (exemple en fin de page) sur le port HTTPS
Ou sinon la classe HttpRequest http://msdn2.microsoft.com/en-us/lib...tprequest.aspx mais ça c'est plutot si tu veux interroger ton serveur HTTP
En fait, je voudrais juste intéroger mon serveur https sans échanger de données, je voudrais juste savoir si il répond...
Ben regarde l'exemple sur la msdn avec les sockets et adapte le, c'est pas très compliqué.
je vais essayer mais je débute, je vais me lancer... Comment est ce que je pourrais faire pour tester plusieurs lien en même temps ? faire du quasi temps réel ?
je cré une socket par test mais estce que je peux en ouvrir plusieurs en même temps ?
Dans la mesure ou tu veux faire un test de réponse
tu envoie une requete GET, et t'attend sagement la réponse du serveur. S'il est pa d'accord ou s'il est d'accord tu recevra une réponse
HTTP/1.1 200 OK
ou un truc dans le genre, donc tu peux très bien utiliser HttpRequest.
Si tu le fait avec les Sockets tu va devoir lire toi meme ce qui est récupéré et le parser... pas top, enfin pas compliqué non plus cela dit. et il faudra que tu gère le timeout...
Pour la concurrence des 500 tests... les threads.
Le problème c'est que si tu fait ouvrir 500 threads au système comme ca d'un coup... il va pas aimer et va prendre un peu de temps... donc utilise les threads de la pool de threads
ThreadPool a qui tu peux attribuer une tâche.
tu prend une file de nom/ip a tester et tu prend un simple objet (object) que tu instancie pour servir de monitor d'exclusion mutuelle.
dans un premier temps tu instancie la file et y met tous le noms à tester.
Puis tu lance 500 threads de pools avec tous la meme tache (meme délégué de callback).
chacun de ces threads se lock sur l'objet d'exclusion mutuel créé.
(section lock (objet) { ... })
dans ce code locké tu met l'accès à la file ou tu dépile le premier élément à tester.
ensuite en dehors du code locked (après la fin du bloc lock{}) tu fait ton test par httprequest ou socket.
a la fin tu met le resultat dans une file... ou une stack de sortie que tu va locker aussi pour éviter que tout le monde n'écrive lise en meme temps dedans ca t'évitera des déconvenues.
une fois fait, le délégué termine normallement et le thread est "libre" et retourne dans la pool a attendre une nouvelle tâche à accomplir.
avec un thread normal, le code ressemblerais à ca :
ici tu remarquera que je met une association host, bool pour les résultats histoire de savoir qui est libre et qui ne l'est pas.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
ton autre code qui essaie d'accèder à m_Result pour dépiler les éléments qui s'y trouve et les traiter doit le faire dans un
également sinon tu risque là aussi de sévères déconvenues.Code:lock(m_LockResult) { ... }
voila sur le principe c'est assez simple :)
Une connexion est très rapide, tu n'a qu'à faire un boucle et créer autant de socket que de test que tu veux faire.
Il y aurai la solution des threads, mais beaucoup trop couteux donc n'y pense pas (c'est mon avis).
Code:
2
3
4
5
6
Merci pour les infos, je vais essayer tout ca !!! j'ai un peu de boulot lol.
merci encore.
tu semble oublié un détail...
la boucle pour les socket c'est long car tu va tester tes 500 connexions l'unes après l'autres...
de plus un serveur qui est encombré, ou ne répond pas... va occupé ta lecture pendant un temps élevé... or la norme pour considéré une ligne de serveur http comme timeout c'est de l'ordre de 15 à 30s... ca fait beaucoup de temps pour les tester les unes après les autres pour peu qu'il y en est quelques unes qui lag ou ne répondent carrément pas.
Utiliser les threads de la pool est moins lourd que d'instancier lui meme les threads.
De plus il peut faire les tests par lots. je m'explique... au lieu de lancer 500 threads en meme temps, il peut simplement les lancer 10 par 10. Le nombre de threads max que la pool peut utiliser peut etre défini et auquel cas... il redonne du travail aux threads qui finissent, jusqu'a ce que la file d'entrée soit vide.
Rien de bien sorcier et plus efficace qu'une attente sur les 500 connexions... ne pas oublié en plus qu'en .NET toute connexion sur socket ou quelqu'autre Stream d'entrée sont blocantes !!! En gros si tu essaie de lire sur une socket ou ya rien à lire... et bien ton thread reste bloquer comme un con jusqu'a avoir des données à lire. Et meme la lecture asynchrone ne permet pas de totalement règler le probleme.
Les programmes qui font ces scan la plupart du temps en natif, manipulaient les attributs des sockets pour les rendres non blocantes, ce qui permettait de faire plusieurs tests simultannéments, en plus en natif il existe une commande qui permet de lancer plusieur attentes en lecture sur N sockets avec un timeout. a la fin on récupère les sockets qui ont répondues, il suffit donc de lire les données sur la ligne pour savoir si cela correspond à nos attentes... Malheureusement ils n'ont pas pensé à implanter un tel mécanisme en .NET, d'ailleurs dans aucune lib "Objet", au mieux on peut tester socket par socket au lieu de faire un test groupé plus rapide, et moins consommateur pour le systeme.
J'ai une erreur de certificat quand je teste une url de type :
https://1.1.1.1:0000
je voudrais savoir si le lien répond avec de bout de code :
Code:
2
3