Comment la main sur une prise d'écoute TCP avec un minimum de temps?

Question

Bien que cette question est marqué eventmachine, génériques solutions socket BSD dans toutes les langues sont très appréciées aussi.

---

Un peu d'histoire:

J'ai une application écoute sur un socket TCP. Il est démarré et fermé avec un script d'initialisation régulière de style System V.

Mon problème est qu'il a besoin d'un certain temps pour démarrer avant qu'il ne soit prêt à servir le socket TCP. Ce n'est pas trop longtemps, peut-être seulement 5 secondes, mais qui est 5 secondes de trop quand un redémarrage doit être effectué au cours d'une journée de travail. Il est également essentiel que les connexions existantes restent ouvertes et sont terminées normalement.

Les raisons pour un redémarrage de l'application des patchs, mises à jour, etc.. Je me trouve malheureusement dans la position que, chaque fois dans un certain temps, je dois faire ce genre de chose dans la production.

---

La question:

Je cherche un moyen de faire une main sur propre de la prise d'écoute TCP, d'un processus à l'autre, et par conséquent obtenir seulement une seconde de temps d'arrêt de séparation. Je voudrais les connexions existantes / prises pour rester ouvert et terminer le traitement dans l'ancien processus, alors que le nouveau processus commence le service de nouvelles connectinos.

Y at-il une méthode éprouvée de le faire en utilisant les sockets BSD-? (Les points bonus pour une solution de eventmachine).

Y at-il peut-être des bibliothèques open-source là mettant en œuvre ce que je peux utiliser tel quel, ou utiliser comme référence? (Encore une fois, des solutions non-Ruby et non eventmachine sont trop apprécié!)

Answer 1

Il y a deux façons de le faire sans temps d'arrêt, avec des modifications appropriées au programme du serveur.

La première consiste à mettre en œuvre une capacité de redémarrage dans le serveur lui-même, par exemple lors de la réception d'un certain signal ou un autre message. Le programme serait alors exec sa nouvelle version, il passe le numéro de descripteur de fichier de la prise d'écoute par exemple comme argument. Cette prise aurait le drapeau FD_CLOEXEC clair (par défaut) si qu'il serait hérité. Étant donné que les autres prises continueront d'être desservis par le processus original et ne doivent pas être transmis au nouveau processus, le drapeau doit être mis sur les par exemple en utilisant fcntl() . Après bifurquer et execing le nouveau processus, le processus original peut aller de l'avant et de fermer la prise d'écoute sans interruption de service, étant donné que le nouveau processus est maintenant à l'écoute sur la socket.

Une autre méthode, si vous ne voulez pas l'ancien serveur d'avoir à fork et exec le nouveau serveur lui-même, serait d'utiliser un socket de domaine Unix pour communiquer entre l'ancien et le nouveau processus de serveur. Un nouveau processus de serveur peut vérifier une telle prise dans un endroit bien connu dans le système de fichiers quand il commence. Le cas échéant, le nouveau serveur se connecter à cette prise et demander que l'ancien transfert de serveur sa prise d'écoute en tant que données auxiliaires en utilisant SCM_RIGHTS. Un exemple est donné à la fin de cmsg (3) .

Answer 2

Jean-Paul Calderone a écrit une présentation détaillée en 2004 sur une solution globale à votre problème en utilisant Twisted, y compris la migration de prise et d'autres questions.