форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Межпроцессорное общение"
Сообщение от Simps (ok) on 09-Июн-04, 11:28  (MSK)
Есть один процесс и n-ное количество других процессиков. Есть у кого нибудь рабочее решение, общения между процессиками и процессом ? Пробовал делать через message queue ... Шлю мессадж от главного процесса в надежде что его получат все, получает только один из всех ... Пробовал делать через shared memory, получают все но начинается пляска с блокировками (блокировать сообщение пока оно не обработается), в итоге сервер может послать только одно сообщение и впадает в бесконечный цикл пока ждет его разблокировки ... Можно конечно внести элемент таймаута ... Как еще можно организовать эффективное межпроцессорное общение ?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Межпроцессорное общение"
Сообщение от Vladislav Lazarenko on 09-Июн-04, 16:40  (MSK)
>Есть один процесс и n-ное количество других процессиков. Есть у кого нибудь >рабочее решение, общения между процессиками и процессом ? Пробовал делать через >message queue ... Шлю мессадж от главного процесса в надежде что >его получат все, получает только один из всех ... Пробовал делать >через shared memory, получают все но начинается пляска с блокировками (блокировать >сообщение пока оно не обработается), в итоге сервер может послать только >одно сообщение и впадает в бесконечный цикл пока ждет его разблокировки >... Можно конечно внести элемент таймаута ... Как еще можно организовать >эффективное межпроцессорное общение ? RPC, XML RPC, SOAP, Java RMI, CORBA, COM/DCOM, Sockets/Pipes etc.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "Межпроцессорное общение"
	Сообщение от Simps (ok) on 09-Июн-04, 17:32  (MSK)
	>>Есть один процесс и n-ное количество других процессиков. Есть у кого нибудь >>рабочее решение, общения между процессиками и процессом ? Пробовал делать через >>message queue ... Шлю мессадж от главного процесса в надежде что >>его получат все, получает только один из всех ... Пробовал делать >>через shared memory, получают все но начинается пляска с блокировками (блокировать >>сообщение пока оно не обработается), в итоге сервер может послать только >>одно сообщение и впадает в бесконечный цикл пока ждет его разблокировки >>... Можно конечно внести элемент таймаута ... Как еще можно организовать >>эффективное межпроцессорное общение ? > >RPC, XML RPC, SOAP, Java RMI, CORBA, COM/DCOM, Sockets/Pipes etc. Что вы выбираете ? Я выбираю sockect =)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Межпроцессорное общение"
	Сообщение от Vladislav Lazarenko on 09-Июн-04, 17:34  (MSK)
	>>>Есть один процесс и n-ное количество других процессиков. Есть у кого нибудь >>>рабочее решение, общения между процессиками и процессом ? Пробовал делать через >>>message queue ... Шлю мессадж от главного процесса в надежде что >>>его получат все, получает только один из всех ... Пробовал делать >>>через shared memory, получают все но начинается пляска с блокировками (блокировать >>>сообщение пока оно не обработается), в итоге сервер может послать только >>>одно сообщение и впадает в бесконечный цикл пока ждет его разблокировки >>>... Можно конечно внести элемент таймаута ... Как еще можно организовать >>>эффективное межпроцессорное общение ? >> >>RPC, XML RPC, SOAP, Java RMI, CORBA, COM/DCOM, Sockets/Pipes etc. > >Что вы выбираете ? Я выбираю sockect =) Зависит от задачи. В больших проектах я часто использую CORBA или RMI. Редко бывает необходимо использовать sockets .. Вы бы ещё на ассемблере писать начали ...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Межпроцессорное общение"
	Сообщение от Simps (ok) on 09-Июн-04, 17:52  (MSK)
	>>>>Есть один процесс и n-ное количество других процессиков. Есть у кого нибудь >>>>рабочее решение, общения между процессиками и процессом ? Пробовал делать через >>>>message queue ... Шлю мессадж от главного процесса в надежде что >>>>его получат все, получает только один из всех ... Пробовал делать >>>>через shared memory, получают все но начинается пляска с блокировками (блокировать >>>>сообщение пока оно не обработается), в итоге сервер может послать только >>>>одно сообщение и впадает в бесконечный цикл пока ждет его разблокировки >>>>... Можно конечно внести элемент таймаута ... Как еще можно организовать >>>>эффективное межпроцессорное общение ? >>> >>>RPC, XML RPC, SOAP, Java RMI, CORBA, COM/DCOM, Sockets/Pipes etc. >> >>Что вы выбираете ? Я выбираю sockect =) > > >Зависит от задачи. В больших проектах я часто использую CORBA или RMI. >Редко бывает необходимо использовать sockets .. Вы бы ещё на ассемблере >писать начали ... А причем тут ассемблер ? Я конечно понимаю что Вы сами офигиваете от своего ума, но всетаки причем тут ассемблер ?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Межпроцессорное общение"
	Сообщение от Vladislav Lazarenko on 09-Июн-04, 17:54  (MSK)
	>>>>>Есть один процесс и n-ное количество других процессиков. Есть у кого нибудь >>>>>рабочее решение, общения между процессиками и процессом ? Пробовал делать через >>>>>message queue ... Шлю мессадж от главного процесса в надежде что >>>>>его получат все, получает только один из всех ... Пробовал делать >>>>>через shared memory, получают все но начинается пляска с блокировками (блокировать >>>>>сообщение пока оно не обработается), в итоге сервер может послать только >>>>>одно сообщение и впадает в бесконечный цикл пока ждет его разблокировки >>>>>... Можно конечно внести элемент таймаута ... Как еще можно организовать >>>>>эффективное межпроцессорное общение ? >>>> >>>>RPC, XML RPC, SOAP, Java RMI, CORBA, COM/DCOM, Sockets/Pipes etc. >>> >>>Что вы выбираете ? Я выбираю sockect =) >> >> >>Зависит от задачи. В больших проектах я часто использую CORBA или RMI. >>Редко бывает необходимо использовать sockets .. Вы бы ещё на ассемблере >>писать начали ... > >А причем тут ассемблер ? Я конечно понимаю что Вы сами офигиваете >от своего ума, но всетаки причем тут ассемблер ? Я имел в виду столь низкий уровень ... зачем долазить до сокетов, программировать межпроцессорное взаимодействие так низко, делать свои баги и так далее ?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Межпроцессорное общение"
	Сообщение от ram_scanner on 11-Июн-04, 07:59  (MSK)
	>>>>>>Есть один процесс и n-ное количество других процессиков. Есть у кого нибудь >>>>>>рабочее решение, общения между процессиками и процессом ? Пробовал делать через >>>>>>message queue ... Шлю мессадж от главного процесса в надежде что >>>>>>его получат все, получает только один из всех ... Пробовал делать Btw message queue очень удобное средство, проглючить там сложно, и проблема в данном случае решается достаточно просто. Поскольку очередь получается на всех одна, то пускай "один процесс" будет иметь заранее определенный ID сообщения, который знают "процессики" а каждый "процессик" сгенерит себе идентификатор и сообщит его "одному процессу" маркируя их егошным ID (чтобы соседи по очереди сообщение не схавали). А "один процесс" пускай сообщения свои отправляет в очередь персонально каждому "процессику", маркируя их идентификаторами этих "процессиков". А уж достать из очереди сообщение с ID равным заданому проблем не составляет.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "Межпроцессорное общение"
	Сообщение от DeadMustdie (??) on 11-Июн-04, 19:49  (MSK)
	>Я имел в виду столь низкий уровень ... зачем долазить до сокетов, >программировать межпроцессорное взаимодействие так низко, делать >свои баги и так далее ? Для того, чтобы - обеспечить соблюдение ограничений по потребляемым ресурсам, - исключить необходимость таскать за собой с машины на машину и с платформы на платформу громоздкое middleware непонятного устройства со своими собственными особенностями и багами, - а также для повышения переносимости, так как писать собственный портабельный софт разумного размера существенно проще, нежели портировать чужого  перекормленного крокодила на платформу, где он сроду не работал. Действовать может любая из перечисленных выше причин или их комбинация. Собственно при выборе инструментария и нужно соизмерять затраты труда, времени и денег с планом разработки и доступными в каждый момент ресурсами. Работать на "низком" уровне в ряде случаев намного дешевле и даже удобнее.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Межпроцессорное общение"
	Сообщение от Vladislav Lazarenko on 14-Июн-04, 10:18  (MSK)
	>>Я имел в виду столь низкий уровень ... зачем долазить до сокетов, >>программировать межпроцессорное взаимодействие так низко, делать >>свои баги и так далее ? > >Для того, чтобы > - обеспечить соблюдение ограничений по потребляемым ресурсам, > - исключить необходимость таскать за собой с машины на машину >и с платформы на платформу громоздкое middleware непонятного устройства >со своими собственными особенностями и багами, > - а также для повышения переносимости, так как писать собственный >портабельный софт разумного размера существенно проще, нежели портировать >чужого  перекормленного крокодила на платформу, где он сроду не работал. > >Действовать может любая из перечисленных выше причин или их комбинация. >Собственно при выборе инструментария и нужно соизмерять затраты труда, >времени и денег с планом разработки и доступными в каждый момент >ресурсами. Работать на "низком" уровне в ряде случаев намного дешевле >и даже удобнее. Ну если бы Вы прочли хотя бы одну книгу о PM, то знали бы, что писать на столь низком уровне - это круто, но написать что-то будет стоить таких больших денег и огромного кол-ва времени, что за это никто не берется (кроме OpenSource проектов, которым все пофоигу, может быть ?). Зачем изобретать велосипеды ? :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Межпроцессорное общение"
	Сообщение от DeadMustdie (??) on 14-Июн-04, 18:56  (MSK)
	>Ну если бы Вы прочли хотя бы одну книгу о PM, то >знали бы, что писать на столь низком уровне - это круто, >но написать что-то будет стоить таких больших денег и огромного кол-ва >времени, что за это никто не берется (кроме OpenSource проектов, которым >все пофоигу, может быть ?). Зачем изобретать велосипеды ? :) Если под 'PM' понимается управление проектами, то Ваше заключение о моей полной 'неначитанности' не вполне соответствует действительности. Однако в некоторых из этих самых книжек весьма внятно написано, что необходимость использования кода со стороны должна быть тщательно исследована. В краткосрочном плане максимальное использование готовых решений позволяет быстро собрать решение из "строительных блоков", однако в долгосрочной перспективе помимо прямых плюсов есть и явные минусы, главный из которых - большая зависимость потребительских свойств продукта от свойств составляющих его компонент. При этом бывает весьма сложно, а то и невозможно компенсировать нехватку некоторых свойств этих самых компонент в коде самого продукта. Примеров масса; лично для меня наиболее болезненные воспоминания связаны с перечнем поддерживаемых платформ, то бишь переносимостью, шедевра под названием VisiBroker. А уж страдальцы (я бы даже сказал - *терпилы*) от компании Borland/Inprise никогда не перестанут потрясать моё воображение. Каждый раз при выходе новой версии Дельфов али ещё какого чуда начинается народный стон: "а вот в новой версии то исправили и сё добавили, нам её купили, а она, зараза такая, не то что старые проекты нормально не ест - исходники старые, сто лет назад написанные и отлаженные, выплёвывает". И никак не могут люди понять, что если компания так "нежно" относится к своим пользователям, то им пора уже как минимум ответить ей взаимностью. А насчёт изобретения велосипедов - если нужно купить в магазине упаковку замороженных блинчиков с повидлом, нет никакой необходимости арендовать автобус "Икарус" для перевозки себя, родимого, от дома через перекрёсток напротив, где расположен супермаркет. Дороговато, да и хлопот только лишних прибавит. Ножками - оно проще. Впрочем дело вкуса. Не хочу, чтобы создалось впечатление, будто я кому своё мнение навязываю :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "ИМХО Берётся Стивенс читается пишется 150 строк кода"
	Сообщение от ZOD (??) on 03-Фев-05, 18:06  (MSK)
	наполовину содраного из книжки и не парится. Я конечно понимаю что для здачку класса поставщик - потребители можно решить и с КОРБАй но не понимаю нафик нужен такой гемороище. >>>>Есть один процесс и n-ное количество других процессиков. Есть у кого нибудь >>>>рабочее решение, общения между процессиками и процессом ? Пробовал делать через >>>>message queue ... Шлю мессадж от главного процесса в надежде что >>>>его получат все, получает только один из всех ... Пробовал делать >>>>через shared memory, получают все но начинается пляска с блокировками (блокировать >>>>сообщение пока оно не обработается), в итоге сервер может послать только >>>>одно сообщение и впадает в бесконечный цикл пока ждет его разблокировки >>>>... Можно конечно внести элемент таймаута ... Как еще можно организовать >>>>эффективное межпроцессорное общение ? >>> >>>RPC, XML RPC, SOAP, Java RMI, CORBA, COM/DCOM, Sockets/Pipes etc. >> >>Что вы выбираете ? Я выбираю sockect =) > > >Зависит от задачи. В больших проектах я часто использую CORBA или RMI. >Редко бывает необходимо использовать sockets .. Вы бы ещё на ассемблере >писать начали ...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "ИМХО Берётся Стивенс читается пишется 150 строк кода"
	Сообщение от DeadMustdie (??) on 03-Фев-05, 20:15  (MSK)
	>ИМХО Берётся Стивенс читается пишется 150 строк кода >наполовину содраного из книжки и не парится. Я конечно понимаю что для >здачку класса поставщик - потребители можно решить и с КОРБАй но >не понимаю нафик нужен такой гемороище. Золотые слова. Почему-то ярым апологетам употребления везде и вся охренительно больших миддлварей не приходит в голову, что при наличии некоего (не особенно большого) опыта на так называемом "низком" уровне программы разрабатываются и быстрее, и дешевле. Плюс при сопровождении меньше зависишь от "большого дяди".
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "ИМХО Берётся Стивенс читается пишется 150 строк кода"
	Сообщение от Vladislav Lazarenko on 04-Фев-05, 14:23  (MSK)
	>>ИМХО Берётся Стивенс читается пишется 150 строк кода >>наполовину содраного из книжки и не парится. Я конечно понимаю что для >>здачку класса поставщик - потребители можно решить и с КОРБАй но >>не понимаю нафик нужен такой гемороище. > >Золотые слова. Почему-то ярым апологетам употребления везде и вся >охренительно больших миддлварей не приходит в голову, что при наличии >некоего (не особенно большого) опыта на так называемом "низком" уровне >программы разрабатываются и быстрее, и дешевле. Плюс при сопровождении >меньше зависишь от "большого дяди". Хм, возможно, Вы в чем-то и правы. Однако, изобретать велосипеды, заново писать уже исправленые баги не очень полезно в большинстве случаев.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "Стрелять из пушек по воробьям"
	Сообщение от ZOD (??) on 04-Фев-05, 17:57  (MSK)
	не есть правильно, дорого и промахнёшся... Написано же сдирается из книжки... Какой такой велосипед..?  В чём сложность..? Можно даже на плюсах всё сварганить (если оно надо), тот кто с++ знает спокойно переделает всё на них... (я вообще думал что у ООПщиков такие задачи давно в каком нить виде в библиотеке лежат, где же повторное использование кода?) Тут даже RPC не нужно. Не говоря уже о КОРБАх КОМах и прочей ереси. Сложный интрумент нужен для решения сложных задач, а не таких. Можно гвозди микроскопом забивать, а нужно молотком.... Я вот слышал про человека который на exel VBS нейронную сеть хитрой конфигурации реализовал. Вот как Вы ПМы думаете --- правильный ли это подход для инженера или нет? Слава богу что он не инженер, а учёный --- им такое можно, а нам нельзя. >>>ИМХО Берётся Стивенс читается пишется 150 строк кода >>>наполовину содраного из книжки и не парится. Я конечно понимаю что для >>>здачку класса поставщик - потребители можно решить и с КОРБАй но >>>не понимаю нафик нужен такой гемороище. >> >>Золотые слова. Почему-то ярым апологетам употребления везде и вся >>охренительно больших миддлварей не приходит в голову, что при наличии >>некоего (не особенно большого) опыта на так называемом "низком" уровне >>программы разрабатываются и быстрее, и дешевле. Плюс при сопровождении >>меньше зависишь от "большого дяди". > >Хм, возможно, Вы в чем-то и правы. Однако, изобретать велосипеды, заново писать >уже исправленые баги не очень полезно в большинстве случаев.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "Стрелять из пушек по воробьям"
	Сообщение от Vladislav Lazarenko on 04-Фев-05, 18:06  (MSK)
	Мне кажется, что на CORBA все же удобнее, и ничего в ней тяжелоге нет. Программы работают достаточно быстро. Но, конечно, если уже готово решение, то лучше использовать его, переписав из книжки.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	15. "Ну незнаю,"
	Сообщение от ZOD (??) on 04-Фев-05, 19:52  (MSK)
	я предпочитаю решать задачи максимально тупым из всех возможных методов. Перед этим прикинув какие с этим могут быть проблемы в дальнейшем, и насколько они решатся если я что-то усложню. Уровень socket и RPC для моих задач более чем достаточен. Описаная же задача как раз из этой области. Пусть средняя команда разработчиков допускает 3 ошибки на 1000 строк кода. В варианте решения этой задачей с Корба мы суммируем количество ошибок в своём коде + количество ошибок во ВСЁм коде корбы (ибо как о внутренностях третьестороннего продукта ничего не знаем и перестраховываемся). Второй момент --- такого рода --- допустим нам нужно прикрутить аутентификацию процессов общающихся друг с другом (вот мы попали когда передирали с Стивенса). Как это сделать? Написать ещё 100 строк + криптовальная библиотека + nное количество гемороя, а если мы использовали мидлваре то что? Либо уже есть либо ещё 50 строк и есть. В общем моё ИМХО таково --- если архитектура проекта проработана --- именно архитектура, а не частности, то можно не напррягаться и передирать Стивенса в необходимых количествах. А если делаем то незнаем что, то высокоуровневый инструментарий нам поможет. Пример продуманой архитектуры --- UNIX. Как известно хотя базовая безопасность там есть но остальное прикручено весьма сбоку, как и сеть (через 10 лет после первой реализации). Тем неменее в области сетей оно number one, а в области безопасности не хуже остальных. Хотя несомненно есть лучше. Пример не очень продуманой --- MSW. Вещи типа HAL и микроядра ИМХО продуманы и правильны. Всё в качестве сервисов --- очень хорошо. Использование RPC тоже как правило по делу, но реализация самих сервисов делалось ИМХО по принципу --- помере надобности, потом как нибудь прикрутим. И что мы видим в результате? Да система работает, да дыры в безопасности более менее залатаны, но писать под неё софт --- упаси боже. Проблемы несовместимости также имеют место быть. Как это всё работает, хотябы на пальцах боюсь, что мало кто понимает, да никого это и не волнует мы же абстрагировались. В общем как вывод моё ИМХО таково --- использование абтракций мидлваре и вообще лишних сущностей там где ненадо, приводит к необоснованому росту объёма кода и сложности взаимодействий и хотя возможность поддержки всего этого объёма сохраняется но требует она всё больших усилий и более сложного инструментария/квалифицированой рабочей силы. В случае же простой типа UNIX архитектуры, и малого количества неочёвидно связаных сущностей сохраняется возможность использования раб силы в среднем более низкой квалификации и простейшего инструментария. Это кстати мы наглядно видим в виде Linux как ремэйка UNIX образца конца 80х. Сообщество GNU не потянуло очень сложных проектов типа OpenOffice или GNOME итп без помощи со стороны  проприетарных разработчиков, однако ремэйк UNIX получился более менее удачный.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.