Events у idTCPServer

← →
ManGorn (2003-07-07 09:48) [0]

OnConnect и OnDisconnect - это понятно, но вот когда происходят:

OnAfterCommandHandler
OnBeforeCommandHandler
OnException
OnExecute
OnListenException
OnNoCommandHandler
OnStatus ?

(заранее спасибо за ответ)

← →
Digitman (2003-07-07 10:25) [1]

исходники-то есть ! разве трудно посмотреть, в какой последовательности и при каких условиях возбуждаются события ?

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

← →
ManGorn (2003-07-08 13:00) [2]

Дятел, я не то спрашивал.

← →
Digitman (2003-07-08 17:29) [3]

> ManGorn

Ты хам, сударь !

← →
ManGorn (2003-07-11 14:00) [4]

2Digitman Извините, не хотел вас обитеть, но данный способ мне не подходит :(

← →
Digitman (2003-07-11 14:15) [5]

> ManGorn

> данный способ мне не подходит

почему ? разве это трудно ? за неимением детального описания компонента ? но при наличии исходников ? и хэлпа ? пусть даже и малоинформативного ?

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

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

OnBeforeCommandHandler
OnExecute
OnAfterCommandHandler

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

OnListenException должно стоять в особом ряду - к транспорту оно отношения не имеет.

← →
Shade (2003-07-11 14:53) [6]

OnExecute выполняется периодически между OnConnect и OnDisconnect
то есть тут и делаеш в принципе всю обработку данных от клиента...
есть еще OnCommandHandler
OnAfterCommandHandler
OnBeforeCommandHandler
OnNoCommandHandler

в Indy уже есть "как бы протокол обмена данными" :-)
У клиента есть метод(ы) SendCmd(...)...
Соответственно на каждую команду у сервера есть CommandHandler то есть обработчик этой комманды (его нужно создать на сервере с помощью свойства CommandHandlers)
Соответственно, если обработчик команды не зарегестрирован произойдет событие OnNoCommandHandler

Кста,OnExecute произойдет помоему только если не используешь CommandHandlers

OnException
При любом необрабатываемом исключении в вышеописаных событиях...
OnListenException
При исключении в "слушающем потоке"

OnStatus ?
Всякая фигня типа сообщений о состоянии подключения ("Connect","Resolving Host","Disconnect")

2 Digitman ©
А с чего такая принципиальность в "неиспользовании" Indy?
Очень даже неплохие компоненты...
Я понимаю что ты и сам можешь сделать лучше ручками - но зачем изобретать велосипед?

← →
Digitman (2003-07-11 15:14) [7]

> Shade

зачем мне нужно тратить время на детальное (не поверхностное !!) изучение другого продукта, если базовый продукт я знаю как облупленный ?
- гибкость базового продукта в силу его простоты дает мне возможность контролировать транспорт от и до, так как мне надо в конкретных, порой нестандартных задачах;
- базовый продукт изучен вдоль и поперек - никаких неожиданностей я от него не жду; надежность и прозрачность - прежде всего

← →
Shade (2003-07-11 15:20) [8]

2 Digitman © (11.07.03 15:14)
Ну в принципе согласен...

А базовый продукт - это что ? ServerSocket/ClientSocket? или bind()/send()/recive()?

Для меня родным и базовым стал Indy...:-)

← →
Polevi (2003-07-11 16:22) [9]

лучше когда базовым продуктом является Winsock API, IMHO

← →
Digitman (2003-07-11 16:53) [10]

> Shade

TServerSocket/TClientSocket

прозрачны до мыслимого предела)
крути-верти их как хочешь, настраивай-перестраивай - все позволяют без особых хлопот !

> Polevi

О ! Це верно) ... Но уж больно много писать приходится кода)

То ли дело - переопределил нужные классы в составе, перекрыл нужные методы - и готова совершенно оригинальная версия !! С минимумом геморроя)

← →
Polevi (2003-07-11 17:32) [11]

2Digitman © (11.07.03 16:53)

