Créer artificiellement une erreur de délai de connexion
Un problème de notre logiciel survient lorsque je reçois un délai de connexion. Ces erreurs sont très rares (généralement lorsque ma connexion est interrompue par notre réseau interne). Comment puis-je générer artificiellement ce type d'effet afin de tester notre logiciel?
Si cela compte, l'application est écrite en C++/MFC à l'aide de classes CAsyncSocket.
Modifier:
J'ai essayé d'utiliser un hôte inexistant et j'obtiens l'erreur de socket:
WSAEINVAL (10022) Argument non valide
Ma tentative suivante consistait à utiliser la suggestion de Alexander de connecter un autre port, 81 (sur mon propre serveur cependant). Cela a très bien fonctionné. Exactement la même chose qu'une connexion interrompue (attente de 60 secondes, puis erreur). Je vous remercie!
Connectez-vous à un hôte existant mais à un port bloqué par le pare-feu qui supprime simplement les paquets TCP SYN. Par exemple, www.google.com:81.
Connectez-vous à une adresse IP non routable, telle que 10.255.255.1.
Si vous êtes sur une machine unix, vous pouvez lancer une écoute de port à l’aide de netcat:
nc -l 8099
Ensuite, modifiez votre service pour appeler ce qu'il fait habituellement sur ce port, par exemple. http: // localhost: 8099/some/sort/of/endpoint
Ensuite, votre service ouvrira la connexion et écrira des données, mais ne recevra jamais de réponse et vous donnera donc un délai de lecture (plutôt que la connexion refusée)
L'URL suivante donne toujours un délai d'expiration et combine le meilleur des réponses de @Alexander et @ Emu ci-dessus:
L'utilisation de example.com:81 constitue une amélioration par rapport à la réponse d'Alexander, car example.com est réservé par la norme DNS. Il sera donc toujours inaccessible, contrairement à google.com:81, qui peut changer si Google en a envie. De plus, étant donné que example.com est défini comme inaccessible, vous n'inonderez pas les serveurs de Google.
Je dirais que c'est une amélioration par rapport à la réponse de @ emu car il est beaucoup plus facile de s'en souvenir.
Vous pouvez utiliser le code Python REPL pour simuler un délai d’attente lors de la réception de données (c’est-à-dire après l’établissement d’une connexion). Seule une installation standard de Python est nécessaire.
Python 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('localhost', 9000))
>>> s.listen(0)
>>> (clientsocket, address) = s.accept()
Maintenant, il attend une connexion entrante. Connectez ce que vous voulez tester à localhost:9000. Lorsque vous le ferez, Python acceptera la connexion et accept() le renverra. Sauf si vous envoyez des données via clientsocket, le socket de l'appelant doit expirer lors de la prochaine recv().
10.0.0.0, 10.255.255.255, 172.16.0.0, 172.31.255.255, 192.168.0.0, 192.168.255.255
tout cela n'est pas routable.
Je voudrais attirer l'attention de tout le monde sur pathod
Avec une configuration (tirée de leurs exemples) de 200:b@100:dr, vous obtiendrez une connexion qui sera interrompue de manière aléatoire.
Que diriez-vous d'une solution logicielle:
Installez le serveur SSH sur le serveur d'applications. Ensuite, utilisez le tunnel de socket pour créer un lien entre votre port local et le port distant du serveur d'applications. Vous pouvez utiliser les outils client ssh pour le faire. Demandez à votre application cliente de se connecter à votre port local mappé. Ensuite, vous pouvez casser le tunnel de socket à volonté pour simuler le délai de connexion.
Si vous souhaitez utiliser une connexion active, vous pouvez également utiliser http://httpbin.org/delay/# , où # est l'heure à laquelle vous voulez que le serveur attende avant d'envoyer une réponse. Tant que votre délai d'attente est plus court que le délai ... devrait simuler l'effet. Je l'ai utilisé avec succès avec le paquet de requêtes python.
Vous voudrez peut-être modifier votre demande si vous envoyez quelque chose de sensible - aucune idée de ce qu'il advient des données qui leur sont envoyées.
Il existe des services disponibles qui vous permettent de créer artificiellement des délais d'expiration Origin en appelant une API dans laquelle vous spécifiez le temps de réponse du serveur. Server Timeout sur macgyver est un exemple d'un tel service.
Par exemple, si vous souhaitez tester une demande dont le délai de réponse est de 15 secondes, il vous suffit d'envoyer une demande de publication à l'API macgyver.
Charge utile JSON:
{
"timeout_length": 15000
}
Réponse de l'API (après 15 secondes):
{
"response": "ok"
}
Programme Timeout du serveur sur macgyver
https://askmacgyver.com/explore/program/server-timeout/3U4s6g6u
Vous pouvez installer le pilote Microsoft Loopback qui créera une interface distincte pour vous. Ensuite, vous pouvez vous connecter à l'un de vos services (votre propre hôte). Ensuite, dans les connexions réseau, vous pouvez désactiver/activer une telle interface ...
La technique que j'utilise fréquemment pour simuler un délai de connexion aléatoire consiste à utiliser le transfert de port local ssh.
ssh -L 12345:realserver.com:80 localhost
Cela transférera le trafic sur localhost: 12345 vers realserver.com:80. Vous pouvez également faire une boucle dans votre ordinateur local si vous le souhaitez:
ssh -L 12345:localhost:8080 localhost
Ainsi, vous pouvez pointer votre application sur votre port localhost et personnalisé, et le trafic sera acheminé vers l'hôte cible: port. Ensuite, vous pouvez quitter ce Shell (vous devrez peut-être aussi ctrl + c le Shell après l'avoir quitté) et cela supprimera le transfert, ce qui entraînera une perte de connexion pour votre application.
Bien que le choix de l'OP ne soit pas clairement défini, il existe une différence entre tenter une connexion à un hôte/port inexistant et un délai d'attente d'une connexion déjà établie. Je voudrais aller avec Rob et attendre que la connexion fonctionne, puis tirez le câble. Ou, pour plus de commodité, demandez à une machine virtuelle de servir de serveur de test (avec un réseau ponté) et de simplement désactiver l'interface de réseau virtuel une fois la connexion établie.
J'ai eu des problèmes dans le même sens que vous. Afin de tester le comportement du logiciel, je viens de débrancher le câble réseau au moment opportun. Je devais définir un point d'arrêt juste avant de vouloir débrancher le câble.
Si je le faisais encore, je mettrais un commutateur (un bouton-poussoir momentané normalement fermé) dans un câble réseau.
Si la déconnexion physique entraîne un comportement différent, vous pouvez connecter votre ordinateur à un concentrateur bon marché et placer le commutateur susmentionné entre votre concentrateur et le réseau principal.
- EDIT -- Dans de nombreux cas, vous aurez besoin de la connexion réseau jusqu'à ce que vous atteigniez un certain point de votre programme. ALORS, vous voudrez vous déconnecter en utilisant l'une des nombreuses suggestions proposées.
Le plus simple serait de laisser tomber votre connexion en utilisant CurrPorts .
Cependant, afin de tester votre code de gestion des exceptions, vous devriez peut-être envisager de résumer votre code de connexion réseau et d'écrire un stub, un simulacre ou un décorateur qui lève des exceptions à la demande. Vous pourrez alors tester la logique de traitement des erreurs de l'application sans avoir à utiliser réellement le réseau.
Beaucoup de bonnes réponses mais la solution la plus propre semble être ce service
http://httpstat.us/504?sleep=60000
Vous pouvez configurer la durée du délai d'attente (jusqu'à 230 secondes) et le code de retour éventuel.
Pour moi, le moyen le plus simple consistait à ajouter un itinéraire statique sur un routeur de bureau en fonction du réseau de destination. Il suffit de diriger le trafic vers un hôte qui ne répond pas (par exemple, votre ordinateur) et vous obtiendrez un délai de requête expiré.
La meilleure chose pour moi était que les routes statiques puissent être gérées via une interface Web et activées/désactivées facilement.
Branchez votre câble réseau sur un commutateur sans autre connexion/câble. Cela devrait marcher à mon humble avis.
J'ai déjà eu recours à diverses tactiques pour simuler des problèmes de réseau.
- Tirez sur le câble réseau
- Eteignez l'interrupteur (idéalement avec l'interrupteur auquel l'ordinateur est branché, toujours sous tension afin que la machine conserve sa "connexion réseau") entre votre machine et la "cible".
- Exécuter un logiciel de pare-feu sur la machine cible qui supprime silencieusement les données reçues
Une de ces idées pourrait vous donner un moyen de générer artificiellement le scénario dont vous avez besoin
En fonction du logiciel de pare-feu que vous avez installé/disponible, vous devriez pouvoir bloquer le port sortant et, en fonction de la configuration de votre pare-feu, il convient de supprimer le paquet de demande de connexion. Aucune demande de connexion, aucune connexion, un délai d'attente s'ensuit. Cela fonctionnerait probablement mieux s'il était implémenté au niveau du routeur (ils ont tendance à supprimer les paquets au lieu d'envoyer des réinitialisations, ou l'équivalent), mais il y a forcément un logiciel qui ferait l'affaire aussi.