Здравствуйте, glh, Вы писали:
glh>Коллеги! Господа!
glh>Занимался ли кто-нибудь сравнением производительности и областей применения различных способов межпроцессного взаимодействия?
glh>Под "производительностью" здесь понимается "perfomance", эффективность обработки запросов и пропускная способность данного канала IPC.
glh>Имеются в виду прежде всего messages, mailslots, named pipes, memory-mapped files, sockets.
glh>Понятно, что:
glh>сообщения — локально, малый размер передаваемых данных;
glh>слоты — асинхронные уведомления, причем только односторонне;
glh>сокеты — сеть.
glh>Интересует в разрезе эффективного общения между собственно сервером и клиентами.
glh>коммуникационными демонами-транспортами в рамках одной машины.
glh>Характер взаимодействия: сервер, возможно statefull, работающий в режиме запрос-ответ и коммуникационные демоны-транспорты.
glh>Клиенты общаются с демонами реализующий транспорт, демоны с сервером.
glh>Объемы передаваемых данных — сравнимы с траффиком SQL и/или HTTP серверов. Ответы много больше запросов.
glh>Мейлслоты отпадают. Сокеты в данном случае излишне, к тому же это будет одним из транспортом. 
glh>В основном, я думаю, выбор сводится к сравнению named pipes и memory mapped files.
glh>PS. http://www.rsdn.ru/article/?baseserv/ipc.xmlАвтор(ы): Алекс Jenter
Дата: 10.03.2001
Обзор основных технологий IPC: Очень многим приложениям, если не большей части, требуется
информация от других приложений, либо они должны эту информацию сообщать.
Именно поэтому в операционную систему встраивается множество механизмов,
которые обеспечивают т.н. Interproccess Communication (IPC) — то есть
межпроцессное взаимодействие...
прочитан и ответа на вопрос не дает, тк представляет лишь обзор возможных методов.
Я доволен named pipe
У меня на одной трубе к серверу одновременно до 30 клиентов соединяются
Время реакции устраивает Трафик будь здоров
Тем более что сервер и клиенты на разных компах
Да и объемы прокачиваемой информации приличные
Конечно это мое субъективное мнение
