178 / 68 / 13
Регистрация: 22.12.2015
Сообщений: 2,648
|
|
1 | |
Пример обмена данными между приложениями с использованием .net remoting07.04.2017, 18:00. Показов 5605. Ответов 11
Метки нет (Все метки)
Всем здравствуйте.
Есть два приложения WindowsForms одно посылает в порт массив байт определённой структуры по UDP-протоколу, другое (на другом сетевом компьютере) принимает из порта этот массив байт (разумеется используя UDP-протокол и тот же порт), "расшифровывает" его и выводит данные на экран. Услышал, что для этой задачи можно использовать .net remoting. Встретившиеся мне примеры, к сожалению, приведены только для консолей и в них одно приложение запускается из другого. Примера обмена данными между двумя абсолютно независимыми и запускаемыми (останавливаемыми) в разное время приложениями Windows Forms не нашёл. Возможно я чего-то не понял и .net remoting существует не для моей задачи?
0
|
07.04.2017, 18:00 | |
Ответы с готовыми решениями:
11
Пример обмена данными между приложениями с использованием WCF Реализация обмена данными между серверным и клиентским приложениями Обмен данными между приложениями Обмен данными между приложениями |
07.04.2017, 22:13 | 2 |
jkrnd,
1) remoting это устаревшая технология. Она и раньше не особо использовалась, а сейчас и подавно. Вместо нее сейчас - WCF. 2) remoting это гораздо более высокоуровневая технолгия чем UDP/TCP. И совсем непонятно зачем вам она для "обмена данными". Тем более, если ваше приложение уже работает, то непонятно какую задачу remoting вам решит. 3) remoting работает как в консоли так и в winforms. И вообще это не зависит от типа приложения.
1
|
178 / 68 / 13
Регистрация: 22.12.2015
Сообщений: 2,648
|
|
09.04.2017, 07:01 [ТС] | 3 |
пример для двух WindowsForm Application можно
в дальнейшем использовать для решения задачи современный подход.
0
|
09.04.2017, 10:49 | 4 | |||||||||||||||
Сообщение было отмечено jkrnd как решение
Решение
Сначала создаем контракт. Это интерфейс, методы которого может выполнять сервер:
Далее, создаем отдельное winforms приложение с сервером: Кликните здесь для просмотра всего текста
Класс ServiceImplementation реализует контракт IService, и по сути является классом, который будет обрабатывать запросы клиентов. В ServiceImplementation реализовано событие HelloReceived, которое срабатывает тогда, когда клиент присылает строку через метод Hello. Это событие нужно для того, что бы мы могли автоматически обновить интерфейс приложения, когда поступит новый запрос от клиента. И наконец сам клиент также оформляем в виде отдельного winforms приложения: Кликните здесь для просмотра всего текста
Здесь создается сервис типа IService, методы которого вы просто вызываете как у обычного объекта. Однако в реальности, эти методы будут выполняться на сервере. Клиент и сервер сконфигурированы для работы на одном компьютере. Разумеется, если сервер работает на другом хосте, то вместо localhost нужно указывать адрес сервера.
1
|
178 / 68 / 13
Регистрация: 22.12.2015
Сообщений: 2,648
|
|
09.04.2017, 11:22 [ТС] | 5 |
Storm23, спасибо. Я надеюсь возможен вариант: один клиент (раздаёт массив байтов всем кто подписан на контракт) и несколько серверов (принимающих эти байты по контракту), причём как клиенты так и серверы могут свободно запускаться и останавливаться, то есть никаких особых операций, посылки запросов на соединение и прочее не нужно?
0
|
178 / 68 / 13
Регистрация: 22.12.2015
Сообщений: 2,648
|
|
09.04.2017, 16:35 [ТС] | 8 |
не воспользоваться таким предложением не могу
Есть локальная сеть. На одном из компьютеров (источнике данных для других компьютеров) происходит считывание текущей даты (DateTime, 8 байт). (Реально на нём происходит опрос контроллера и заполняется структура в виде теущей даты и массива float-величин) . Задача на другом компьютере сети (или localhost) принимать эти байты и отображать на форме своего приложения в метке в виде отформатированной даты (обязательно включая секунды чтобы увидеть ход процесса). Обмен данными в таймере 1-2 раза в секунду не реже. Принимающих данные программ может быть несколько. Они могут находится на одном и том же компьютере, произвольно запускаться, выгружаться. При остановке программы источника данных не должно быть "вылетов" принимающих данные программ. Не по теме: Совсем недавно это реализовывалось мною через запись-чтение в двоичный файл определённой структуры (с 1996 года!). В прошлом году я познакомился с .NET и с помощью форумчан перевёл всё это на UDP-обмен. Всё отлично работает, но есть и ограничения. Например, запуская несколько серверов (читающих из порта) на одном компьютере приходится менять порты обмена. Ну и вообще, хотелось бы использовать передовые технологии.
0
|
Storm23
|
09.04.2017, 17:12
#9
|
0
|
09.04.2017, 17:15 | 10 |
jkrnd, тогда архитектура примерна такая.
Основной компьютер - это хост службы с поддержкой контрактов обратного вызова. Каждый из клиентов при запуске коннектится с хостом и подписывается на его обратные вызовы. Хост по команде может начинать и останавливать передачу, и все клиенты, кто в данный момент присоединен к хосту, получают от него данные и отображают у себя. Последний пункт вашего требования можно реализовать через периодический опрос хоста на ответ. Это один вариант. Вариант 2. Тот же хост, но без обратных вызовов. Хост просто читает данные и хранит их. Клиенты периодически опрашивают хост (по таймеру) и получают данные. Последний пункт реализуется через систему автообнаружения WS Discovery (то есть, если хост не в сети, то и запрос не производится). Какой из вариантов вас больше устраивает?
1
|
178 / 68 / 13
Регистрация: 22.12.2015
Сообщений: 2,648
|
|
10.04.2017, 14:36 [ТС] | 11 |
insite2012, Вариант 2
0
|
10.04.2017, 16:46 | 12 |
1
|
10.04.2017, 16:46 | |
10.04.2017, 16:46 | |
Помогаю со студенческими работами здесь
12
Обмен данными между приложениями по Wi-Fi Технология обмен данными между приложениями Универсальный обмен данными между приложениями Обмен данными между двумя приложениями Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |