Обменивайтесь Данными между двумя приложениями через ПК на LAN
mspdbsrv.exe является использованием Visual Studio процесса для создания .pdb файлов, когда Вы компилируете; это файлы символов, которые позволяют Вам отладить приложение. Иногда это приходит в бешенство и не завершает работу правильно при выходе из Visual Studio. У меня была эта причина, плохо компилирует даже после выхода и перезапуска Visual Studio. Используйте Проводник Процесса или список задач (Ctrl+Alt+Delete в Windows) для ручного уничтожения mspdbsrv.exe, если это повреждается на Вас.
Если это имеет значение, я не видел, что эта проблема происходит в Visual Studio 2008 на данный момент, но я только использовал его несколько дней.
9 ответов
Если я пишу это сам, я (почти) всегда использую сокеты для обмена данными между приложениями.
Это небольшой вес, он хорошо работает на одном компьютере, в локальной сети или в Интернете без изменений и позволяет взаимодействовать между приложениями с разными разрешениями, такими как службы (сообщения Windows вызывают здесь проблемы).
Возможно, это не требование для вас, но я также поклонник независимого от платформы транспорта, такого как TCP / IP.
Для Delphi есть много бесплатных вариантов. Вот некоторые из них, о которых я знаю. Если вам нравится блокировать библиотеки, посмотрите Indy или Synapse . Если вы предпочитаете неблокирующий режим, посетите ICS .
Перед тем, как выбрать метод, вы должны охарактеризовать обмен данными в соответствии с его пропускной способностью, детализацией, задержкой и критичностью.
Пропускная способность - сколько данных в единицу времени вам нужно будет переместить ? Диапазон возможных значений настолько широк, что приложения с самой низкой и самой высокой скоростью почти не имеют ничего общего.
Гранулярность - насколько велики сообщения? Сколько данных требуется принимающему приложению, чтобы оно могло использовать сообщение?
Задержка - когда одно приложение отправляет сообщение, как скоро это должно увидеть другое приложение? Насколько быстро вы хотите, чтобы принимающее приложение реагировало на отправляющее приложение?
Критичность - как долго полученное сообщение может оставаться без внимания, прежде чем оно будет переполнено более поздним сообщением? (Обычно это не важно, если пропускная способность не высока, а хранилище сообщений ограничено.)
После того, как вы ответите на эти вопросы, вы можете начать спрашивать о лучшей технологии для вашей конкретной ситуации.
-Al.
DCOM раньше был хорошим методом межпроцессного взаимодействия. Это также было одной из сильных сторон Delphis. Сегодня я бы настоятельно рекомендовал не использовать его.
В зависимости от характера вашего проекта я бы выбрал
- с использованием соединения сокетов SQL-сервера
Раньше я использовал почтовые ящики, если мне нужно было общаться с более чем одним ПК одновременно («широковещательная рассылка») по сети, хотя есть оговорка, что почтовые ящики не гарантируются.
Для 1-к-1 именованные каналы - это способ сортировки Windows, вы в основном открываете канал связи между двумя компьютерами, а затем записываете сообщения в канал. Непросто начать, но очень надежный и рекомендуемый способ для таких вещей, как службы Windows.
MS предлагает именованные каналы в качестве альтернативного способа связи с SQL-сервером (кроме TCP / IP).
Но, как сказал Брюс, TCP / IP является стандартным, независимым от платформы и очень надежным.
Посмотрите решения, использующие интерфейсы типа «Удаленный вызов процедур». Я использую RemObjects SDK для такого рода вещей, но есть версии RealThinClient с открытым исходным кодом, которые также подойдут.
Оба они позволяют создать соединение, которое для большей части вашего кода является «прозрачным», и вы просто вызываете интерфейс, который отправляет данные по сети и возвращает результаты. Затем вы можете программировать, как обычно, и забыть детали сокетов и т. Д.
Это один из тех случаев, когда на самом деле нет "лучшего" ответа, поскольку практически любая из уже обсужденных технологий может использоваться для точного взаимодействия между двумя приложениями. Выбор того, какой метод использовать, действительно сводится к критическому характеру вашего общения, а также к тому, сколько данных должно быть передано с одной рабочей станции на другую.
Если ваше общение не зависит от времени или критично, тогда простой регулярного опроса базы данных или файла может быть достаточно. Если ваше общение критично и зависит от времени, возможно, стоит попробовать разместить TCPIP-сервер на каждом клиенте. Если только чувствительно ко времени, то почтовые ящики - хороший выбор, если критично, но не чувствительно ко времени, то именованные каналы.
Я много раз использовал компоненты многоадресной рассылки библиотеки Indy (IdIPMCastClient / Server) для этого типа вещей. Приложения просто отправляют друг другу XML. Быстро и легко с минимальными требованиями к подключению.
Вероятно, самый простой способ - это прочитать и записать файл (или, возможно, один файл для каждого направления). Он также имеет то преимущество, что его легко моделировать и отслеживать. Однако это не самый быстрый вариант (и это определенно звучит неубедительно ;-)).
Для интеграции приложений Delphi можно использовать промежуточное ПО, ориентированное на сообщения . Брокеры сообщений предлагают гарантированную доставку, балансировку нагрузки, различные модели коммуникации, работают как на разных платформах, так и на разных языках. Брокеры сообщений с открытым исходным кодом включают:
(отказ от ответственности - я являюсь автором Delphi / Бесплатные клиентские библиотеки Pascal для этих серверов)