TIdHTTP - асинхронный запрос

← →
Maacheba (2009-02-11 19:45) [0]

А можно с помощью TIdHTTP сделать асинхронный POST запрос?
Если вызывать метод Post - то он блокируется до возврата ответа.

Если такое нельзя - кто как посоветует проще, чтобы не особо разбираться, сделать POST-запрос к удаленному серверу?

Программа не VCL, работает в качестве сервиса.

← →
Ega23 © (2009-02-11 19:48) [1]

> Если вызывать метод Post - то он блокируется до возврата
> ответа.

Естественно. Ты что-то серверу послал - значит должен что-то получить. Либо умереть по таймауту.

← →
Anatoly Podgoretsky © (2009-02-11 20:01) [2]

> Maacheba (11.02.2009 19:45:00) [0]

Переходи на ICS
Инди синхронные компоненты.

← →
Сергей М. © (2009-02-11 20:12) [3]

> Программа не VCL, работает в качестве сервиса

Чем блокирующий режим мешает работе сервиса ?

← →
Maacheba (2009-02-12 12:30) [4]

> Естественно. Ты что-то серверу послал - значит должен что-
> то получить. Либо умереть по таймауту

я даже не знаю как комментировать, Олег. Что нужно ожидать ответа - естественно, но почему из этого следует, что ответа надо ожидать в заблокированном состоянии - я не понимаю, что тут естественного.

> Чем блокирующий режим мешает работе сервиса ?

а вот вам не все равно, проблема то озвучена в сабже.

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

← →
Сергей М. © (2009-02-12 12:48) [5]

> тем, что поток зависает, и если в это время сервис останавливают
> - он не успевает за отведенное время выгрузиться

Используй таймайт ожидания ввода-вывода - и будет счастье)

← →
Maacheba (2009-02-12 13:19) [6]

> Используй таймайт ожидания ввода-вывода - и будет счастье)

и какой же таймаут вы посоветуете мне использовать?

Во-первых, я не нашел где в Indy задается таймаут у idHTTP.

Во-вторых, это костыль, а не решение. Чем меньше таймаут - тем быстрее может выгрузиться сервис. Чем больше таймаут - тем выше шанс успешной связи с сервером по плохому каналу.

Ничем жертвовать я не хочу, если можно сделать по-другому.

← →
Dimka Maslov © (2009-02-12 13:26) [7]

"Асинхронно" значит в "отдельном потоке"

← →
Maacheba (2009-02-12 13:39) [8]

> "Асинхронно" значит в "отдельном потоке"

да ты полиглот.

← →
Сергей М. © (2009-02-12 13:51) [9]

> какой же таймаут вы посоветуете мне использовать?

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

> я не нашел где в Indy задается таймаут у idHTTP

Так ты не под тем фонарем искал - см. TIdTCPClient.ReadTimeout

> Чем меньше таймаут - тем быстрее может выгрузиться сервис

Да.

> Чем больше таймаут - тем выше шанс успешной связи с сервером
> по плохому каналу

Таймаут не влияет ни на какие шансы, кроме как на шанс безусловно и гарантированно вернуться из блок.вызова в указанное время.

> Ничем жертвовать я не хочу, если можно сделать по-другому

Ну и делай, что ж мешает ?)

Ты когда на Инди делал ставку, чего ж сразу не изучил его особенности ?
Почему не сравнил компонентные продукты в этой категории на прежмет реализуемых режимов ?

Тоже мне костылененавистник нашелся)

← →
Сергей М. © (2009-02-12 13:53) [10]

> Maacheba

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

← →
Сергей М. © (2009-02-12 14:05) [11]

> Maacheba (12.02.09 13:39) [8]
>
>
> > "Асинхронно" значит в "отдельном потоке"
>
> да ты полиглот.

Тебе дело советуют, а ты рогом уперся)
Не хочешь костыль ? Выноси синхронный блокирующий запрос в отдельный поток - это самое простое и очевидно что можно предложить в твоей печальной ситуации)

← →
Maacheba (2009-02-12 15:58) [12]

> Ну, очевидно, заведомо меньший того времени, которое SCM
> отводит сервису на то чтобы он закруглился по команде останова.
>

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

> Так ты не под тем фонарем искал - см. TIdTCPClient.ReadTimeout

и каким образом настройкой TIdTCPClient.ReadTimeout мне повлиять на поведение TidHTTP?

> > Чем меньше таймаут - тем быстрее может выгрузиться сервис

> Да.

это в общем-то был не вопрос.

> Таймаут не влияет ни на какие шансы, кроме как на шанс безусловно
> и гарантированно вернуться из блок.вызова в указанное время.

серьезно что ли? А вы никогда не видели загруженный апач, особенно под прослойкой nginx"а? Он запрос в очередь и на 20 секунд может ставить, а потом еще время на выполнение скриптов, например.

Так что поставите вы таймаут в 30 секунд - получите нужный ответ. Поставите таймаут в 5 секунд - не получите ничего. Именно это вы называете "Таймаут не влияет ни на какие шансы" ?

> Ты когда на Инди делал ставку, чего ж сразу не изучил его
> особенности ?

а тендер не нужно было провести на поставку компонента?
Никаких ставок я не делал, нужно было сделать POST-запрос, посмотрел что есть встроенного в дельфи, оказался TIdHTTP, использовал его, натолкнулся на этот косячок, задал вопрос.

Задал вопрос, о котором давно все забыли. Как сделать запрос POST в инди асинхронно. Если это нельзя - то как сделать его без indy с наименьшими трудозатратами, желательно (добавлю) без установки различных наборов компонент.

Сергей М. некомпетентен, чтобы помочь в решении этого вопроса. Но готов всю свою энергию направить на то, чтобы ответом на вопрос "как сделать асинхронный запрос" стало "сделай синхронный запрос".

← →
Maacheba (2009-02-12 16:07) [13]

> Тебе дело советуют, а ты рогом уперся)

какое дело? Отсылка POST и так идет в отдельном потоке, фигли толку? "Основной" поток все равно дожидается окончания работы всех рабочих потоков, и если хоть один завис - то и "основной" зависнет. Так что как это решает проблему - непонятно. TerminateThread даже и не предлагайте.

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

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

"автор нихрена не знает программирование", "программа спроектирована неправильно" и коронное "на самом деле автору нужно не то, что он хочет. А то, что хочет автор - знаю только я".

> Maacheba

Так, все, свободен.
LMD

← →
Maacheba (2009-02-12 16:16) [15]

Я не просто ламер, я агрессивный ламер. Надо писать: ALMD

← →
Maacheba (2009-02-12 16:54) [16]

ну что, никто не подскажет? Так не хочется на TCP-сокетах вручную писать...

Читай сюда, агрессивный ты наш:

http://www.sockets.com/winsock.htm#SetBlockingHook
http://www.sockets.com/winsock.htm#UnhookBlockingHook
http://www.sockets.com/winsock.htm#CancelBlockingCall

Это к вопросу о документированном корректном прерывании блокирущих WS-вызовов.

> Так не хочется на TCP-сокетах вручную писать

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

← →
Maacheba (2009-02-13 11:56) [18]

Удалено модератором
Примечание: Down

TIdHTTP - асинхронный запрос Найти похожие ветки