Skip to main content

Il y a environ 18 mois, j'ai écrit un blog pour parler des changements dans le fonctionnement de l'acceptation dans la version 17.1 d'OpenVOS. Ce que j'ai négligé d'indiquer, c'est que ces changements ne prennent effet que si le code de l'application est basé sur POSIX. Pour résumer, avant la version 17.1, STCP ne répondait à une demande de connexion d'un client que si le code d'application du serveur avait appelé la routine d'acceptation. Si le code n'avait pas appelé la routine d'acceptation, la demande de connexion du client était placée dans une file d'attente mais ne recevait pas de réponse. Une fois que l'application appelait "accept", le STCP envoyait une réponse de connexion. Si le client est toujours en attente, la connexion se termine à ce moment. Si le client avait déjà abandonné, il répondrait à la réponse de connexion par une réinitialisation, le STCP jetterait la connexion et l'acceptation serait suspendue (en supposant un mode de blocage) et attendrait une autre connexion.

La figure 1 illustre ce scénario ; les lignes de texte justifiées à gauche sont des messages d'état de l'application serveur, les lignes indentées packet_monitor (légèrement modifiées) sont le résultat de l'activité du client. L'application (acceptTestnoPosix) est lancée et écoute sur le port 12345, et une fois l'écoute terminée, elle s'endort pendant 300 secondes. Le client établit ensuite une connexion sur le port 12345 en envoyant un segment TCP sur le port 12345 avec le drapeau Syn (S) activé. Il essaie trois fois avant d'abandonner. Après 300 secondes, l'application se réveille et les appels sont acceptés. La pile STCP répond au client en envoyant un segment TCP avec les drapeaux Syn et Ack (SA) activés. Comme le client n'a plus d'enregistrement de la connexion s'il envoie un Reset (R), le STCP se bloque à ce stade. Si la socket était en mode non-bloquant, l'acceptation serait revenue avec une erreur EAGAIN.

acceptTestnoPosix 12345
Exécution du testnoPosix 12345
Dormir pendant 300 secondes

  11:04:45.923 R TCP 164.152.77.50 164.152.77.217 11071 12345 S
  11:04:48.925 R TCP 164.152.77.50 164.152.77.217 11071 12345 S
  11:04:54.937 R TCP 164.152.77.50 164.152.77.217 11071 12345 S

Prêt à accepter une connexion sur le port numéro 12345
  11:09:41.852 T TCP 164.152.77.217 164.152.77.50 12345 11071 SA 
  11:09:41.854 R TCP 164.152.77.50 164.152.77.217 11071 12345 R

Figure 1 - Accepter avant le 17.1 ou après le 17.1 non-POSIX

 

Si l'application est basée sur POSIX, les choses sont différentes (figure 2). Le STCP répond à la demande de connexion (S) immédiatement (SA). Puis, après 300 secondes, l'application se réveille, les appels sont acceptés et STCP renvoie la prise acceptée.

acceptTestwithPosix 12345
Exécution du testnoPosix 12345
Dormir pendant 300 secondes

  10:58:43.962 R TCP 164.152.77.50 164.152.77.217 11024 12345 S
  10:58:43.964 T TCP 164.152.77.217 164.152.77.50 12345 11024 SA 
  10:58:43.964 R TCP 164.152.77.50 164.152.77.217 11024 12345 A

Prêt à accepter une connexion sur le port numéro 12345
Connexion acceptée

Figure 2 - accepter un poste basé sur POSIX 17.1

 

La différence de comportement peut être critique. Si le client attend une réponse de l'application du serveur après avoir établi une connexion, il peut s'écouler un certain temps et fermer la connexion avant que l'application n'appelle effectivement pour accepter.

Comment construire une application avec POSIX ? D'abord la ligne

#define _POSIX_C_SOURCE 200112L

doit être la première ligne de la source de la demande. En second lieu, le chemin de la bibliothèque

(master_disk)>système>bibliothèque d'objets positifs

doit se trouver dans les chemins des bibliothèques d'objets après les bibliothèques STCP et avant la bibliothèque C.

Comment pouvez-vous savoir si cela a été fait ? Vous pouvez consulter les bibliothèques d'objets auxquelles l'application était liée en utilisant la commande display_program_module -object_dirs

display_program_module acceptTestwithPosix -object_dirs      
     %azvos#m17_mas>SysAdmin>Noah_Davids>temp>acceptTestwithPosix.pm 

Carte du répertoire des objets :

    11 annuaires de recherche
     0 annuaires non-recherche
    11 annuaires au total

   Chemin du répertoire du DTC

     1 %azvos#m17_mas>SysAdmin>Noah_Davids>temp
     2 %azvos#m17_mas>system>stcp>object_library
     3 %azvos#m17_mas>system>stcp>object_library>socket
     4 %azvos#m17_mas>system>stcp>object_library>net
     5 %azvos#m17_mas>system>stcp>object_library>common
     6 %azvos#m17_mas>system>posix_object_library
     7 %azvos#m17_mas>system>c_object_library
     8 %azvos#m17_mas>system>object_library
     9 %azvos#m17_mas>opt>apache>lib
    10 %azvos#m17_mas>opt>openssl>lib
    11 %azvos#m17_mas>opt>mysql>lib>mysql

Mais cela ne vous dit pas si la #define fait partie du code source.

Si vous pouvez exécuter le code, vous pouvez regarder les drapeaux de socket, un programme basé sur POSIX aura le drapeau de socket SF_POSIX activé. Par exemple, j'ai trois programmes acceptTestnoPosix, acceptTestwithPosix et acceptTestwithPosixPathOnly. Ce dernier avait le répertoire >system>posix_object_library dans les chemins de la bibliothèque mais n'incluait pas le #define dans le code source. Notez que cette combinaison est considérée comme non valide. Seule l'application qui était liée à la bibliothèque POSIX et qui avait l'instruction POSIX_SOURCE #define dans le code a créé une socket avec le drapeau SF_POSIX.

acceptTestnoPosix.pm 12345     
Exécution du testnoPosix 12345
Dormir pendant 300 secondes
               as : match posix ; dump_stcbq -full -lport 12345     
               comme :
acceptTestwithPosix.pm 12345
Exécution du testnoPosix 12345
Dormir pendant 300 secondes
               as : match posix ; dump_stcbq -full -lport 12345
                                                   SF_POSIX
               comme :  
acceptTestwithPosixPathOnly.pm 12345
Exécution du testnoPosix 12345
Dormir pendant 300 secondes
               as : match posix ; dump_stcbq -full -lport 12345
               comme :

Il y a une quatrième possibilité, le #define était inclus dans la source mais la posix_object_library n'a pas été utilisée. Dans ce cas, la routine de socket renvoie une erreur.

acceptTestwithPosixDefineOnly 12345
Exécution du testnoPosix 12345
acceptTestnoPosix : ne peut pas créer de prise d'écoute : Application construite  
+ incorrect : Le runtime POSIX doit être recherché avant le runtime C.

Toutes les commandes et utilitaires du STCP sont construits avec POSIX et je recommande fortement que toutes les applications que vous construisez utilisent également POSIX.

2024 Stratus Technologies.