сокет для обмена сообщениями между пользовательским интерфейсом и кодом C?

Question

сокет для обмена сообщениями между пользовательским интерфейсом и кодом C?

1

Я реализовал библиотеку C и хотел бы продемонстрировать ее функциональность для пользовательского интерфейса. Пользовательский интерфейс будет либо интерфейсом Windows Forms, либо интерфейсом WPF.

Чтобы придумать более "независимый от платформы" способ связывания UI и C lib вместе, я подумал о создании сокета на стороне интерфейса, а также на стороне C. Сокет будет использоваться для обмена двунаправленными сообщениями между пользовательским интерфейсом и библиотекой. Я знаю, что могут быть некоторые накладные расходы, чтобы сделать это таким образом, но "трафик сообщений" между пользовательским интерфейсом и кодом C не будет тяжелым.

Другая причина для этого заключается в том, что я читал, что есть много ошибок, о которых вы должны знать, когда используете PInvoke, IJW, COM или CLI (для включения вызовов С# -to-C и C-to -С#). Этот сокет-подход делает его более чистым, и я буду лучше контролировать, что происходит, когда код С# отправляет сообщение в код C (или наоборот).

Чтобы начать работу и чтобы не тратить время, я ищу советы от опытных разработчиков, которые много знают о кодах сокетов.

Я не уверен, что должны быть требования для кода сокета с обеих сторон? Я знаю, что хочу, чтобы какой-либо компонент на стороне пользовательского интерфейса мог отправлять и отвечать на сообщения.

user1884325 22 сен. 2014, в 19:36

Источник

0

Вы подразумеваете под «сокеты»: сетевые сокеты? Может быть, вы можете использовать именованные каналы. Именованные каналы могут быть созданы на стороне C ++ и на стороне C #. На стороне C # у вас есть NamedPipeServerStream и NamedPipClientStream . Вы получаете к ним доступ через интерфейс Stream .
Sjips 22 сен. 2014, в 17:27
0

Это звучит почти так, как должно быть на Programmers.SE .
gunr2171 22 сен. 2014, в 17:28
0

Почему не Windows Communication Foundation? msdn.microsoft.com/en-us/library/dd456779(v=vs.110).aspx
paparazzo 22 сен. 2014, в 17:32
0

Просто хотел бы сказать, что издержки вызовов сокетов и сериализации, вероятно, будут намного больше, чем P / Invoke. Конечно, есть и подводные камни для P / Invoke, но есть и для сокетов.
Joel Lucsy 22 сен. 2014, в 17:46
0

@joel: да, вы, вероятно, правы, но трафик сообщений не будет большим объемом / частотой .... и код будет "чище"
user1884325 22 сен. 2014, в 18:17
1

Так что же не так с P / Invoke точно?
Blindy 22 сен. 2014, в 18:34
0

@Blam он сказал "платформа независима".
Peter Ritchie 22 сен. 2014, в 19:26
0

Вы серьезно не хотите использовать сокеты для такого рода вещей. Независимость от платформы - это неправильное название, и в конце этого пути вы найдете много горя.
Peter Ritchie 22 сен. 2014, в 19:27
0

@peter: что может пойти не так, выставив функциональность c lib через API сервер / клиент?
user1884325 22 сен. 2014, в 21:00
0

Теперь у вас есть зависимость от сети, драйвера, наличия карты. Конфигурация этого сокета теперь требуется. хотя «сокеты» существуют во всех операционных системах, у вас не будет единого фрагмента кода, который будет работать на всех из них, - у вас будут разные варианты, что приведет к дополнительному обслуживанию. Если он настроен для сети, у вас будет сетевой трафик (и замедление из-за него), которого у вас не было раньше. У вас будут объекты для передачи данных и / или сопоставления формы в памяти и обратно по беспроводной сети, которой вам также придется управлять. и т.п.
Peter Ritchie 22 сен. 2014, в 21:03
0

@peter: так что бы вы сделали? Давайте просто примем Windows в качестве платформы для пользовательского интерфейса и C-lib
user1884325 22 сен. 2014, в 21:11
0

Я бы просто вызвал библиотеку.
Peter Ritchie 22 сен. 2014, в 21:12
0

@peter: разве CLI не является рекомендуемым способом включения двунаправленных вызовов между окнами форм c # и статической C lib? я полагаю, что "клей" является C ++ CLI DLL? это позволяет для двунаправленных звонков? и что я должен знать с точки зрения подводных камней?
user1884325 22 сен. 2014, в 21:24
0

да, управляемый C ++ делает все для вас. Когда я говорю «pinvoke», я включаю это.
Peter Ritchie 22 сен. 2014, в 21:25
0

как c # относится к нативному ptr для выделенной памяти? скажем, функция ac, которая возвращает указатель на байтовый массив ..... будет ли сборщик мусора пытаться освободить байтовый массив? вероятно нет ... но каковы серьезные подводные камни, о которых я должен знать при реализации "клея" ???
user1884325 22 сен. 2014, в 21:29
0

Давайте продолжим эту дискуссию в чате .
user1884325 22 сен. 2014, в 22:49

Показать ещё 14 комментариев

Теги:

c#

c

wpf

winforms

sockets

2 ответа

Ещё вопросы

Вы подразумеваете под «сокеты»: сетевые сокеты? Может быть, вы можете использовать именованные каналы. Именованные каналы могут быть созданы на стороне C ++ и на стороне C #. На стороне C # у вас есть NamedPipeServerStream и NamedPipClientStream . Вы получаете к ним доступ через интерфейс Stream .
Это звучит почти так, как должно быть на Programmers.SE .
Почему не Windows Communication Foundation? msdn.microsoft.com/en-us/library/dd456779(v=vs.110).aspx
Просто хотел бы сказать, что издержки вызовов сокетов и сериализации, вероятно, будут намного больше, чем P / Invoke. Конечно, есть и подводные камни для P / Invoke, но есть и для сокетов.
@joel: да, вы, вероятно, правы, но трафик сообщений не будет большим объемом / частотой .... и код будет "чище"
@Blam он сказал "платформа независима".
Вы серьезно не хотите использовать сокеты для такого рода вещей. Независимость от платформы - это неправильное название, и в конце этого пути вы найдете много горя.
@peter: что может пойти не так, выставив функциональность c lib через API сервер / клиент?
Теперь у вас есть зависимость от сети, драйвера, наличия карты. Конфигурация этого сокета теперь требуется. хотя «сокеты» существуют во всех операционных системах, у вас не будет единого фрагмента кода, который будет работать на всех из них, - у вас будут разные варианты, что приведет к дополнительному обслуживанию. Если он настроен для сети, у вас будет сетевой трафик (и замедление из-за него), которого у вас не было раньше. У вас будут объекты для передачи данных и / или сопоставления формы в памяти и обратно по беспроводной сети, которой вам также придется управлять. и т.п.
@peter: так что бы вы сделали? Давайте просто примем Windows в качестве платформы для пользовательского интерфейса и C-lib
@peter: разве CLI не является рекомендуемым способом включения двунаправленных вызовов между окнами форм c # и статической C lib? я полагаю, что "клей" является C ++ CLI DLL? это позволяет для двунаправленных звонков? и что я должен знать с точки зрения подводных камней?
да, управляемый C ++ делает все для вас. Когда я говорю «pinvoke», я включаю это.
как c # относится к нативному ptr для выделенной памяти? скажем, функция ac, которая возвращает указатель на байтовый массив ..... будет ли сборщик мусора пытаться освободить байтовый массив? вероятно нет ... но каковы серьезные подводные камни, о которых я должен знать при реализации "клея" ???
Давайте продолжим эту дискуссию в чате .

Aladin Hdabe · Answer 1 · 2014-09-22T18-15-00.000Z

Пожалуйста, прочитайте эту тему, это может помочь вам решить, в какую сторону перейти Interprocess Communications

Alex Cornford · Answer 2 · 2014-09-22T16-28-00.000Z

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

вот основной пример. http://www.linuxhowtos.org/C_C++/socket.htm

Для написания кода сокета требуются совместимые форматы данных между отправляющим приложением и получающим приложением. Это означает, что вам необходимо тщательно структурировать свои сообщения и гарантировать, что каждая целая, длинная целая, плавающая, двойная и фиксированная длина строки точно совпадают. Дополнительный байт с 1 стороны будет сжимать ваше сообщение в мусор. Если ваши форматы кодирования данных c и С# не совпадают - у вас будет дополнительная работа по декодированию/форматированию.

Я предпочел использовать ONC-RPC для написания кода клиентского сервера между неравными системами. Десять лет назад я использовал RPC для подключения большой endian Solaris к маленькой системной системе VMS - она работала безупречно, это было очень быстро написать.

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