способ реализации IPC - PullRequest
       11

способ реализации IPC

2 голосов
/ 16 декабря 2009

Каков предпочтительный способ реализации IPC поверх окон?

Я знаю несколько таких как: именованный канал, разделяемая память, семафоры? , может быть COM (хотя я не уверен, как) ...

Я хотел знать, что считается наиболее надежным, быстрым, наименее подверженным ошибкам и простым в обслуживании / понимании.

Ответы [ 5 ]

5 голосов
/ 16 декабря 2009

Несколько лет назад мы изучали этот конкретный вопрос для ситуации клиент / сервер, когда клиент и сервер работали на одной машине. В то время мы использовали сокеты (UDP), даже когда клиент и сервер находились на одной машине. Для нас «лучшим» оказалась общая память с именованными семафорами для ее синхронизации. В то время я в основном изучал каналы по сравнению с необработанной реализацией совместно используемой памяти. Я тестировал каналы с перекрывающимся вводом / выводом и с портами завершения ввода / вывода.

Я тестировал с большим разнообразием размеров данных. На нижнем уровне, где клиент и сервер отражали 1 байт назад и вперед, реализация первичной общей памяти была быстрее всего в 3 раза. Когда я пропустил 10000 байт назад и вперед, реализации канала и исходная реализация общей памяти были все примерно с той же скоростью. Я использовал 4K буферы, если я правильно помню с реализацией общей памяти.

Для всех размеров данных тест общей памяти проходил в 2-6 раз быстрее, чем при использовании сокетов (по сравнению с TCP).

Между реализациями конвейера перекрывающаяся версия ввода-вывода была быстрее, чем версия порта завершения ввода-вывода, примерно на 30% при передаче небольших объемов данных. Опять же, при больших порциях данных разница была минимальной.

Реализация канала была, конечно, гораздо менее сложной для кода. Но мы имели дело с несколькими небольшими порциями данных, передаваемых взад и вперед, поэтому стоило дополнительной сложности реализовать версию совместно используемой памяти с именованными семафорами.

Конечно, как было упомянуто, это было несколько лет назад, и вы не представляете, правильно ли я реализовал все различные тесты. Обратите внимание, что это было с одним клиентом. Окончательная реализация нашего взаимодействия с разделяемой памятью очень хорошо масштабируется для сотен запущенных «клиентов». Но я не знаю, лучше ли это в таком масштабе, чем конвейерная реализация.

2 голосов
/ 16 декабря 2009

Взгляните на boost :: interprocess .

Общая память, вероятно, самая быстрая в целом, но несколько подвержена ошибкам и ограничена локальными процессами.

COM полностью версии и автоматически поддерживает удаленный IPC, но, очевидно, это зависит от платформы.

Для крупномасштабного приложения вы можете рассмотреть что-то вроде ActiveMQ или OpenMQ .

1 голос
/ 17 декабря 2009

RPC / вне процесса COM или DCOM (которые в конечном итоге будут использовать RPC в любом случае) являются предпочтительным способом сделать IPC в Windows, если вы не делаете что-то действительно простое - я видел так много случаев, когда люди шли по пути именованных каналов и в конечном итоге в основном реализовывали то, что DCOM дает вам бесплатно . Не делайте ту же ошибку:)

1 голос
/ 16 декабря 2009

MSDN имеет хорошее резюме.

При этом, я думаю, вам стоит подумать об использовании сторонней библиотеки. Повышение должно быть хорошим - как указано в другом ответе - и ваш инструментарий GUI тоже может содержать некоторые абстракции.

Для чистого Win32 анонимные каналы должны быть самым простым методом (где вам нужно всего лишь вызвать CreatePipe и использовать два полученных дескриптора файла; удвоить все для полнодуплексного), но у него есть недостаток, заключающийся в том, что он работает только тогда, когда оба процесса работающий на той же машине, и что у вас уже должны быть какие-то средства связи между процессами для передачи дескрипторов.

0 голосов
/ 16 декабря 2009

транспорт по названным трубам для меня

для формата данных либо сверните свой собственный, либо используйте локальный RPC (именно это использует msft)

...