в TServerSocket/TClientSocket нет многих вкусностей WinSock2, к сожелению

← →
Digitman (2003-07-11 17:39) [12]

> Polevi

а какие проблемы их добавить ? imho, никаких)

первое, что я когда-то сделал - заменил accept() на WSAAccept(), получив замечательную "вкусность" : true-conditional acceptance.

и ввел посему новое событие OnAcceptRequest(), в обработчике которого - как это говорят - можно действительно "забанить юзера"

уверяю, гораздо проще было переписать пару субклассов и перекрыть несколько методов, нежели лепить "с нуля" свои классы !

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

← →
ManGorn (2003-07-14 13:34) [13]

Гы... а теперь скажу я :) Для тех кто плохо видит - см.выше. Я
юзаю Delphi 7.0, и кто не помнит в нём больше нету TServerSocket
и TClientSocket. Отсюда приходится изобретать велосипед и
переходить на другие компоненты, подобные TIdTCPServer. Нет,
можно конечно и WinSock2 юзать, но нафига с ним париться?

← →
Tiny (2003-07-14 13:46) [14]

2Polevi © (11.07.03 16:22)
лучше когда базовым продуктом является Winsock API, IMHO

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

2Digitman © (11.07.03 17:39)

то же самое я могу сказать и про Indy...
хотя может просто я не занимался сетью углубленно как раз до появления Indy...
(а переход с TServerSocket/TClientSocket на Indy - как минимум небольшой шок :-) типа - где читать то??! куда писать?? а еще и документация только платная??)

2ManGorn (14.07.03 13:34)
Для тех кто плохо видит - см.выше. Во-во! Я вроде ответил на твой вопрос :-)

← →
$hade (2003-07-14 13:49) [15]

Тьфу,б№;, прошлый пост от меня был :-)

← →
Digitman (2003-07-14 13:50) [16]

Я не пользую D7 , но сдается мне, что пэкедж с этими компонентами так же как и в D6 просто убран с палитры по умолчанию и может быть в любой момент подключен из каталога %DELPHI%\Lib

← →
$hade (2003-07-14 13:54) [17]

Digitman © (14.07.03 13:50)
Воистину так! :-)

← →
Digitman (2003-07-14 13:59) [18]

> $hade

Тогда и мы все вместе с полным правом и удовольствием можем поГЫкать над самоуверенным заявлением ManGorn (14.07.03 13:34)

> Гы... а теперь скажу я :) Для тех кто плохо видит - см.выше. Я
>
> юзаю Delphi 7.0, и кто не помнит в нём больше нету TServerSocket
> и TClientSocket

← →
Polevi (2003-07-14 14:28) [19]

2Digitman © (11.07.03 17:39)
>и точно так же и избавляемся в этих классах при необходимости
>от механизма оконной нотификации по-умолчанию в пользу
>событийной.

это если использовать send, recv.. а вот WSASend, WSARecv с использованием ф-ии завершения overlapped ввода вывода - слишком много придется менять, imho, проще написать свою обертку

← →
Digitman (2003-07-14 14:37) [20]

> Polevi

да я не спорю)... но overlapped-нотификация, в принципе, сравнима по производительности с event-нотификацией.

← →
ManGorn (2003-07-18 09:52) [21]

Как в D7 доставить компоненты TClientSocket и TServerSocket???

← →
Digitman (2003-07-18 10:09) [22]

ну как ? обычным образом !

IDE-Меню "Component | Install packages ..", выбираешь из %DELPHI%\Lib BPL-модуль, хранящий эти компоненты (как он там обзывается - я не в курсе, спроси у других D7-юзеров), - и вот они уже у тебя в палитре !)

← →
ManGorn (2003-07-19 08:38) [23]

Не-а, не катит!

← →
Anatoly Podgoretsky (2003-07-19 09:33) [24]

Все катит, только научись устанавливать компоненты и научись пользоваться блокнотом для чтения readme файлов.

← →
ManGorn (2003-07-27 15:44) [25]

Туфта! :)

Events у idTCPServer Найти похожие ветки