Здравствуйте снова, уважаемые! Так получилось, что в моих программах сервер проявляет больше активности, отправляя различные команды клиентам. Подскажите, есть ли событие, которое генерирует IdTCPClient при получении пакетов (с текстом)? В голове одна мысль сделать таймер и в нем tcpClient.ReadLn, но это бред да и лагать будет. Возможно заменить IdTCPClient на сервер? (будут ли два сервера вообще между собой взаимодействовать?)

> есть ли событие, которое генерирует IdTCPClient при получении
> пакетов


Нет.


> сделать таймер и в нем tcpClient.ReadLn, но это бред


Эт точно)


> Возможно заменить IdTCPClient на сервер?


Невозможно.

> Салат   (06.08.07 12:58)  

используй TServerSocket / TClientSocket - они могут работать в асинхронном режиме на сообщениях - имхо для твоей задачи самое то.

> в моих программах сервер проявляет больше активности


Это вовсе не повод и не обязательное требование для задействования событийного механизма на стороне клиента.

сервер вообще не должен проявлять активности, только выполнять команды клиента. Что-то неверно в проекте :)

> umbra ©   (06.08.07 14:48) [4]


Ну эт ты явно загнул)

Сервер серверу все-таки рознь)

> сервер вообще не должен проявлять активности, только выполнять
> команды клиента. Что-то неверно в проекте :)

Нет не всегда. В качестве примера могу привести сервер входящий в большинство цифровых АТС - так называемый Call Manager. Клиенты подключаются к серверу, могут отдавать команды, получать результаты выполнения команд, но, в то же время сервер сам информирует клиентов о наступлении определенных событий, например звонках. Такое реализовано, например, у CISCO.

Есть и другие примеры, где такое поведение сервера уместно.

> информирует клиентов

но не отдает команды. Клиенты сами решают, что им делать. Я о терминологии, а не о конкретных решениях. Клиент - командует, сервер - исполняет (или не исполняет) и информирует.

На моем сервере происходит некий процесс а в клиентах отображается информация об этом процессе плюс они на него могут влиять. Вот и упирается все в то, что в Indy TCP клиенте нет событий, которые происходили бы автоматически при приеме данных. TServerSocket и TClientSocket в delphi 7 нет, вместо них есть TcpClient и TcpServer. Видимо, придется переходить на них.

>
> Вот и упирается все в то, что в Indy TCP клиенте нет событий,
>  которые происходили бы автоматически при приеме данных.
>

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

> > сделать таймер и в нем tcpClient.ReadLn, но это бред
> Эт точно)

А вообще в D7 все таки есть TClientSocket и TServerSocket, просто они не зарегистрированы. Программировать на них предельно просто и нужную функциональность обеспечивают. Я нашел свою прелесть :)

> Вот и упирается все в то, что в Indy TCP клиенте нет событий,
>  которые происходили бы автоматически при приеме данных


В большинстве случаев эти события нафих не нужны.
Твой случай скорее всего не исключение.

Я сейчас столкнулся с той же проблемой - пишу чат для локальной сети.
Думаю, что в этом случае придется создавать потоки с Readln - ом.

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


Зачем ?

Сергей М. ©   (29.01.08 12:12) [13]
Зачем ?
потому что valenok © :)
все уже создано до вас...

>  в то же время сервер сам информирует клиентов о наступлении
> определенных событий, например звонках. Такое реализовано,
>  например, у CISCO.

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

Вообще-то, сервер -- это процесс, владеющий слушающим сокетом, клиент, соответственно, -- процесс, инициировавший создание соединения.

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

Вся остальная псевдоклассификация -- от лукавого.

вы о чем тут?))как вообще делфи включить?)))

> как вообще делфи включить?


Кнопочку нажать)