Вопрос

У меня есть классическая программа клиент/сервер (толстый клиент и база данных), написанная на Delphi 2006.Когда в клиенте выполняются определенные условия, мне нужно очень быстро уведомить всех остальных клиентов.До сих пор это делалось с использованием широковещательной рассылки UDP, но это больше нецелесообразно, поскольку теперь клиенты подключаются из-за пределов локальной сети, а широковещательная рассылка UDP ограничивается локальной сетью.

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

Есть ли какие-либо другие наборы компонентов или технологии, на которые мне следует обратить внимание вместо этого?

Это было полезно?

Решение

Простой ответ заключается в том, что стандартные протоколы, доступные в Delphi (и других инструментах), не допускают обратного уведомления.Я рассмотрел это для проекта, в котором хотел использовать SOAP.Все они предполагают, что клиент запрашивает сервер, сервер отвечает и все.

Для меня решением стал RemObjects SDK.Это позволяет вам отправлять уведомления клиентам, и уведомление может содержать любые данные, которые вам нравятся (точно так же, как клиент-сервер).Сам использую соединение SuperTCP, но и с другими оно работает.Он по-прежнему может предлагать интерфейс SOAP для клиентов, которые должны его использовать, но там, где вы контролируете и клиент, и сервер, он работает очень хорошо.

Другие советы

Есть несколько действительно простых способов сделать это с помощью Delphi, хотя я уверен, что RemObjects SDK тоже работает очень хорошо.

  1. Имейте центральный сервер, на котором * прослушивает * TIdTCPServer*.Тогда у каждого клиента есть TIdTCPClient в теме.Они подключаются к серверу и блокировать чтение ожидающий для сервер для записи.Как только сервер получает уведомление через прослушивающий сокет, он передачи каждому из ожидающих клиентов.Это практически немедленное уведомление всех клиентов.
  2. Иметь центральный сервер с TIdTCPServer прослушиваетг на это.Тогда у каждого клиента есть TIdTCPClient в теме.Эти клиенты могут "пинг" сервер будет регулярно запрашивать обновления (используйте токен сеанса для поддержания состояния).Частота интервала определяет, насколько быстро будет отправлено уведомление.Когда одному из клиентов необходимо уведомить остальных, он просто уведомляет об этом сервер.Затем сервер использует очередь сообщений составить список всех активных клиентских сессий и добавить уведомление для каждой.Затем в следующий раз, когда каждый из клиентов подключается, он отправляет ему уведомление и удаляет его из очереди.
  3. Поддерживать таблица сеансов в базе данных, где каждый клиент регулярно обновляет информацию об активном сеансе и удаляется при отключении.Вам понадобится процесс обслуживания, который удаляет мертвые сеансы.Тогда у вас есть таблица очереди сообщений в который клиент может записать обновление с одной строкой для каждого текущего активного сеанса.Тогда другие клиенты смогут регулярно пинговать эту таблицу, чтобы узнать, есть ли какие-либо ожидающие уведомления для ее сеанса; если они есть, они могут их прочитать, обработать их, а затем удалить.
  4. Что-то подобное пиринговый подход, при котором клиенты узнают друг о друге через информацию в базе данных, а затем подключаются напрямую друг к другу и уведомляют или запрашивают уведомления (в зависимости от конфигураций брандмауэра и NAT).Немного сложнее, но возможно.

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

Для этого вам понадобятся следующие компоненты: TIdTCPServer (слушатель) и TIdTCPClient (отправитель).Оба из них находятся в библиотеках Indy в Delphi.

Компоненты АСУ ТП от http://www.overbyte.be отлично.а.) Лучшая совместимость, чем Indy B.) Открытка. Пособия. Хорошие примеры и поддержка.Используйте TClientSocket и TServerSocket.

Проект FirebirdSQL использует концепцию уведомлений как соединений сервер-клиент, которые отправляют строку клиенту.Для этого сервер БД использует другой порт.И потребовать от клиента регистрации, что интересно получать уведомления определенного типа через вызов API.

Вы можете использовать ту же идею.

RabbitMQ должен соответствовать вашим требованиям.Сервер бесплатен и готов к использованию.Вам просто нужна клиентская сторона для подключения, отправки/отправки сообщения и получения/извлечения уведомления.

Сервер: http://www.rabbitmq.com/download.htmlДелайте гугл для клиента или реализуйте сами

Ваше здоровье

Вы должны иметь возможность использовать Multicast UDP для той же цели.Единственная разница будет заключаться в присоединении к группе многоадресной рассылки от каждого клиента.

http://en.wikipedia.org/wiki/IP_Multicast

http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol

Редактировать: Просто чтобы уточнить, многоадресная рассылка позволяет вам присоединиться к определенной «группе», связанной с IP-адресом многоадресной рассылки.Любой пакет, отправленный на этот адрес, достигнет каждого клиента, присоединившегося к группе.

Вы можете посмотреть компонент weonlydo wodVPN, который позволяет вам создать надежную UDP-дырку и получить переадресацию портов или обычный VPN (со стандартным сетевым адаптером), чтобы вы могли подключить два компьютера за NAT.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top