Article View: borland.public.cppbuilder.internet.socket
Article #1473Re: IdTCPClient Connected question
From: Dennis Jones
Date: Fri, 26 Jan 2007 01:16
Date: Fri, 26 Jan 2007 01:16
51 lines
3532 bytes
3532 bytes
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:45b938e2$1@newsgroups.borland.com...
> Besides, you shouldn't be calling Connected() until Connect() exits
> anyway.
Who says? Is that documented somewhere?
> Why are you doing that?
Remy, must you always ask *why* someone is doing something? Can't you just
answer the question without questioning the motive behind it? Not only is
it annoying and occasionally rude, but it is also very condescending toward
the person who is asking the question; and in point of fact, is largely
irrelevant much of the time. If you must know the answer before you can
give the person an appropriatate answer, then please try to phrase your
question so that it does not imply that the person is an idiot.
Since it is apparently not obvious why someone would want to do what I am
doing, consider how you would indicate the current state of a volatile
connection. When the connection is up, you want to indicate a "Connected"
status; when it is not, you want to indicate a "Not connected" status. It
should be obvious that it would be ridiculous to indicate "Connected" during
those few moments when it is trying to establish a connection and then
change back to "Not connected" after it fails ("Connecting" would be more
appropriate). The same is true for IdTCPClient, but requirements and
expectations for a library like Indy are much stronger and more explicit --
so to state that it is connected when it is not is just plain wrong.
In my case, the state of the connection is queried in a thread that is
separate from that which is actually attempting to establish the connection.
To force queries of the Connected property to occur only after a
Connect()/Disconnect() call have completed is just plain silly -- not to
mention that it would require unnecessary synchronization and coupling
between the threads.
>> How can I determine the *true* state of the client?
>
> Stop calling methods out of order.
Who is to say that I am calling them out of order? The Connected property
should *not* be dependent on *when* it is called. If it is, then it should
be documented that way -- but it is not. If a connection has not been
properly established, then Connected should be false -- it's that simple.
When the connection has been properly established, then AND ONLY THEN,
should Connected be true. Any other behavior is wrong.
- Dennis
Technical Details
Message-ID:
<45b95649$1@newsgroups.borland.com>Path:
arc1-ca.pugleaf.net!g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.albasani.net!feeder06.uucp-net.de!reader.uucp.at!feeder02.uucp.at!feeder08.uucp.at!news.uucp.at!newsgroups.borland.com!not-for-mailReferences:
<45b9274f@newsgroups.borland.com> <45b938e2$1@newsgroups.borland.com>Show Full Headers
Complete Article Headers
X-Google-Thread: 11508e,e8cbc2087e955870 X-Google-Attributes: gid11508e,public X-Google-Language: ENGLISH,ASCII-7-bit From: "Dennis Jones" <nospam@nospam.com> Newsgroups: borland.public.cppbuilder.internet.socket References: <45b9274f@newsgroups.borland.com> <45b938e2$1@newsgroups.borland.com> Subject: Re: IdTCPClient Connected question Date: Thu, 25 Jan 2007 17:16:41 -0800 Lines: 53 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-RFC2646: Format=Flowed; Original NNTP-Posting-Host: 71.245.109.58 Message-ID: <45b95649$1@newsgroups.borland.com> X-Trace: newsgroups.borland.com 1169774153 71.245.109.58 (25 Jan 2007 17:15:53 -0800) Path: arc1-ca.pugleaf.net!g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.albasani.net!feeder06.uucp-net.de!reader.uucp.at!feeder02.uucp.at!feeder08.uucp.at!news.uucp.at!newsgroups.borland.com!not-for-mail