Вообще да. Нужен такой протокол и нужно опираться на гарантии ОС по поводу атомарности и флаша буферов и их размера. Чего там с send? === If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted === как оно будет если сервер не успевает читать данные? И какой размер гарантируется? по-моему это не очень документировано http://stackoverflow.com/a/16165686/1625053
8 сентября 2015 г., 15:22 пользователь Alexander Lourier <[email protected]> написал: > Один сокет можно использовать в нескольких процессах, но у вас должен быть > протокол, который это поддерживает. Системный вызов send позволяет > отправлять цельные блоки данных так, чтобы они не перебивались в середине > данными из другого процесса. Например, я вполне могу представить себе > родительский процесс, который устанавливает соединение с получателем данных, > запускает N детей, которые что-то вычисляют и сбрасывают результаты своей > работы непосредственно в сокет. Если нужно отправлять запросы и получать > ответы, то тут уже никак не проверить, кому из процессов достанется ответ, > если они друг с другом не будут договариваться через какие-то механизмы > синхронизации. Тогда дочерний процесс должен закрыть соединение и открыть > своё новое, чтобы с тем же сервером общаться по отдельному соединению. > > On Tue, Sep 8, 2015 at 1:59 PM Victor Efimov <[email protected]> wrote: >> >> 8 сентября 2015 г., 14:52 пользователь Ilya Chesnokov >> <[email protected]> написал: >> > 8 сентября 2015 г., 0:03 пользователь Victor Efimov <[email protected]> >> > написал: >> >> Я думаю имелось ввиду несколько другое. Примеры это 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 <[email protected]> >> >> написал: >> >>> Здравствуйте, 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:[email protected] >> >>> >> >>> -- >> >>> Moscow.pm mailing list >> >>> [email protected] | http://moscow.pm.org >> > >> > >> > >> > -- >> > Best regards, >> > Ilya Chesnokov >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
