Examiner les points de trace des API sockets (2)

<sys/socket.h> comme SOMAXCONN et a une valeur de 512 (0x200 en hexadécimal) sur i5/OS. L’API accept() attend que les requêtes de connexion entrantes arrivent sur le port du serveur FTP. Le format d’API accept() est semblable à celui de l’API bind(). Les trois paramètres de l’API accept() sont fournis en tant que #2, #3 et #4 (figure 9). Il existe une différence entre les points de trace bind() et accept() : avec accept(), le stockage vers lequel remote_address pointe n’est pas inclus dans la sortie de trace parce que ce paramètre est un champ de sortie. Autre différence : adress_length est à la fois un paramètre d’entrée et de sortie. Quand l’API est appelée, adress_length spécifie la taille du buffer d’adresse à distance ; à la sortie de l’API, adress_length spécifie la longueur de l’adresse qui a été stockée dans le buffer d’adresse à distance.

Les autres champs du point de trace SC#00100 sont des valeurs système internes que l’on peut ignorer. Pendant le démarrage, le serveur FTP n’appelle pas toutes les API importantes. Au début de l’article, j’ai indiqué que, au coeur de toute application client/serveur, on trouve huit API sockets. Utilisons une trace du client FTP i5/OS pour examiner les API restantes. L’API connect() établit une connexion TCP/IP. Les paramètres de connect() ressemblent à ceux de bind(), et la sortie de trace est également ressemblante. Ces trois paramètres connect() sont fournis en tant que #2, #3 et #4 sur le point de trace SC#00140 (figure 10). Dans cet exemple FTP, le format de l’adresse de destination est une structure sockaddr_ (voir figure 6). Le stockage réel visé par le pointeur d’adresse de destination est fourni en #10. Comme c’est le cas avec les points de trace entrée bind() et accept(), SC#00140 inclut un certain nombre de valeurs système internes que l’on peut ignorer.

Même si ce n’est pas dit au début de cet article, de nombreuses applications réseau, y compris le client FTP, utilisent souvent select(). L’API select() permet à une application d’attendre qu’une activité se manifeste sur un ou plusieurs descripteurs de sockets. Les cinq paramètres de select() sont fournis en tant que #2, #3, #4, #5 et #6 (figure 11). L’API select() a quatre paramètres qui sont autant de pointeurs vers du stockage supplémentaire. Si un pointeur NULL est transmis pour l’un de ces paramètres, la chaîne NULL est affichée au lieu du contenu du stockage en #7, #8, #9 et #10. Dans la figure 11, NULL est affiché pour le stockage write et exception, puisqu’un pointeur NULL (ne contenant que des zéros) a été transmis pour ces deux paramètres.

Quand l’API select() se termine et qu’un point de trace SC#00255 est généré, le stockage read, write et exception mis à jour (updated) est fourni en tant que #4, #5 et #6. Le stockage pour le temps d’attente n’est pas affiché à la sortie parce que ce paramètre n’est qu’un paramètre d’entrée de select() ; chacun des autres paramètres sont tous deux des variables d’entrée et de sortie. Certaines API apparaissent dans les traces client et serveur FTP, mais ce ne sont pas de vraies API sockets. Les API read(), write(), ioctl() et close() sont en fait des interfaces IFS qui fonctionnent sur les deux fichiers et sockets. Quand ces API sont appelées par une application réseau, l’API FILEOPxxxx affiche la trace pour le nom API. Les API send() et recv() sockets sont plus efficaces que les API read() et write(), IFS, mais beaucoup d’applications sont codées de manière à utiliser les API read() et write() IFS lors de l’envoi et de la réception de données sur le réseau (c’est le cas par exemple de FTP. Sur le point de trace entrée de l’API write(), SC#00950, seuls deux champs sont utiles : #2, le descripteur de socket, et #8, les données proprement dites envoyées (figure 12).

Vous pouvez ignorer le reste des rubriques de trace incluses sur le point de trace write(). Le point de trace sortie de l’API write(), SC#00955, trace le descripteur de socket, le code de renvoi et la valeur errno. Le code de renvoi (return) de l’API write() est le nombre d’octets qui ont été envoyés. Sur le point de trace entrée de l’API read(), SC#00940, là aussi deux champs sont utiles : #2, le descripteur de socket, et #3, la taille du buffer de données qui a été spécifiée par l’application pour contenir les données entrantes (figure 13). Le point de trace sortie de l’API read(), SC#00945, est le point de trace le plus intéressant dans ce cas, parce qu’il trace sur l’entrée #10 les données réellement reçues.

Ignorez le reste des rubriques de trace incluses sur les points de trace entrée et sortie de l’API read(). TRCINT présente une limitation : parfois, il n’inclut pas toutes les données d’application réelles envoyées ou reçues dans la sortie de trace. Par exemple, si l’application envoie et reçoit de grandes quantités de données sur un appel d’API unique, seuls les 10 000 premiers octets environ sont inclus dans la sortie de TRCINT. La quantité de données d’application tracées varie selon le point de trace réel et la release i5/OS utilisée. L’API finale que le serveur FTP et le client FTP utilisent tous deux, est le close() IFS (figure 14). L’API close() termine la connexion TCP/IP et ferme le socket.