Коммуникация C# между процессами
Я работаю с приложением, и я могу сделать сценарии C# для выполнения в этой среде. Я могу импортировать DLLs любого вида в эту среду. Моя проблема состоит в том, что я хотел бы включить коммуникацию между этими сценариями. Поскольку средой управляют, и у меня нет доступа к исходному коду приложения, я в замешательстве относительно того, как сделать это.
Вещи я попробовал:
Файловый ввод-вывод: Просто при записи сообщений, что я хотел бы, чтобы каждый считал в .txt файлах и чтении другого его. Проблема состоит в том, что мне нужно это сценарии для выполнения вполне быстро, и это заняло слишком много времени.
nServiceBus: Я попробовал это, но я просто не мог заставить это работать в среде, с которой я имею дело. Я не говорю, что это не может быть сделано, просто что я не мог сделать его.
Кто-либо знает о простом способе сделать это, которое также довольно быстро?
8 ответов
Ответ прост:
Поскольку вы можете импортировать любую DLL в сценарий вы можете создать собственную библиотеку DLL, которая будет реализовывать связь между процессами любым способом: общая память, именованный канал, TCP / UDP.
Что ж, не зная подробностей вашего окружения, я мало что могу предложить. Вы используете термин «сценарии C #» ... Я не совсем понимаю, что это означает, поскольку C # обычно является компилируемым языком.
Если вы используете обычный C #, изучали ли вы WCF с именованными каналами? Если ваши сборки работают на одном физическом компьютере, вы сможете легко и быстро создать некоторые службы WCF, размещенные с привязкой Named Pipe. Именованные каналы обеспечивают простой, эффективный и быстрый механизм передачи сообщений в локальном контексте. Сам WCF довольно прост в использовании и является встроенным компонентом платформы .NET.
Вы можете использовать PipeStream . Что быстрее, чем дисковый ввод-вывод, поскольку они выполняются с использованием основной памяти.
Ваш метод межпроцессного взаимодействия должен зависеть от того, насколько важно обрабатывать каждое сообщение.
Например, если процесс A приказывает процессу B, скажем, отправить электронное письмо вашему ИТ-персоналу о том, что сервер не работает, это очень важно.
Однако при потоковой передаче звука отдельные сообщения (пакеты) не критичны для производительности приложения и могут быть отброшены.
В первом случае вам следует рассмотреть возможность использования постоянного хранилища, такого как база данных, для хранения сообщений и позволить каждому процессу опрашивать базу данных для получения своих собственных сообщений. Таким образом, если процесс завершается или временно теряет связь с другими процессами, он сможет получить любые сообщения, которые он пропустил, при повторном запуске.
Вы можете использовать форму межпроцессного взаимодействия даже в рамках одного процесса. Относитесь к своим сценариям как к отдельным процессам и общайтесь таким образом.
Именованные каналы могут быть хорошим вариантом в этой ситуации. Они очень быстрые и довольно простые в использовании в .NET 3.5.
В качестве альтернативы, если сценарии загружаются в один домен приложения, вы можете использовать статический класс или синглтон в качестве службы связи. Однако, если скрипты загружаются изолированно, это может оказаться невозможным.
XMPP / Jabber - еще одна оценка, взгляните на jabber.net .
Поскольку у вас уже есть файловый ввод-вывод, вы можете получить достаточную скорость, разместив его на RAM-диске. Если вы опрашиваете изменения сегодня, то FileSystemWatcher может помочь сделать вашу коммуникацию более отзывчивой.
Еще один простой способ - открыть сокет TCP на заранее определенном порте, подключиться к нему из другого процесса и обмениваться данными таким образом.