Как к передаче TCP, слушая сокет с минимальным временем простоя?
В то время как этим вопросом является отмеченный EventMachine, универсальные решения BSD-сокета на любом языке очень ценятся также.
Некоторый фон:
У меня есть приложение, слушающее на сокете TCP. Это запускается и закрывается с init сценарием стиля регулярной System V.
Моя проблема состоит в том, что требуется некоторое время для запуска, прежде чем это будет готово обслужить сокет TCP. Это не слишком длинно, возможно, только 5 секунд, но это составляет 5 секунд слишком долго, когда перезапуск должен быть выполнен во время рабочего дня. Также крайне важно, чтобы существующие соединения остались открытыми и обычно заканчивались.
Причинами перезапуска приложения являются патчи, обновления, и т.п.. Я, к сожалению, оказываюсь в положении, что время от времени я должен сделать такого рода вещь в производстве.
Вопрос:
Я ищу способ сделать аккуратную передачу TCP, слушая сокет от одного процесса до другого, и в результате получить только долю секунды времени простоя. Я хотел бы, чтобы существующие соединения / сокеты остались открытыми и закончили обрабатывать в старом процессе, в то время как новый процесс начинает обслуживать новый connectinos.
Есть ли некоторый испытанный метод выполнения этого использования BSD-сокеты? (Бонусные очки для решения EventMachine.)
Есть ли, возможно, библиотеки с открытым исходным кодом, там реализовывая это, которое я могу использовать как есть, или использовать в качестве ссылки? (Снова, не-Ruby и решения non-EventMachine ценятся также!)
2 ответа
Большинство ЦП имеют жестко закодированный вектор сброса , который определяет адрес первой команды, выполняемой после аппаратного сброса. Думайте об этом как о матери всех немаскируемых прерываний.
-121--4998217-FireFinder делает именно то, что вы ищете. Можно вычислить выражения CSS или XPath, в них будут перечислены соответствующие элементы, а также нарисована красная граница вокруг них.
Если нужно просто выполнить быстрое тестирование, можно также открыть панель инструментов разработчика (F12) и использовать $ $ ('селектор') для быстрого поиска.
Существует несколько способов сделать это без простоев с соответствующими модификациями серверной программы.
Одним из них является реализация возможности перезапуска в самом сервере, например, после приема определенного сигнала или другого сообщения. Затем программа выполняет свою новую версию, передавая ей номер дескриптора файла слушающего сокета, например, в качестве аргумента. Для этого сокета должен быть снят флаг FD _ CLOEXEC (по умолчанию), чтобы он наследовался. Поскольку другие сокеты будут продолжать обслуживаться исходным процессом и не должны передаваться новому процессу, флаг должен быть установлен на тех, которые, например, используют fcntl () . После форсирования и выполнения нового процесса исходный процесс может продолжить работу и закрыть сокет прослушивания без прерывания обслуживания, поскольку новый процесс теперь прослушивает этот сокет.
Альтернативный метод, если вы не хотите, чтобы старому серверу пришлось раскачивать и выполнять сам новый сервер, заключается в использовании Unix-domain сокета для обмена данными между старым и новым серверными процессами. Новый серверный процесс может проверить наличие такого сокета в известном месте файловой системы при его запуске. При наличии новый сервер подключится к этому сокету и запросит, чтобы старый сервер передал свой прослушивающий сокет в качестве вспомогательных данных с помощью SCM_RIGHTS. Пример этого приведен в конце cmsg (3) .
Жан-Поль Кальдероне написал подробную презентацию в 2004 году о комплексном решении вашей проблемы с использованием Twisted, включая миграцию сокетов и другие проблемы.