Обмен данными между двумя приложениями через ПК в локальной сети - PullRequest
7 голосов
/ 10 августа 2009

Мне нужно реализовать два приложения, которые будут обмениваться данными друг с другом. Оба приложения будут работать на отдельных ПК, которые являются частью локальной сети.

Как мы можем сделать это в Delphi?

Существует ли какой-либо бесплатный компонент, который облегчит обмен данными между приложениями на ПК?

Ответы [ 10 ]

11 голосов
/ 10 августа 2009

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

Это небольшой вес, он хорошо работает на одном компьютере, в локальной сети или в Интернете без изменений, и позволяет общаться между приложениями с различными разрешениями, такими как службы (сообщения Windows вызывают проблемы здесь).

Возможно, это не является обязательным требованием для вас, но я также являюсь поклонником платформно-независимых транспортов, таких как TCP / IP.

Существует множество бесплатных вариантов для Delphi. Вот некоторые из них, которые я знаю. Если вам нравится блокировать библиотеки, посмотрите на Indy или Synapse . Если вы предпочитаете неблокирование, проверьте ICS .

4 голосов
/ 10 августа 2009

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

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

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

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

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

После того, как вы ответите на эти вопросы, вы можете начать спрашивать о лучших технологиях для вашей конкретной ситуации.

-Аль.

3 голосов
/ 11 августа 2009

DCOM был хорошим методом межпроцессного взаимодействия. Это было также одной из сильных сторон Delphis. Сегодня я бы настоятельно советовал не использовать его.

В зависимости от характера вашего проекта я бы выбрал либо

  • с использованием сервера SQL
  • сокет связи
3 голосов
/ 10 августа 2009

Раньше я использовал почтовые слоты, если мне нужно было общаться одновременно с несколькими ПК («широковещательно») по сети, хотя есть предостережение, что почтовые слоты не гарантируются.

Для 1-к-1 именованные каналы - это способ Windows для такого рода действий: вы в основном открываете канал связи между двумя ПК, а затем записываете сообщения в канал. Не просто для начала, но очень надежный и рекомендуемый способ для таких вещей, как службы Windows.

MS предлагает именованные каналы в качестве альтернативного способа связи с SQL Server (кроме TCP / IP).

Но, как сказал Брюс, TCP / IP является стандартным и независимым от платформы и очень надежным.

1 голос
/ 11 августа 2009

Я много раз использовал компоненты Multicast библиотеки Indy (IdIPMCastClient / Server) для этого типа вещей. Приложения просто отправляют друг другу XML. Быстро и просто с минимальными требованиями к соединению.

1 голос
/ 10 августа 2009

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

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

1 голос
/ 10 августа 2009

Посмотрите на решения, использующие интерфейсы типа «Удаленный вызов процедур». Я использую RemObjects SDK для такого рода вещей, но есть версии с открытым исходным кодом RealThinClient , которые будут работать так же хорошо.

Оба этих параметра позволяют вам создать соединение, которое для большей части вашего кода является "прозрачным", и вы просто вызываете интерфейс, который отправляет данные по проводам и возвращает результаты. Затем вы можете запрограммировать, как обычно, и забыть детали сокетов и т. Д.

0 голосов
/ 11 ноября 2011

Возможна возможность «обмениваться» объектами по сети.

Это возможно с клиент-серверным ORM, таким как наш маленький mORMot .

Эти библиотеки с открытым исходным кодом работают от Delphi 6 до XE2 и используют JSON для передачи. Включены некоторые функции безопасности (включая механизм аутентификации RESTful ), и они могут использовать любую базу данных или вообще не использовать базу данных.

См., В частности, первые четыре предоставленных образца и соответствующую документацию.

0 голосов
/ 11 августа 2009

Для интеграции приложений Delphi может быть выбрано промежуточное ПО, ориентированное на сообщения . Брокеры сообщений предлагают гарантированную доставку, балансировку нагрузки, различные модели коммуникации, и они работают на разных платформах и на разных языках. Брокеры сообщений с открытым исходным кодом включают в себя:

(Отказ от ответственности - я являюсь автором клиентских библиотек Delphi / Free Pascal для этих серверов)

0 голосов
/ 10 августа 2009

Вероятно, самый простой способ - это прочитать и записать файл (или, возможно, один файл в каждом направлении). Он также имеет то преимущество, что его легко моделировать и отслеживать. Хотя это не самый быстрый вариант (и он определенно звучит неубедительно ;-)).

...