Débloquer les appels à la fonction de recv sans utiliser le mode non-bloquant

Lors de l'écriture d'une application réseau, vous pouvez utiliser le mode non bloquant ou le mode bloquant. Le mode non bloquant est plus flexible et nécessaire lorsque l'application doit faire plusieurs choses, comme par exemple l'entretien de plusieurs prises. Toutefois, si l'application ne fait qu'une seule chose, par exemple lire à partir d'une socket et écrire les données dans un fichier ou une file d'attente, l'utilisation du mode bloquant peut réduire considérablement la complexité de votre application. Il y a un petit problème avec le mode de blocage : si quelque chose ne va pas avec la connexion, l'application ne le saura peut-être jamais ; elle attendra éternellement des données qui n'arriveront jamais.

Comment cela peut-il se produire ? Imaginez que votre demande ait appelé le service de recouvrement et qu'elle attende les données d'un client. La connexion réseau du client n'est pas fiable et l'application cliente subit de multiples retransmissions. À un moment donné, la pile TCP du client décide que la connexion doit être interrompue ; elle en informe l'application cliente et nettoie la socket. Votre application est laissée en attente de données sur une connexion qui, en ce qui concerne le client, a été fermée. La seule façon de résoudre le problème est de terminer manuellement votre application et de la redémarrer. La fermeture de l'application laisse la socket connectée dans un état "TIME_WAIT" qui, à moins que vous n'ayez activé l'option REUSEADDR socket, vous empêchera de redémarrer immédiatement l'application et de la lier à la socket d'écoute.

Vous pouvez toutefois demander à OpenVOS de fixer un délai d'attente pour les données pendant l'appel de récupération. Le résultat est qu'à l'expiration du délai, l'appel renvoie un -1 et errno est réglé sur e$timeout (1081). Votre demande peut alors prendre une décision sur la manière de procéder. Elle peut mettre fin à la connexion, donner une autre chance au client, envoyer quelque chose au client pour tester la connexion, ou toute autre réponse appropriée à l'application. Le fait est que le diagnostic de la situation et la réponse sont sous votre contrôle.

Le programme timeout_recv.c de la figure 2 est un exemple de la façon de procéder. Il faut 2 arguments, un numéro de port à écouter et un délai d'attente en unités de 1/1024 de seconde. La figure 1 montre un exemple d'exécution, la ligne de commande (en gras et soulignée) est répétée car je suis convaincu que tous les arguments doivent être répétés par les programmes interactifs. Notez que j'ai fixé un délai d'attente de 10 secondes (10240 / 1024). Le programme signale quand il appelle accept et si accept, il renvoie un délai d'attente. Bien que je ne l'aie pas mentionné dans le paragraphe précédent, le délai d'attente fonctionne également pour l'appel d'acceptation et le programme le démontre. Une fois la connexion établie, le programme signale le moment où il appelle recv et le temps que recv retourne avec un délai d'attente ou des caractères. J'ai mis en évidence tous les messages de timeout.

Notez que les appels pour fixer les délais sont spécifiques à OpenVOS (et VOS) ; cette approche ne fonctionnera pas sous d'autres systèmes d'exploitation.

Figure 1 - Exemple d'exécution de timeout_recv

Figure 2 - timeout_recv.c