Рассылка сообщения всем хостам

← →
Elen © (2007-08-16 10:41) [0]

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

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

unit Unit2; interface uses IdSocketHandle, Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, IdBaseComponent, IdComponent, IdUDPBase, IdUDPServer; type TForm2 = class(TForm) IdUDPServer1: TIdUDPServer; procedure IdUDPServer1UDPRead(Sender: TObject; AData: TStream; ABinding: TIdSocketHandle); private { Private declarations } public { Public declarations } end; var Form2: TForm2; implementation {$R *.dfm} procedure TForm2.IdUDPServer1UDPRead(Sender: TObject; AData: TStream; ABinding: TIdSocketHandle); var s:string; begin s:=IdUDPServer1.ReceiveString; caption:=s; if s="q" then begin IdUDPServer1.Active:=false; close; end; end; end.

Подскажите пожалуйста как правильно работать с Broadcast сообщениями в Indy UDP

И вообще правильным ли я путем иду чтоб решить такую задачу?

Заранее спасибо.

← →
Сергей М. © (2007-08-16 10:45) [1]

> правильным ли я путем иду чтоб решить такую задачу?

Для начала ты должна осознать, что UDP не подразумевает гарантии доставки пакетов.

← →
Сергей М. © (2007-08-16 10:54) [2]

А раз не подразумевает, то это усложняет задачу - придется реализовывать квитирование доставки :

- клиент посылает пакет и ждет некоторое время от сервера ответный пакет, подтверждающий доставку;

- при превышении таймаута ожидания этой "квитанции" клиент посылает повторный пакет, если сч-к повторов не превышен

← →
Elen © (2007-08-16 10:58) [3]

> Сергей М. © (16.08.07 10:54) [2]

Дык в том то и проблема что нужен броадкаст, но и негарантированность доставки не радует.

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

← →
Сергей М. © (2007-08-16 11:00) [4]

UDP-бродкасту есть альтернатива - TCP-мультикаст, но он не всегда поддерживается тем или иным Winsock-провайдером.

TCP гарантирует доставку, но его использование для этих целей в рамках гомогенной ЛВС вряд ли оправдано - этот протокол ощутимо "тяжелей" чем UDP.

Одна из разумных альтернатив - использование именованых программных каналов (Named Pipes), хотя и здесь есть ограничение, связанное с отсутствием поддержки серверной логики системами на платформе Win9x/Me

← →
Elen © (2007-08-16 11:02) [5]

> Сергей М. © (16.08.07 11:00) [4]

А где об ТСР-мультикасте можно узнать подробненько? И заодно про Named Pipes?

← →
Сергей М. © (2007-08-16 11:10) [6]

> где об ТСР-мультикасте можно узнать подробненько?

А нужен ли он в твоем случае ?

Если хостов в ЛВС не так уж и много, можно воспользоваться обычным "комплектом" из компонентов, реализующих классический TCP-сервер и TCP-клиент. Многоадресная рассылка в этом случае реализуется программно, что вовсе не сложно.

> про Named Pipes?
>

В справке, в MSDN

ключ.слово для поиска - CreateNamedPipe, ConnectNamedPipe, TransactNamedPipe

← →
Elen © (2007-08-16 11:16) [7]

> Многоадресная рассылка в этом случае реализуется программно,
> что вовсе не сложно.

Например как?

← →
Сергей М. © (2007-08-16 11:19) [8]

В цикле по некоему списку имен или адресов хостов

← →
Сергей М. © (2007-08-16 11:26) [9]

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

← →
Elen © (2007-08-16 12:14) [10]

> Сергей М. © (16.08.07 11:26) [9]

Ну вот придется список составлять... Ну тоже вариант.

Ну это компы в одном домене. Имена абсолютно разные. даже не знаю что еще сказать...

← →
Сергей М. © (2007-08-16 12:23) [11]

> придется список составлять

Зачем его составлять ?
Он сам "составится")

Можно реализовать такую схему:

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

Стартующее приложение C первым делом осуществляет коннект к серверу в приложении S, в рез-те чего кл.гнездо автоматически заносится в список Connections[] серверного компонента.

При необходимости прил-е S в цикле по всем эл-там этого списка рассылает всем подключенным на этот момент клиентам нужную команду.

← →
Сергей М. © (2007-08-16 12:31) [12]

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

В msdn есть пример пайп-клиента и пайп-сервера в разных их "ипостасях".

Существуют и готовые дельфийские компоненты для пайп-взаимодействия.

В этом Форуме так же есть статья про пайпы с при примерами.

← →
Elen © (2007-08-16 12:42) [13]

> Стартующее приложение C первым делом осуществляет коннект
> к серверу в приложении S

Но S не запушенно. Я его буду запускать в отдельных случаях. чтож получается нужно чтоб приложения клиенты с некоторым интервалом пытались установить коннект?
Есть мыслишка - сначала я пытаюсь связаться через UDP с клиетами. Как только клиент отвечает дальше уже связь всю передаю через TCP.

> S не запушенно

Что мешает все время держать его "запущенным" ?

> Elen ©

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

> Что мешает все время держать его "запущенным" ?

Отсутствие смысла. Ладно я пожалуй попробую разные варианты. Спасибо, ребята. Буду копать дальше.

> Elen ©

Я как то сталкивался с подобной задачей. Пришлось написать даже свой сервер и свой клиент на асинхронных сокетах на сообщениях. Клиенты постоянно держат связь с сервером, восстанавливая коннект при его потере. Сервер шлет так называемы евенты клиентам и принимает от клиентов команды. На команды он отвечает. Все получилось довольно надежно.

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

> Elen © (16.08.07 12:53) [16]
>
>

> Отсутствие смысла

Да ладно !?)

А в лишних телодвижениях в виде старта и стопа приложения S (всякий раз когда его функциональность нужна под рукой немедленно) смысл, конечно, же сомнению не подлежит ?

Ну запусти ты S как службу - нехай она тихо и не привлекая к себе внимания "пасет" нажатие тобой какого-либо хоткея и немедленно, без пыли и шума "закругляет" неугодные тебе процессы, будь они хоть на Луне. Разве нет в этом смысла ?)

> Ну запусти ты S как службу - нехай она тихо и не привлекая
> к себе внимания "пасет" нажатие тобой какого-либо хоткея
> и немедленно, без пыли и шума "закругляет" неугодные тебе
> процессы, будь они хоть на Луне. Разве нет в этом смысла
> ?)

Тоже вариант.

Рассылка сообщения всем хостам Найти похожие ветки