Cómo traspaso de un socket de escucha TCP con el mínimo tiempo de inactividad?

Question

Si bien esta pregunta se marca EventMachine, genéricos soluciones BSD sockets en cualquier idioma son muy apreciados también.

---

Algunos antecedentes:

Tengo una aplicación que escucha en un socket TCP. Se inició y cerró con una escritura regular System V init estilo.

Mi problema es que se necesita un poco de tiempo para poner en marcha antes de estar listo para dar servicio al socket TCP. No es demasiado largo, tal vez sólo 5 segundos, pero eso es de 5 segundos demasiado tiempo cuando un reinicio necesita ser realizado durante una jornada laboral. También es crucial que las conexiones existentes se mantengan abiertos y están acabados con normalidad.

Las razones para un reinicio de la aplicación son parches, actualizaciones, y similares. Lamentablemente, yo encuentro en la posición de que, de vez en cuando, tengo que hacer este tipo de cosas en la producción.

---

La pregunta:

Estoy buscando una manera de hacer un traspaso ordenado del socket de escucha TCP, a partir de un proceso a otro, y como resultado obtener sólo una fracción de segundo de tiempo de inactividad. Me gustaría conexiones / zócalos existentes para permanecer abierto y terminar el procesamiento en el proceso anterior, mientras que el nuevo proceso se inicia el servicio de nuevos connectinos.

¿Hay algún método probado de hacer esto usando BSD-enchufes? (puntos de bonificación para una solución EventMachine.)

¿Hay quizá bibliotecas de código abierto por ahí aplicación de la presente, que puedo usar como es, o utilizar como referencia? (De nuevo, las soluciones no Ruby y no EventMachine se aprecian también!)

Answer 1

Hay un par de maneras de hacer esto sin tiempo de inactividad, con las modificaciones adecuadas en el programa servidor.

Uno es implementar una capacidad de reinicio en el propio servidor, por ejemplo a la recepción de una cierta señal u otro mensaje. El programa entonces exec su nueva versión, pasándole el número de descriptor de archivo del socket de escucha, por ejemplo, como argumento. Este zócalo tendría la FD_CLOEXEC bandera clara (por defecto) por lo que sería heredado. Desde los otros zócalos seguirán siendo atendidos por el proceso original y no deben ser transmitidos al nuevo proceso, la bandera se debe establecer en aquellos, por ejemplo, utilizando fcntl() . Después de que se bifurcan y execing el nuevo proceso, el proceso original puede seguir adelante y cerrar el socket de escucha sin ningún tipo de interrupción del servicio, ya que el nuevo proceso está escuchando en ese socket.

Un método alternativo, si no desea que el servidor antiguo al que tenedor y exec con el nuevo servidor sí mismo, sería el uso de un toma de dominio Unix para la comunicación entre el proceso del servidor viejo y nuevo. Un nuevo proceso servidor puede comprobar si hay una toma de este tipo en un lugar bien conocido en el sistema de archivos cuando se está iniciando. Si está presente, el nuevo servidor se conectaría a esta toma y solicitar que el servidor de transferencia de edad su socket de escucha como datos auxiliares usando SCM_RIGHTS. Un ejemplo de esto se da al final de cmsg (3) .

Answer 2

Jean-Paul Calderone escribió un detalla la presentación en 2004 en una solución integral a su problema usando trenzado, incluyendo la migración zócalo y otros temas.