Механизмы IPC в C# - использование и передовые практики
Некоторое время назад я использовал IPC в коде Win32 - критические секции, события и семафоры.
Как сцена в среде .NET? Есть ли какой-нибудь учебник, объясняющий все доступные параметры, когда их использовать и почему?
+1. Слава Богу. Это первый случай вопросов с привкусом "Best Practices", который не помечен как неконструктивный / не по теме [который я когда-либо видел] !!
Ответы 6
Самый последний материал Microsoft в IPC - Фонд связи Windows. На самом деле на нижнем уровне нет ничего нового (tcp, upd, именованные каналы и т. д.). Но WCF значительно упрощает разработку IPC.
Полезный ресурс:
- Межпроцессное взаимодействие с WCF на портале доктора Добба
- Параметры связи WCF в .NET Framework 3.5
и конечно MSDN в WCF
Привет, видео по первой ссылке мертво!
Существует также .NET Remoting, который мне показался довольно крутым, но я думаю, они устарели теперь, когда у них есть WCF.
Сказал ли Microsoft такое на самом деле?
У них есть: «Этот раздел относится к устаревшей технологии, которая сохраняется для обратной совместимости с существующими приложениями и не рекомендуется для новой разработки. Теперь распределенные приложения должны разрабатываться с использованием Windows Communication Foundation (WCF)». от msdn.microsoft.com/en-us/library/kwdt6w2k.aspx
Я работал с Remoting в течение многих лет. Для небольших приложений (например, передача до 1k небольших объектов) это очень просто и эффективно. Выше этого предела, нет! Это действительно отстой. Вы должны заархивировать данные перед отправкой, и это добавляет дополнительные накладные расходы (использование ЦП). У меня были очень неприятные воспоминания об этой проблеме.
Я обычно использую именованные каналы или сокеты Unix (в зависимости от того, нацелен ли я на MS.NET или Mono - у меня есть класс, который абстрагирует его), поскольку он прост в использовании, переносится и позволяет мне легко взаимодействовать с неуправляемым кодом. . Тем не менее, если вы имеете дело только с управляемым кодом, используйте WCF или удаленное взаимодействие - последнее, если вам нужна поддержка Mono, поскольку их поддержки WCF просто еще нет.
Хотя это могло иметь место в сентябре 2008 года (когда был сделан этот комментарий), сейчас 2011 год, и WCF на Mono сейчас достаточно зрелый. Смотрите Страница разработки Mono WCF и судите сами.
Похоже, вас интересуют методы синхронизации, а не общение. Если это так, вы можете запустить здесь или, возможно, еще один краткий обзор.
Помимо очевидного (WCF), существует довольно хорошая привязка ZeroMQ для C# / CLR:
http://www.zeromq.org/bindings:clr
Реализует ориентированные на сообщения IPC, pub / sub и различные другие стратегии с гораздо меньшим количеством кода и конфигурации, чем WCF.
Кроме того, он, по крайней мере, на порядок быстрее, чем что-либо еще, и имеет меньшую задержку, если вам требуется связь с низкой задержкой.
Что касается семафоров, блокировок, мьютексов и т. д. Если вы делитесь посредством общения, а не общаетесь посредством совместного использования, у вас будет меньше хлопот, чем при традиционной парадигме.
Что это значит?
Я понимаю, что это означает, что вместо того, чтобы делиться ресурсами и каждая программа пытается требовать их по своему желанию, вы должны заставить программы напрямую общаться друг с другом с IPC. В первом сценарии ваши программы «общаются», блокируя общий ресурс. Во втором они общаются через какой-то протокол, чтобы координировать использование общего ресурса.
The inter-process ipc transport is disconnected, like tcp. It has one limitation: it does not yet work on Windows. Soooo actually not really IPC for windows right? Which still might be quite common when the C# tag was added.
Вы мог используете адаптер локальной петли с ZeroMQ. Однако производительность, очевидно, будет зависеть от реализации адаптера. Однако мне не нравится семантика обращения к сетевому стеку (хотя и виртуальному интерфейсу), когда вы не намерены общаться по сети. Лично для IPC на той же машине я считаю использование трубок лучшим решением. Реализация .NET Standard надежна и полностью переносима. Решения с отображенной памятью могут предложить лучшую производительность, но использование собственного - сложная задача, а синхронизация подвержена ошибкам. "делиться общением" :)
Я бы рекомендовал использовать файлы с отображением памяти, если вам нужно использовать домен машины, а не связь через сеть. См. Следующую ссылку.
http://techmikael.blogspot.com/2010/02/blazing-fast-ipc-in-net-4-wcf-vs.html
Список API локальных машин .NET: weblogs.asp.net/ricardoperes/…
Что нужно сделать? Если вам нужно синхронизировать доступ к какому-либо внешнему ресурсу, вы можете использовать Mutex для реализации межпроцессной синхронизации.