Обмен данными между двумя приложениями на ПК в локальной сети

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

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

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

7
database delphi lan sockets

10 ответов

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

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

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

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

11

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

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

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

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

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

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

-Al.

4

Я использовал Mailslots, если мне нужно было общаться с более чем одним ПК за раз ("трансляция") по сети, хотя есть оговорка, что mailslots не гарантированы.

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

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

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

3

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

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

  • использование SQL server
  • гнездо связи
3

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

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

1

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

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

1

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

1

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

0

возможность может быть "поделиться" объектами по сети.

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

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

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

0

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

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

0