Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 Jun : Re: TIDCmdTCPServer and TIDTCPClient

www.cryer.info
Managed Newsgroup Archive

Re: TIDCmdTCPServer and TIDTCPClient

Subject:Re: TIDCmdTCPServer and TIDTCPClient
Posted by:"Remy Lebeau (TeamB)" (no.spam@no.spam.com)
Date:Mon, 19 Jun 2006 23:40:04

"Roberto Colpani" <roberto.colpani@vetrariafratellicolpani.it> wrote in
message news:449790c0$1@newsgroups.borland.com...

> If I use a worker thread on the execute method I must still have
> a timer that check if something is writing to IOHandler. Than I
> must still use a timer?

No.  Just call ReadLn() in a continuous loop until the socket is
disconnected.

> On the help I have found an IOHandler.ReadLnWait function

That is not the function to use in this situation to begin with.

> I don't understand very well how this function works
> it read the IOHandler every time the FailCount reach is value?

No.  It reads the IOHandler in a loop until a non-empty line is received, or
until the loop runs the number of times specified by the FailCount.
ReadLnWait() is only used in situations where empty lines may appear in a
response where they do not belong.  Typically, this occurs from buggy
servers, so Indy uses ReadLnWait() to ignore the empty lines while waiting
for responses from commands.

> And then, on the server side how can I resolve the writeln block?

You can't get rid of the block itself.  It is just the nature of blocking
sockets.  What you can do, however, is minimize its effect on the other
connections.  There are many ways to do that.  Such as using per-connection
outbound queues, or a dedicated writing thread.  Either way, when a client
sends data that has to be copied to other connections, don't enter a global
lock that blocks all connections in the first place.


Gambit

Replies:

none

In response to:

www.cryer.info
Managed Newsgroup Archive