68 / 66 / 19
Регистрация: 27.12.2008
Сообщений: 212
|
|
1 | |
Универсальный обмен данными между приложениями28.05.2011, 17:54. Показов 30874. Ответов 26
Метки нет Все метки)
(
Посоветуйте, пожалуйста, подход для решения следующей штуки:
Передача данных из приложенияА (C#) в приложениеB (C#, C++, Java, остальные будет хорошо, но не обязательно), где они изменяются и передаются обратно. Данные могут быть любого объема и состоять из нескольких аргументов разных типов (например, {текст, кодировка, число}). Достаточно, чтобы передача была между приложениями на локальном компьютере, где приложениеА запускает приложениеВ. Скорость передача желательна, но не является критичной. Спасибо.
0
|
|
28.05.2011, 17:54 | |
Ответы с готовыми решениями:
26
Как организовать обмен данными между приложениями по интернету Обмен данных между приложениями
Обмен данными между устройствами |
13 / 13 / 2
Регистрация: 10.01.2010
Сообщений: 34
|
|
28.05.2011, 18:13 | 2 |
Файлы не подходят?
0
|
68 / 66 / 19
Регистрация: 27.12.2008
Сообщений: 212
|
|
28.05.2011, 18:21 [ТС] | 3 |
))) подходят, но пишу диплом, поэтому хочется чтобы было прям ах)))
К тому же, вдруг все-таки захочется через сеть работать) Вот прочел такие названия как "сокеты, Remoting, пайп-каналы, WM_COPYDATA...", не владею ни одним из этих слов, а изучить их всех - не успею, нужно выбрать что-то одно.
0
|
6277 / 3562 / 898
Регистрация: 28.10.2010
Сообщений: 5,926
|
||||||
28.05.2011, 18:48 | 4 | |||||
5
|
68 / 66 / 19
Регистрация: 27.12.2008
Сообщений: 212
|
||||||
28.05.2011, 19:32 [ТС] | 5 | |||||
Спасибо, очень забавно)))
но у меня не получилось передать таким способом многострочные данные(
0
|
-19 / 1 / 2
Регистрация: 05.11.2012
Сообщений: 48
|
|
04.01.2014, 21:06 | 6 |
0
|
447 / 305 / 47
Регистрация: 23.01.2013
Сообщений: 661
|
||||||
05.01.2014, 01:36 | 7 | |||||
Пример с использованием WM_COPYDATA.
С помощью SendDataMessage отправлять можно только структуру не содержащую ссылочные типы.
Упс, не глянул на дату первого сообщения. Ну может кому-то другому поможет.
2
|
Ушел с форума
![]() |
|
05.01.2014, 14:14 | 8 |
![]() Решение
Ну раз уж подняли старую тему...
В Windows самый эффективный механизм обмена данными между приложениями - это разделяемая память (или отображаемые в память файлы, это почти одно и то же), а также все механизмы, построенные на этой основе (pipes, например). Разделяемая память поддерживается аппаратно (отображение одной физической страницы на разные виртуальные адреса), для обмена данными не требуется ни доступ к диску/сети, ни смена задач, ни переключение в ядро, поэтому скорость максимальная. У Memory-Mapped Files есть лишь один недостаток - для обмена данными между сессиями нужно создавать объект MMF в глобальном пространстве имен, а для этого нужна привилегия SE_CREATE_GLOBAL_NAME, которая, начиная с Windows Vista, только у администраторов и служб. У именованных каналов (named pipes) такой проблемы нет, к тому же они поддерживают обмен данными по сети, работу с безопасностью (например, пайп-сервер может выполнять запрос в контексте безопасности пайп-клиента), message mode, таймауты и кое-что еще. Правда, написать хорошо работающий пайп-сервер не так просто, как кажется, но такова цена за его эффективность и функциональность. IpcChannel и NetNamedPipeBinding из WCF тоже построены на pipes, так что в .NET, вероятно, стоит использовать их. Еше один вариант - COM/RPC. Скорость здесь будет ниже на порядок, да и для тех, кто не знаком с технологией COM, написание даже простейшего клиент-сервера может быстро завести в тупик. Но это один из немногих способов работать с данными в объектном ключе (классы, свойства, методы, интерфейсы) и вызывать удаленные (в том числе на удаленных машинах) методы так, как будто они находятся в одном и том же процессе. К тому же COM поддерживается очень многими средами, это большой плюс. Про компоненты, которые пишутся на C++, а затем дергаются из JScript или .NET, или используются в Office/1C, рассказывать не буду. Если ничто из вышеперечисленного использовать нельзя (или не позволяет "религия"), тогда остаются сокеты. Но это не самое лучшее решение. В двух словах - long path. Даже простейший вызов send, recv или connect на локалхост проходит длинную цепочку вызовов, от уровня winsock вниз, через провайдеров сети, затем в ядро (AFD), потом в стек TCP, где для него создаются I/O-запросы, выполняются ожидания, доставка APC и прочее-прочее. И только пройдя этот "лабиринт" вызовов и часовых механизмов, данные попадают в ожидающее приложение. Если на компьютере установлен какой-нибудь фаервол и он настроен на фильтрацию локальных соединений (а такая опция есть у многих из них), то картина будет еще более запутанной, а путь - еще более длинным. Что касается WM_COPYDATA, то это вообще последний вариант, когда ничего другого не остается. Здесь нет гарантии доставки, нет возможности отправить данные в ответ. Для обработки нужна оконная процедура. Сами сообщения летают только в пределах одного десктопа, а на Windows Vista и выше "режутся" UAC-ом, например если их пытаются слать от обычного процесса к процессу, запущенному в контексте администратора. А если разрешить доставку (ChangeWindowMessageFilter), то всякое зловредное приложение сможет делать то же самое. В общем, это и ненадежно, и неудобно, и несекьюрно.
11
|
192 / 199 / 82
Регистрация: 11.04.2013
Сообщений: 1,086
|
|
05.01.2014, 18:37 | 9 |
про DDE забыли
0
|
447 / 305 / 47
Регистрация: 23.01.2013
Сообщений: 661
|
|
05.01.2014, 22:53 | 10 |
Убежденный, можно узнать почему при посылке сообщение WM_COPYDATA нет гарантии доставки?
0
|
Ушел с форума
![]() |
|
06.01.2014, 00:01 | 11 |
1) SendMessage не вернет управления, пока второй процесс не обработает WM_COPYDATA.
Если процесс, которому предназначено сообщение, завис, отправитель тоже будет висеть. 2) Оконное сообщение режется UAC-ом (точнее говоря, UIPI). Например, если процесс А, запущенный от обычного пользователя (standard user), посылает сообщение в процесс Б, который запущен от имени администратора. У них тогда будут разные integrity level (А - medium, Б - high), и сообщение не пройдет. Единственная "радость" - SendMessage в этом случае вернет 0, а не 1. 3) Для отправки сообщения нужен оконный хэндл. А оконные хэндлы - штука специфическая, на них не удерживается никаких референсов, не нужно делать CloseHandle, например. Может случиться, что между тем, когда хэндл целевого окна получен (FindWindow), и отправкой ему сообщения WM_COPYDATA, целевой процесс будет завершен, а его хэндл с тем же числовым значением присвоен окну какого-нибудь другого процесса.
3
|
0 / 0 / 0
Регистрация: 21.04.2015
Сообщений: 8
|
|
05.01.2017, 14:29 | 12 |
Всем привет,
очень заинтересовало особенно: не подскажите по поводу других способов реализации обмена объектами, классами и пр? преимущества/недостатки? интересуют именно те варианты которые могут работать на одной машине, не обязательно по сети.
0
|
Ушел с форума
![]() |
|
05.01.2017, 14:38 | 13 |
Если мы говорим о каких-то удобных стандартных средствах, то их просто нет.
В C++ отсутствует двоичный интерфейс (ABI), поэтому обмениваться классами и объектами не получится не то, что между разными языками, но даже между компиляторами или разными версиями одного и того же компилятора. COM/RPC решает эту проблему.
0
|
0 / 0 / 0
Регистрация: 21.04.2015
Сообщений: 8
|
|
05.01.2017, 14:51 | 14 |
другими словами без использования COM/RPC не получится реализовать такой обмен между разными процессами даже если оба приложения на .NET и работают на одной машине в рамках одной ОС?
0
|
Ушел с форума
![]() |
|
05.01.2017, 15:08 | 15 |
В .NET есть WCF, нужно смотреть в эту сторону, как мне кажется.
Я в .NET не специалист, так что подождем ответов кого-нибудь еще ![]() Добавлено через 15 секунд В .NET есть WCF, нужно смотреть в эту сторону, как мне кажется. Я в .NET не специалист, так что подождем ответов кого-нибудь еще ![]()
0
|
![]() |
|
05.01.2017, 15:26 | 16 |
Да, я тоже поддерживаю. WCF - универсальная технология, так что ее можно использовать во множестве сценариев взаимодействия.
Добавлено через 16 секунд Да, я тоже поддерживаю. WCF - универсальная технология, так что ее можно использовать во множестве сценариев взаимодействия.
0
|
![]() |
|
06.01.2017, 14:20 | 18 |
А так практически везде. И обмен идет не объектами по сути, а их состоянием. На мой взгляд, WCF на данный момент самая простая и эффективная технология, и для вашей задачи подойдет как нельзя лучше.
Кстати, сериализация - не обязательное требование. Лучше использовать контракты данных.
0
|
0 / 0 / 0
Регистрация: 21.04.2015
Сообщений: 8
|
|
06.01.2017, 15:44 | 19 |
о контрактах данных в мсдн
сервис не запустился когда я пометил класс атрибутом DataContract и создал в нем функции которые принимают/возвращают объекты классов не поддерживающих сериализацию. я склоняюсь к использованию COM. Если я не ошибаюсь, то тут сериализация для обмена вшита в саму технологию. Возни с атрибутами в коде конечно не убавиться, но зато многие из классов в .NET уже сделаны COM-видимыми. Огорчает что COM считается устаревшей технологией. К тому-же на данный момент архитектура клиент/сервис не вписывается в планируемое приложение.
0
|
![]() |
|
06.01.2017, 16:07 | 20 |
К счастью, мне это известно и без вашей ссылки.
![]() Вы просто не умеете их готовить. ![]() Ну самое простое - используйте NamedPipes. Максимальная скорость передачи, как вам и хочется.
0
|
06.01.2017, 16:07 | |
06.01.2017, 16:07 | |
Помогаю со студенческими работами здесь
20
Обмен данными между потоками Обмен данными между формами Обмен данными между процессами Обмен данными между формами Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |