Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 Apr : Re: TIdTCPServer - threads, global data contd.

www.cryer.info
Managed Newsgroup Archive

Re: TIdTCPServer - threads, global data contd.

Subject:Re: TIdTCPServer - threads, global data contd.
Posted by:"Stephen Odgaard" (s..@cowi.dk)
Date:Mon, 17 Apr 2006 22:18:23

"Martin James" <mjames_falcon@dial.pipex.com> wrote in message
news:4443f51e$1@newsgroups.borland.com...
>
> "Stephen Odgaard" <sso@cowi.dk> wrote in message
> news:4443f201@newsgroups.borland.com...
>> Thanks Martin,
>>
>> I think I have a plan figured out by now. I have to dig one step further
>> into the OnExecute infinite look.
>> My current implementation of the .Execute is a ReadLn and a WriteLn.
>> I can see there is a "IdTimeOutDefault = -1" defining that the "Default
>> Timeout" should be used for ReadLn, but not what it is. Where can I see
>> this?
>> (I can see that the ReadLn(ATerminator, ATimeout, AMaxLineLength) could
>> be
>> used, to assure this is under control.)
>> For WriteLn there seem not to be any timeout defined.
>>
>> So basically the wait (or sleep) in a Execute thread containing a ReadLn
> and
>> WriteLn thread is basically this mystical "Default Timeout" value...
>>
>
> AFAIK, the default *read* timeout is INFINITE, (defined in windows unit as
> 'DWORD($FFFFFFFF)', ie. -1).
>
> There is no write timeout, so it is effectively INFINITE also, or at
> least,
> it is as far as Indy goes.  Write calls that get stuck because the client
> has gone away are eventually timed out by the TCP timers in Winsock.
> These
> timers have *long* intervals to accommodate all types of fast, slow,
> high-latency, low-latency links.  This a big problem for those designs of
> 'chat' app that rely on directly calling the write methods of all the
> peerThreads/contexts of all clients in the global list, especially those
> that keep the global list locked for the whole iteration.
>
> Rgds,
> Martin
>
Ok, intersting and it makes sense...
Generally with a live connection a WriteLn will exit almost instantly i
guess, thereby making the RealLn the governing item timewise.
So basically a much simper way to check for outgoing data would be to do a
readln with a timeout of say NN ms. This NN will be specified for the
various clients, which are not all as time critical. 50 ms should be
sufficient for the time critical and at the same time not use too much
CPU...

/SSO


/SSO

Replies:

none

In response to:

www.cryer.info
Managed Newsgroup Archive