Comment puis-je déterminer le temps maximum nécessaire à la mort du socket TCP en raison d'une déconnexion réseau intermédiaire?

Question

J'ai un programme en C++, en utilisant l'API socket standard, fonctionnant sous Ubuntu 7.04, qui maintient une socket ouverte sur un serveur. Mon système vit derrière un routeur. Je veux comprendre combien de temps cela peut prendre pour obtenir une erreur de socket une fois que mon programme commence à envoyer APRÈS que le routeur soit coupé du réseau.

En d'autres termes, mon programme peut rester inactif (en attente de l'utilisateur). Le routeur est déconnecté d'Internet, puis mon programme essaie de communiquer sur ce socket.

De toute évidence, il ne va pas savoir rapidement, car TCP est très habile à maintenir une socket en vie dans des conditions de réseau défavorables. Cela provoque TCP à réessayer beaucoup de fois, de nombreuses façons, avant d'abandonner finalement.

J'ai besoin d'établir une sorte de «pire cas» que je peux donner au groupe de contrôle qualité (et au client), afin qu'ils puissent tester que mon code passe dans un état hors ligne approprié. (Pour référence, mon programme fait partie d'un système de paiement à la pompe pour les stations-service, et le serveur est le système qui autorise les transactions de paiement.Il est tout à fait possible que la station soit coupée du réseau pour une variété de raisons, et le client veut juste savoir à quoi s'attendre).

EDIT: Je n'étais pas clair. Il n'y a pas d'être humain qui attend sur cette chose, c'est juste pour une notation de back office du système hors ligne. Quand l'auteur ne revient pas dans 30 secondes, la transaction est terminée et les gens partent faire d'autres choses.

EDIT: Je suis arrivé à la conclusion que la question n'est pas vraiment responsable dans le cas général. Le nombre de facteurs impliqués dans la détermination de la durée d'une erreur de connexion TCP due à une panne en aval dépend trop de l'équipement exact et de l'échec pour qu'il y ait une réponse simple.

Answer 1

Vous devriez pouvoir utiliser:

http://linux.die.net/man/2/getsockopt

avec:

SO_RCVTIMEO et SO_SNDTIMEO

pour déterminer les délais d'attente impliqués.

Ce lien: http://linux.die.net/man/7/socket

parle plus d'options qui peuvent être vous intéresser.D'après mon expérience, il suffit souvent de choisir une heure. Même lorsque cela semble raisonnable, les délais d'attente arbitraires se comportent généralement mal dans la pratique. Le résultat général est que l'application devient inutilisable lorsque l'environnement tombe en dehors de la norme.

En particulier pour les transactions financières, cela devrait être évité. Peut-être fournir un bouton d'annulation et une indication que la transaction prend plus de temps que prévu serait une meilleure solution.

Answer 2

Je tournerais la question autour de l'autre sens: combien de temps un opérateur de caisse est-il prêt à rester là à regarder le client stupide avant de dire, il ne faut pas travailler pour le faire manuellement.

ramasser donc un peu de temps comme 1 minute (en supposant que votre réseau n'est pas déconnexion automatique, et ainsi se reconnecter lorsque le trafic se produit)

ensuite utiliser ce temps pour la durée de votre programme attend avant d'abandonner. Fermeture de la prise, etc. Affiche un message d'erreur. Peut-être même un compte à rebours en attendant, donc l'opérateur de caisse a une idée combien de temps le système va attendre ...

Ensuite, ils savent que la transaction a échoué, et que c'est l'heure manuelle. Sinon, en fonction de votre pile IP, le délai d'expiration le plus défavorable pourrait être «jamais expiré».

Answer 3

Je pense que la meilleure approche est de ne pas essayer de déterminer le délai d'attente utilisé, mais de spécifier le délai d'expiration vous-même.

En fonction de votre OS, vous pouvez: -

• utilisation setsockopt() avec option SO_SNDTIMEO,
• utilisation non-blocage send() et ensuite utiliser select() avec un délai d'attente
• utilisation non-bloquant send(), et ont un délai d'attente à la réception des données attendues.