L’information TRCINT présentée dans cet article donne une bonne vue interne de toute application réseau tournant sur votre système. Avec TRCINT, vous pouvez examiner les API sockets que l’application utilise lors de l’envoi et de la réception de données sur le réseau. Voyons deux scénarios utilisant la couche d’interface sockets
Quand faut-il utiliser TRCINT ?
pour déboguer des problèmes de réseau.
Scénario n° 1 : Vous constatez qu’une application requête/réponse semble s’immobiliser en attendant une réponse du système distant ; pourtant, vous pouvez atteindre ce dernier par un ping. Avec les outils couverts dans les articles précédents de cette série, vous êtes capables de collecter une trace de communications i5/OS du problème, puis de l’analyser de deux façons. Premièrement, si la requête de l’application n’apparaît pas dans la trace de communications, vous devez déterminer si la requête est envoyée à la pile TCP/IP. Capturez une trace des API sockets que cette application est en train d’appeler, pour déterminer rapidement si l’application appelle les API send() ou write(). Deuxièmement, après avoir examiné la trace de communications, vous pourriez déterminer que la requête de l’application est envoyée sur le réseau et que la réponse du système distant est reçue. Si l’application semble encore figée, capturez une trace des API sockets appelées par l’application et déterminez si les API recv() ou read() sont utilisées pour recevoir la réponse du système distant.
Scénario n° 2 : Une application est défaillante, mais les messages de diagnostic et les moyens de trace qu’elle fournit, ne permettent pas de cerner le problème. Peut-être que l’application ne vérifie pas les codes de renvoi sur chaque appel d’API socket, ou peut-être qu’elle n’affiche pas ou ne transfère pas la valeur errno quand une erreur est détectée. Collecter une trace interne sur les API sockets utilisées par l’application est le seul moyen de déterminer quelles API sockets sont défaillantes et la valeur errno réelle qui est renvoyée, sans mettre à jour et recompiler l’application. Dans les deux scénarios qui précèdent, de bonnes fonctions de diagnostic et de trace au niveau application réduisent la nécessité de capturer une trace au niveau de l’API socket. Malheureusement, beaucoup d’applications socket ont un service déficient, et le seul moyen de les déboguer est d’utiliser une trace de composantes sockets.
Téléchargez cette ressource

État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
- Les PME attendent un meilleur accès aux données d’émissions de la part des fournisseurs
