Angus Robertson - Magenta Systems Ltd wrote:
I'm writing simple console downloader and decided to use sync
operations in order to simplify structure. But I've found that
sync requests (HttpCli) do not use any timeout, so they may last
forever in case of error.
That's IMHO a bug.
Indeed,
But most components do have a timeout for sync methods, for
instance TSyncSmtpCli and TFtpClient.
Yes they have, but do they work properly when a send or receive
lasts longer then the timeout value?
I fixed the timeout in TSyncSmtpCli eight years ago, one of the first
changes I made to
Arno Garrels wrote:
Please guys, take a look at this fix for V7 and test it, anything
wrong with it?
Just noticed that it still lacks a timeout status.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Arno Garrels wrote
TWSocketCounter has been added to TWSocket in V7 with properties
ConnectTick, ConnectDT, LastAliveTick, LastRecvTick and LastSendTick.
Yes, I'm using it in my FTP class, but Start/StopTimer seem easier in my case
SZ wrote:
I think Arno and Francois is right about not making a
Anton Sviridov wrote:
Arno Garrels wrote
Please guys, take a look at this fix for V7 and test it, anything
wrong with it?
It works, but I think Abort isn'tt a very good way to tell that there
was timeout...
Abort on timeout is commonly used in ICS.
and 404 even stranger. 404 means
Any alternates (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes)?
It's not a constant error AFAIK. IMO 408 was more confusing.
Yeah, that's why transport level stuff should be done in transport (socket)
classes :) We would have OnConnect(Request)Timeout or something like and no
mess
Anton Sviridov wrote:
Any alternates
(http://en.wikipedia.org/wiki/List_of_HTTP_status_codes)? It's not a
constant error AFAIK. IMO 408 was more confusing.
Yeah, that's why transport level stuff should be done in transport
(socket) classes :) We would have OnConnect(Request)Timeout or
Connect-timeouts are not the only possible ones.
Yes, I know, but connect ones are the most general and used by everyone,
because w/o connection there's nothing to do anyway.
If you need different timeout values for different states it has to be
implemented using a timer. We need to keep the
Anton Sviridov wrote:
Connect-timeouts are not the only possible ones.
Yes, I know, but connect ones are the most general and used by
everyone, because w/o connection there's nothing to do anyway.
If you need different timeout values for different states it has to
be implemented using a
Hello!
I'm writing simple console downloader and decided to use sync operations in
order to simplify structure. But I've found that sync requests (HttpCli) do not
use any timeout, so they may last forever in case of error. My question is: how
can I add timeouts without messageloops and threads
how can I add timeouts without messageloops and threads and so on?
I see that there is still ControlSocket.MesagePump in SyncRequest, so I suppose
creating timer will work, won't it?
--
Anton
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
how can I add timeouts without messageloops and threads and so on?
You need a messageloop to make ICS component work anyway.
Every GUI application has a messageloop.
If you build a console mode application, you have to create one yourself.
See various console mode ICS démos. Simple...
--
And second question, more global: Isn't it worth to add good and native
timeout functionality to TWSocket so that thousands of developers
hadn't invent a bicycle again and again? I know about TIcsTimer
and so on, but it is not 'out of the box'.
This is underway. but designing a general
If you build a console mode application, you have to create one yourself.
See various console mode ICS d?mos. Simple...
Yes, I created TIcsTimer with HttpCli.CtrlSocket as Owner and implemented
Start/StopTimer methods. Seems working, although I don't see yet how can I
control the main function
Anton Sviridov wrote:
If you build a console mode application, you have to create one
yourself. See various console mode ICS d?mos. Simple...
Yes, I created TIcsTimer with HttpCli.CtrlSocket as Owner and
implemented Start/StopTimer methods. Seems working, although I don't
see yet how can I
I think Arno and Francois is right about not making a TTimer per Thttpcli as
default. It would overwhelm our reverse proxy with 10k connections each with
two sockets. However for simple needs, Anton is right about asking for a
solution which I think sould only be switched on by a define.
Just my
Anton Sviridov wrote:
Hello!
I'm writing simple console downloader and decided to use sync
operations in order to simplify structure. But I've found that sync
requests (HttpCli) do not use any timeout, so they may last forever
in case of error.
That's IMHO a bug.
--
Arno Garrels
--
To
I'm writing simple console downloader and decided to use sync
operations in order to simplify structure. But I've found that
sync requests (HttpCli) do not use any timeout, so they may last
forever in case of error.
That's IMHO a bug.
Indeed, poor implementation in THttpCli with no
18 matches
Mail list logo
