Сетевое программирование Delphi

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

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

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

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

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

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

Компоненты ICS от http://www.overbyte.be великолепны. a.) Лучшая совместимость, чем Indy b.) PostCard ware Хорошие примеры и поддержка. Используйте TClientSocket и TServerSocket

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

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

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

Сервер: http://www.rabbitmq.com/download.html Google для клиента или реализовать себя

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

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

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

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

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

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

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