> Tech > Examiner les points de trace des API sockets

Examiner les points de trace des API sockets

Tech - Par iTPro - Publié le 24 juin 2010
email

Pour illustrer la manière de lire les points de trace sockets, j’ai collecté une trace du serveur FTP à l’aide des commandes suivantes :
ENDTCPSVR *FTP TRCINT SET(*ON)
SIZE(128000)
TRCTYPE(*SCK)
SLTTRCPNT((100 999)
STRTCPSVR *FTP TRCINT SET (*OFF)
TRCINT

SET (*END)

Le tableau en bas de la trace liste trois jobs qui commencent par QTFTP. Concentrons-nous sur les appels d’API socket qui sont faits par le premier job. Le TDE # associé à ce job est 0000000073FB. Le premier point de trace enregistré pour ce job est un appel adressé à l’API socket(). Les trois paramètres sur l’API socket correspondent à #2, #3 et #4 dans le point de trace SC#000360 (figure 4 – à noter que j’ai ajouté le texte en rouge dans cette figure et dans les suivantes, à des fins d’illustration. Ce texte n’apparaîtra pas dans vos traces).

La dernière valeur sur le point de trace SC#00360 est une valeur système interne qui sera de 0 dans vos traces. La sortie API de cet appel de socket, SC#00365, montre que les deux rubriques dans la trace sont le code de renvoi et la valeur errno. Le code de renvoi provenant de l’API socket() est le numéro descripteur de socket nouvellement alloué qui fera référence à ce socket sur les appels d’API suivants. Le numéro descripteur et les valeurs errno sont tous deux de 0. Les trois appels d’API suivants que le serveur FTP effectue sont des appels setsockopt() destinés à changer les paramètres par défaut du socket que l’on vient de créer.

Au point de trace setsockopt(), SC#00340, les cinq paramètres sur l’API setsockopt() sont tracés en tant que #2, #3, #4, #5 et #6 (figure 5). Le paramètre option _ value, #5, est un pointeur système de huit octets vers le buffer de mémoire que l’application a transmis sur l’appel d’API. (Remarque : Dans cette trace, les API sockets fournissent des pointeurs système de huit octets au lieu des pointeurs de 16 octets utilisés par l’application). La valeur d’option réelle qui est stockée dans cet emplacement mémoire est tracée en tant que #8 sur le point de trace.

L’information listée comme #7 sur le point de trace SC#00340 est une valeur système interne que vous pouvez ignorer. Les autres appels setsockopt() que le serveur FTP effectue, sont semblables à celui-ci, mais avec des options différentes définies. L’API socket suivante que le serveur FTP appelle est bind(), qui attribue le numéro de port FTP bien connu 21 à ce socket, comme adresse locale. Les trois paramètres de l’API bind() sont fournis en tant que #2, #3 et #4 (figure 6).

Le stockage réel visé par le pointeur d’adresse local est fourni en #9. Pour la famille d’adresses AF_INET, une structure sockaddr_ in représente les adresses sockets locales et distantes. En examinant la sortie de trace dans #9, vous pouvez voir que le 0x15 est spécifié pour le numéro sin_port, qui est la valeur hexadécimale du numéro de port de serveur FTP 21. Ignorez les autres rubriques incluses dans ce point de trace. Toutes les API jusqu’à ce point se sont déroulées correctement. Mais ce n’est pas toujours le cas. Il est fréquent qu’une ou plusieurs API socket reviennent avec une défaillance. Les points de trace de défaillance d’API socket se trouvent dans de nombreuses traces, y compris celles au début du serveur FTP. Le serveur FTP i5/OS est constitué de multiples jobs.

Au moment du démarrage du serveur, chacun de ces jobs tente de se lier par bind() au port FTP. Le premier job se lie correctement à ce port, mais chacun des jobs suivants reçoit une défaillance sur l’appel bind(). Le point de trace sortie bind() SC#00125 montre que le code de renvoi (return code) est -1 et que la valeur errno est EADDRINUSE (figure 7). Quand une API socket se termine avec une erreur, une information semblable à cette défaillance bind() est incluse dans la trace. L’API suivante que le serveur FTP appelle est listen(). Cette API est simple et n’a que deux paramètres : le descripteur de socket et la valeur backlog.

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Tech - Par iTPro - Publié le 24 juin 2010