ivan_p 19 июл 2013 в 18:39

Простой Inter-Process Communication на C#

4 мин

33K

.NET*C#*

Из песочницы

Комментарии 20

Houston 19 июл 2013 в 18:47

WCF разве не для таких задач предназначен?

ivan_p 19 июл 2013 в 18:55

Вы правы, и для таких. Но ответ на Ваш вопрос уже есть в статье.

Тут можно развести хороший такой холивар, опираясь на то что .NET ориентирован на абстрагирование от канала передачи данных и позволяет одинаково хорошо шарить объекты как по сети, так и между процессами. Но поскольку тема статьи – именно IPC, то попрошу этого не делать.

StanEgo 20 июл 2013 в 09:58

А чем Windows Communication Foundation не Inter-process Communication? Есть классика IPC в Windows — named pipes. IpcChannel — это старая обертка для них. NetNamedPipeBinding в WCF — новая. Никаких причин считать, что старый .net remoting в лице IpcChannel более IPCстей, чем WCF — нет))

Yustos 19 июл 2013 в 19:06

Да, раньше я тоже пробовал IpcChannel, а позже WCF для общения с созданным подпроцессом…
Теперь делаю проще. Запускаю процесс:

var start = new ProcessStartInfo
{
	...
	UseShellExecute = false,
	RedirectStandardInput = true,
	RedirectStandardOutput = true
};

А затем, чтобы пообщаться с ним (в обе стороны, от папы-сыну, от сына-папе), сериализую сообщение, и у дочернего процесса жду:

Encoding.Default.GetString(Convert.FromBase64String(Console.ReadLine()));

От родительского шлю:

process.StandardInput.WriteLine(Convert.ToBase64String(mySerializedMessage));

А уж через консоль поддерживаются и синхронная и асинхронная модель обмена сообщениями.
Не видел ничего проще. Брат жив.

PS: По прежнему не хватает приличной имперсонации подпроцесса и завершения подпроцесса в случае исчезновения отца. Без финтов имею ввиду. На стековерфлоу обе задачи решаются через pinvoke.
Ну и обычного форка не хватает :)

-2

ivan_p 19 июл 2013 в 19:14

Если нету handle'a на приемник (например посылаем сообщение в процесс, на который мы поставили хук), или передаем нечто более сложное чем обычная строка — то этот подход уже не пройдет.
Хотя я с Вами полностью согласен, для простых задач городить огород не стоит — чем проще решение, тем оно надежней.

Yustos 19 июл 2013 в 19:25

Я там писал что сообщение (объект) я сначала сериализую в строку. А перевожу в base64 против всяких там переносов строк.
В этом плане от того же WCF/IPC ничем не отличается — везде нужно уметь сериализовать объект, чтобы передать другому.

ivan_p 19 июл 2013 в 19:35

Сразу не сообразил что Вы имели ввиду объект.

Yustos 19 июл 2013 в 19:48

Жаль не пишут почему минусуют…
А то статья про «простой» IPC :) Может ещё проще есть способ?

ivan_p 19 июл 2013 в 19:52

Увы и ах, но минусовал не я.
Всего способов достаточно много (можно даже простой PostMessage использовать), некоторые упомянуты в статье.

Yustos 19 июл 2013 в 20:05

Не на вас сокрушаюсь — я действительно ищу способ проще :)

kekekeks 19 июл 2013 в 22:21

Вы можете сделать Remoting поверх stdin/stdout, это очень, очень просто делается, и намного удобнее текстовых команд.

igoriok 31 июл 2013 в 22:11

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

kekekeks 1 авг 2013 в 05:39

Ну вы можете получить из TextWriter-ов потоков stdin/stdout настоящий бинарный Stream и гонять байтмассивы, полученные через BinaryFormatter, который умеет нормально работать с сообщениями, генерируемыми RealProxy и RemotingServices.

kekekeks 19 июл 2013 в 19:22

Remoting вообще штука замечательная. Наследуетесь от RealProxy, и получаете на входе в Invoke объект, отражающий всю информацию о вызове метода, которую в дальнейшем можно использовать как угодно (натравить BinaryFormatter и отправить получателю, как это делают стандартные средства, реализовать свой механизм IPC, etc). А что ещё замечательнее, работает без проблем с Mono, чего нельзя сказать о WCF. Так же рекомендуется посмотреть в сторону ServiceStack.

MrEsp 20 июл 2013 в 11:09

Ничего хорошего про Remoting сказать не могу. В году 05-07 был популярен. Сейчас все WCF используют для новых проектов.

ivan_p 20 июл 2013 в 13:02

А как же AOP c использованием RealProxy?=)

kekekeks 22 июл 2013 в 13:02

Вообще, это медленно и заставляет наследоваться от MarshalByRefObject, в случае с AOP всё же лучше наэмитить классов-наследников.

kekekeks 22 июл 2013 в 13:01

Для IPC в рамках одной машины Remoting подходит идеально, у него нет недостатков, влияющих на этот сценарий использования. WCF не работает нормально с Mono. Посему ни на iOS, ни на андройде вы его нормально использовать не сможете. Не говоря уже о случаях с серверной частью на *nix. Так что для IPC через веб стоит использовать ServiceStack.

yan4esko 19 июл 2013 в 23:50

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

Конечно, все время терзают смутные сомнения на счет того, что стоит разобраться с WCF, но никак руки не доходят…

Piskov 20 июл 2013 в 14:11

Ничего сложного, обязательно разбирайтесь — как-никак, уже 2013-й на дворе :-).

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время