Отправка изображений из процесса C ++ в процесс C #

Question

Я пытаюсь отправить данные изображения из скомпилированного процесса C ++ в скомпилированный процесс C #. Процесс C ++ обращается к веб-камере и выполняет некоторую обработку изображения. Изображение представлено двумерным массивом пикселей, причем каждое значение пикселя представляет собой 8-битное значение (0-255), которое является значением серой шкалы этого пикселя. Размер изображения 640 на 480.

Приложение C # выполняет дополнительную обработку и отображает это изображение на экране. Оба процесса одновременно выполняются на моем ноутбуке (ОС Windows 7), но я не могу создать один процесс, который выполняет все шаги, поэтому мне необходим код C ++ и C # для взаимодействия.

Мне было интересно, как лучше всего это сделать? Я читал о написании UDP или TCP-сервера в части C # и клиента в части C ++, затем я могу отправить данные изображения в виде дейтаграммы. Мне было интересно, если это лучший способ и будет ли лучше UDP или TCP?

РЕДАКТИРОВАТЬ: Процесс C ++ неуправляемый C ++, у меня нет возможности запустить его как управляемую DLL. Могу ли я использовать именованные каналы для отправки поверх изображения?

Наконец, UDP гарантирован в порядке, если он общается локально? Я понимаю, что изображение будет превышать ограничение для UDP, но если оно будет не по порядку, я смогу разделить изображения для отправки.

Answer 1

Межпроцессное взаимодействие может осуществляться через сокеты или каналы.

С помощью сокетов (TCP и UDP) вы, по сути, отправляете данные через Интернет себе.К счастью, поскольку ваша комп знает себя, данные не должны покидать комп, поэтому это должно быть довольно быстро.TCP гарантированно будет в порядке и обладает множеством других полезных функций, в то время как UDP в значительной степени накладывает некоторые заголовки на данные и надеется на лучшее.Для этого приложения TCP должен быть в порядке.UDP добавляет ненужную сложность.

Каналы - это другой способ взаимодействия двух процессов.У вас в основном есть процесс C ++ или C #, создающий канал и запускающий другой процесс.Вы просто используете канал как файл: пишите и читайте из него.Это можно сделать в C / C ++, используя комбинацию функций pipe, fork и exec или просто используя функцию popen.C #, вероятно, имеет аналогичные функции.

Я предлагаю использовать канал, используя _popen, (popen для windows) и записать серию целых чисел в канал и прочитать его с другой стороны.Это, наверное, самый простой способ ... помимо использования одного языка, конечно ...

Answer 2

Если вы пишете обе программы, вы можете скомпилировать одну из C ++ как DLL и вызвать функцию, которая возвращает массив или некоторую структуру из вашей программы на C # с атрибутом DllImport в пространстве имен System.Runtime.InteropServices.

Answer 3

Почему вы не можете сделать это в том же процессе?Это потому, что вам нужно смешивать C # и C ++?В этом случае C ++ / CLI можно использовать в качестве моста между средами, чтобы код C # для .NET CLR и код C ++ изначально компилировались в одном процессе.

Если вам действительно нужны два процесса, есть несколько вариантовпри работе на локальной машине, но небольшой сервис на основе TCP, вероятно, лучше.Размер каждого изображения будет 307 КБ, что превышает ограничение UDP в 65 КБ.

Answer 4

Просто перейдите к полностью управляемому коду: p (чтобы сохранить все в одном процессе)

https://net7mma.codeplex.com/SourceControl/latest имеет C # RtspServer и RtpClient

Answer 5

Один из способов сделать это отдельно от сокетов - сохранить данные изображения на диск из приложения C ++ и прочитать их с диска в приложении C #.Конечно, вам нужно будет убедиться в некоторой синхронизации чтения / записи, чтобы файл не читался до его полной записи.

Или, наконец, вы решите использовать UDP или TCP, попробуйте использовать RTP.RTP использует UDP с дополнительным уровнем меток времени, порядковой нумерацией для обеспечения правильного порядка доставки данных.Вы должны быть в состоянии найти реализации протокола на C ++ и C #.Следует особо отметить, что вы можете отправлять изображения через поток RTP / MJPEG, если ваше приложение создает изображения JPEG.

Answer 6

Мне было интересно, является ли это лучшим способом и будет ли лучше UDP или TCP?

Вы обычно прибегаете к UDP для оптимизации скорости, когда TCP не быстрыйдостаточно и потеря пакета неудобна , а не тогда, когда не может быть обработан .Если вы не можете справиться с потерей части изображения при передаче, я сомневаюсь, что вы можете прибегнуть к UDP.

Более того, UDP вряд ли даст повышение производительности в вашем случае, так как вы будете использовать интерфейс обратной связи,Это означает, что все TCP-пакеты, скорее всего, будут доставлены в порядке и без потерь, что сделает TCP более дешевым.

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

Наконец, TCP-сокеты проще в использовании, поэтому, если на вашем компьютере TCP не работает достаточно быстро, я бы придерживался TCP-сокетов.

гарантируется ли UDP, если он осуществляет локальную связь?

AFAIK, это поведение , не гарантируется .Скорее всего, это сработает большую часть времени, но если вы не найдете цитату из соответствующей документации, я бы на это не рассчитывал.

Могу ли я использовать именованные каналы для отправки поверх изображения?

Да, именованные каналы очень похожи на сокеты, но известно, что они медленные.