[Moscow.pm] Модули для поддержания соединения

[Alexander Lourier]

Один сокет можно использовать в нескольких процессах, но у вас должен быть
протокол, который это поддерживает. Системный вызов send позволяет
отправлять цельные блоки данных так, чтобы они не перебивались в середине
данными из другого процесса. Например, я вполне могу представить себе
родительский процесс, который устанавливает соединение с получателем
данных, запускает N детей, которые что-то вычисляют и сбрасывают результаты
своей работы непосредственно в сокет. Если нужно отправлять запросы и
получать ответы, то тут уже никак не проверить, кому из процессов
достанется ответ, если они друг с другом не будут договариваться через
какие-то механизмы синхронизации. Тогда дочерний процесс должен закрыть
соединение и открыть своё новое, чтобы с тем же сервером общаться по
отдельному соединению.

On Tue, Sep 8, 2015 at 1:59 PM Victor Efimov <victor на vsespb.ru> wrote:

> 8 сентября 2015 г., 14:52 пользователь Ilya Chesnokov
> <chesnokov.ilya на gmail.com> написал:
> > 8 сентября 2015 г., 0:03 пользователь Victor Efimov <victor на vsespb.ru>
> написал:
> >> Я думаю имелось ввиду несколько другое. Примеры это DBI и CPAN Redis.
> >
> > Ну да. Хотя в целом про TCP keepalive тоже интересная тема.
> >
> >> 1) Прежде чем послать данные в сокет сделать следующее:
> >>
> >>   if ($self->{pid} != $$) {
> >>     $self->connect;
> >>   }
> >>
> >> (код из Redis.pm)
> >>
> >> 2) В DESTROY, если он есть, делать деструкцию только если $self->{pid}
> == $$.
> >> Надо сказать, это нужно только в DBI, т.к. он в DESTROY посылает
> >> какие-то данные в сокет. В "обычных" клиентах не нужно. В Redis.pm
> >> нету.
> >
> > В-общем, ключевой вопрос в том, можно ли использовать одно и то же
> > соединение в разных процессах, если я правильно понял.
> > Если нельзя, то первый подход используется, если нельзя, то второй -
> > не закрывать соединение в дочерних процессах, а только в родительском.
>
> По-моему одно и то же соединение в любом случае использовать нельзя.
> Учитывая что сценарий -
> это fork() про который мы не знаем зачем и почему он. Возможно до
> fork() кто-то использовал соединение, после fork()
> собирается использовать и в child и parent. В таком случае и child и
> parent будут писать в один сокет. Это всё равно что они по-очереди
> будут писать в сокет в одном процессе.
>
> А DESTROY в DBI имхо просто для того чтобы закрыть коннект, чтобы у
> mysql сервера не висели открытые коннекты
>
> >
> >> 3) реконнект
> >>
> >> 8 сентября 2015 г., 5:36 пользователь Eugen Konkov <kes-kes на yandex.ru>
> написал:
> >>> Здравствуйте, Ilya.
> >>>
> >>> IC> Есть ли готовые модули для поддержания постоянного соединения с
> >>> IC> каким-либо сервером?
> >>> Обычное TCP соединение с keep-alive пакетами
> >>> http://habrahabr.ru/company/intersystems/blog/155565/
> >>> http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
> >>>
> >>>>не закрывалось при уничтожении форка
> >>> Делаете управление соединениями в мастер процессе. Создали соединение
> или их pool и отдаёте fork'ам хендлы. Если будет один хендл, То нужно будер
> решить проблему, какому форку передавать пришедший ответ (Думаю будет проще
> если создавать хендл/fork)
> >>>
> >>> Вы писали 7 сентября 2015 г., 12:18:21:
> >>>
> >>> IC> Добрый день.
> >>>
> >>> IC> Есть ли готовые модули для поддержания постоянного соединения с
> >>> IC> каким-либо сервером? Нужно для того, например, чтобы
> инициализировать
> >>> IC> соединение при старте веб-приложения и повторно использовать в
> форках,
> >>> IC> при этом чтобы оно не закрывалось при уничтожении форка, ну и
> заново
> >>> IC> соединялось при необходимости.
> >>>
> >>> IC> В-общем, нужно что-то вроде той части DBI, которая отвечает за
> >>> IC> TCP-соединение, но без всего того, что связано непосредственно с
> >>> IC> базами данных.
> >>>
> >>> IC> Да, и еще интересно, есть ли что-то подобное отдельно для
> AnyEvent::Handle.
> >>>
> >>> IC> --
> >>> IC> Best regards,
> >>> IC> Ilya Chesnokov
> >>>
> >>>
> >>>
> >>> --
> >>> С уважением,
> >>>  Eugen                          mailto:kes-kes на yandex.ru
> >>>
> >>> --
> >>> Moscow.pm mailing list
> >>> moscow-pm на pm.org | http://moscow.pm.org
> >
> >
> >
> > --
> > Best regards,
> > Ilya Chesnokov
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150908/50ab120d/attachment-0001.html>