LINUX.ORG.RU

Передача сокета между задачами (fork)


0

0

Есть задача написания сетевого сервера. В данный момент продумываю архитектуру. Пока остановился на варианте с одним процессом, обрабатывающим подключение и несколькими - обрабатывающими события.

Теперь возник вопрос о способе передачи данных в рабочие процессы (ребенку основного). Я так планировал, что при наличии готовности на чтения для сокета, этот сокет передается рабочему процессу, который уже читает из него все нужные данные.

Так вот - возможно-ли вообще это и если да - каким образом происходит процесс такой передачи?

> Так вот - возможно-ли вообще это и если да - каким образом происходит процесс такой передачи?

все происходит вполне естественным образом aka файловые дескрипторы родительского процесса наследуются дочерним после вызова fork().

// wbr

klalafuda ★☆☆
()

Да, можно передать файл-дескриптор оь одного процесса другому.
Это описано (с примерами кода) у Стивенса в APUE.

Если надо именно для Linux, то смотри книгу:
Linux Application Development by Michael K. Johnson, Erik W. Troan
глава 16.4.6 Passing File Descriptors.

Если книгу ломает покупать, то песдуй на http://www.danlj.org/lad/src/
там на халяву лежат исходники примеров из этой книги.
Тебе нужеи файл passfd.c (http://www.danlj.org/lad/src/passfd.c)

Но лучше книгу купи... и Стивенса купи...

anonymous
()
Ответ на: комментарий от anonymous

Т.е. получается, что сокет открытый в родителе так-же будет работать и в ребенке?

Я имею ввиду ситуацию, когда сокет передается от родителя ребенку уже _после_ форка, т.е. после создания ребенка.

UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy

> Я имею ввиду ситуацию, когда сокет передается от родителя ребенку уже _после_ форка, т.е. после создания ребенка.

нет, после возврата из fork() дочерний и родительский процессы живут полностью самостоятельной жизнью и их астральная связь нарушается.

ps: почитайте Стивенса, Робачевского, ну хоть что-то. это же самая база.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

2klalafuda:
> > Я имею ввиду ситуацию, когда сокет передается от родителя ребенку
> > уже _после_ форка, т.е. после создания ребенка.

> нет, после возврата из fork() дочерний и родительский процессы живут
> полностью самостоятельной жизнью и их астральная связь нарушается.

> ps: почитайте Стивенса, Робачевского, ну хоть что-то. это же самая
> база.

Если кому и надо Стивенса почитать, то это тебе.
Быстро читать пой пост выше и фтыкать в упомянутые там материалы.
МОЖНО передать файл-дескриптор _после_ fork() - без проблем.

Есть же русский перевод UNP Стивенса:

У.Р. Стивенс. UNIX Разработка сетевых приложений.
глава 14.7. Передача дескрипторов.

Или читай уже упомянутый Linux Application Development.

Брысь в школу, хацкер :-)))



anonymous
()
Ответ на: комментарий от anonymous

>МОЖНО передать файл-дескриптор _после_ fork() - без проблем.

что можно то это факт но задача весьма нетривиальная

cvv ★★★★★
()
Ответ на: комментарий от cvv

> > МОЖНО передать файл-дескриптор _после_ fork() - без проблем.

> что можно то это факт но задача весьма нетривиальная

Какая, нах, нетривиальная задача если есть общедоступные книги
где это разжевано, с примерами как это делать?
Или для тебя все, что сложнее "Хеллоу Ворлд" - нетривиально? :-D

anonymous
()
Ответ на: комментарий от Die-Hard

Кстати, да. Поэксперементировал с passfd.c - дескриптор нормально передается как из чилда родителю так и из родителя чилду. Очень хорошо. :)

UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy

> Кстати, да. Поэксперементировал с passfd.c - дескриптор нормально
> передается как из чилда родителю так и из родителя чилду. Очень
> хорошо. :)

А с чего бы ему не передаваться-то? :-/
Все-таки example из _второго_ издания книги ;-)

BTW, у Стивенса описание мне больше нравится, оно не Linux-specific.
Только все-таки лучше не
Chapter 27.9, "TCP Preforked Server, Descriptor Passing"
а Chapter 14.7 (там подробно разжевано).
Использовал fd passing "по мотивам" Стивенса на Solaris и AIX.

HTH

anonymous
()
Ответ на: комментарий от anonymous

Ну, передача дескриптора - полдела. Главное что он при этом работоспособности не теряет.

Кстати, еще вопрос.

В контексте использования такой передаче с сокетами.

1. Что делать с дескриптором сокета в родителе после того, как передал его ребенку в случае если он больше не понадобиться родителю.

2. Что делать с дескриптором сокета в чилде если этот дескриптор еще нужен будет родителю?

Я так понимаю, что просто ничего не делать?

3. Закрытие сокета либо в родителе, либо в чилде приведет к его закрытию глобально (и у чилда и у родителя)?

UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy

В процессе экспериментов заметил интересную вещь. Закрытие файловго дескриптора в родителе не влияет на него у потомка и наоборот. Т.е. если я его закрываю в родителе, потомок еще может с ним спокойно работать. Хотя, например, указатель текущей позиции у них общий.

Это нормально? То-же самое будет и с сокетами?

UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy

UncleAndy (09.09.2005 20:29:16):

> В процессе экспериментов заметил интересную вещь. Закрытие файловго дескриптора в родителе не влияет на него у потомка и наоборот.

Конечно!

Это -- классика. Ненужные дескрипторы всегда закрываются!

> То-же самое будет и с сокетами?

Попробуй!

Должно быть то же самое.

Die-Hard ★★★★★
()
Ответ на: комментарий от UncleAndy

>> Это -- классика. Ненужные дескрипторы всегда закрываются!

>А как в случае с тредами? Так-же?

Как это?

Нити ж одно и то же адр. пространство разделяют. Если закрыть в одной нитке дескриптор, то он и во второй закроется.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

Я это и имел ввиду. Просто уточнил.

Всем спасибо за пояснения! Die-Hard - персонально. :)

UncleAndy ★★★
() автор топика
Ответ на: комментарий от anonymous

> Да, можно передать файл-дескриптор оь одного процесса другому. Это описано (с примерами кода) у Стивенса в APUE.

забавно, но действительно работает.

ps: это чем-то напоминает "редактирование" таблицы файловых дескрипторов процесса в QNX4 i.e. такой же хак через почти такую же жуткую жопу но, тем не менее, работает :)

// wbr

klalafuda ★☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.