🚀 go-pugleaf

"Dennis Jones" <nospam@nospam.com> wrote in message
news:45b9274f@newsgroups.borland.com...

> When I try to establish a connection with a server, IdTCPClient's
Connected
> property returns true almost immediately upon calling the Connect()
method

If Connect() exits without throwing an exception, Connected() is
guaranteed to return true until you perform a read/write operation.
Remote disconects on a blocking socket be only be detected after a
read/write operation has been performed.

> and stays true until the call times out (if the server is
unavailable).

You can't call Connected() while Connect() is still running.  The
state of the connection is not stable until Connect() exits.

> It seems to me that the Connected property should not return true
> until a connection is properly established.

It doesn't.  Part of Connected()'s internal logic is that is reads any
pending data from the socket (to see if the OS reports whether the
socket was disconnected by the server), and then returns whether the
socket is currently allocated.  In the case of Indy 10, Connected()
also returns true if there is unread data in the connection's
InputBuffer.

Besides, you shouldn't be calling Connected() until Connect() exits
anyway.  Why are you doing that?

> How can I determine the *true* state of the client?

Stop calling methods out of order.


Gambit

"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 

"Dennis Jones" <nospam@nospam.com> wrote in message 
news:45b9274f@newsgroups.borland.com...

> How can I determine the *true* state of the client?

Found my own answer.

- Dennis 

"Dennis Jones" <nospam@nospam.com> wrote in message
news:45b95649$1@newsgroups.borland.com...

> Remy, must you always ask *why* someone is doing something?

Yes.  Because it gets people thinking about what they are trying to
do.  Many times, they are taking the wrong approach with something, or
doing something wrong that they shouldn't be doing.  Case in point -
you.  You should not be calling Connected() while Connect() is still
running.  Nothing should be trying to access the connection in any way
while Connect() is still running.  Indy is not designed for that
particular operation.

> Can't you just answer the question without questioning the motive
behind it?

No. Because the motives tend to be incorrect more times than not.  And
besides, knowing what the motivation is behind something offers better
chances at providing alternative suggestions that the person may not
have even considered yet.

> Since it is apparently not obvious why someone would want to do
> what I am doing

The fact you are trying to call Connected() while Connect() is still
running tells me right away that you are misusing Indy in a way that
it was not designed for.  If you don't want to learn the proper way to
use it, then that is your choice.  Other people may not know how to
use it correctly, which is why they get into trouble and not
understand when something doesn't work correctly.  Hense the desire to
know what they are trying to do so they can be pointed in the right
direction.

> consider how you would indicate the current state of a volatile
connection.

There is no way to determine the current state while the socket is
still in a volatile condition - hense the term volatile, meaning
"unstable, unsettled" according to the dictionary.  So in your own
code, you would set a flag or a UI display or whatever to "connecting"
before actually calling Connect(), and then wait for Connect() to exit
before doing anything else with the connection.  That is the true
state of the connection anyway, and there is no way to query that
state once the connection attempt begins running, as it can change at
any moment.  You have to wait until Connect() either fully succeeds or
fully fails.  There is no in-between.

> When the connection is up, you want to indicate a "Connected"
status;
> when it is not, you want to indicate a "Not connected" status.

Which is exactly what Connected() does - EXCEPT when Connect() is
still running because the state is not known at the moment Connected()
is called.

> It should be obvious that it would be ridiculous to indicate
"Connected"
> during those few moments when it is trying to establish a connection

If you read the documentation for Connected(), it says exactly under
which conditions Connected() returns True.  Those conditions are met
while the socket is in the process of establishing a connection.  If
you don't like it, then don't call Connected() while Connect() is
running.

> 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.

That thread has no business querying the connection until after
Connect() has been called and exited one way or the other.  During
that time, the connection state is unstable, so of course the result
of Connected() will be questionable during that time.

> To force queries of the Connected property to occur only after a
> Connect()/Disconnect() call have completed is just plain silly

No, it is not silly.  And I did not say that Connected() could not be
called before Connect() or after Disconnect().  Only that it can't be
called DURING Connect().

> not to mention that it would require unnecessary synchronization and
> coupling between the threads.

A large part of multi-threaded programming is about synchronizing the
threads to each other.  The OS sync objects are very light-weight and
efficient in that matter.  Just because you may not like doing it does
not make it wrong.  You always have to synchronize access to shared
resources to ensure there state across thread boundaries.  That is
proper programing practice when threads are involved.

> Who is to say that I am calling them out of order?

I am.  Knowing Indy inside and out like I do, I know exactly how and
when Connect() and Connected() work.  Connected() is not reliable
while Connect() is still running, because the socket state is not
settled yet.

> The Connected property should *not* be dependent on *when* it is
called.

Yes, it should.  There are a lot of things going on inside of Indy's
internals.  Connected() is dependant on a number of internal object
states.  Those states are subject to change while Connect() is
running.

> If it is, then it should be documented that way -- but it is not.

Yes, it is.

> When the connection has been properly established, then AND
> ONLY THEN, should Connected be true.  Any other behavior is wrong.

If you don't like it, then you are welcome to join the Indy team and
change it to your liking.  Indy is open-source, afterall.


Gambit

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:45b97154$1@newsgroups.borland.com...
>

> There is no way to determine the current state while the socket is
> still in a volatile condition

For someone who is supposed to know Indy so well, you seem to have missed 
the obvious solution to my query - the OnStaus event provides exactly what I 
want.


>> When the connection is up, you want to indicate a "Connected"
> status;
>> when it is not, you want to indicate a "Not connected" status.
>
> Which is exactly what Connected() does - EXCEPT when Connect() is
> still running because the state is not known at the moment Connected()
> is called.

If the state is not known, then why does 'Connected' change from false to 
true while it is trying to connect?


>> It should be obvious that it would be ridiculous to indicate
> "Connected"
>> during those few moments when it is trying to establish a connection
>
> If you read the documentation for Connected(), it says exactly under
> which conditions Connected() returns True.  Those conditions are met
> while the socket is in the process of establishing a connection.  If
> you don't like it, then don't call Connected() while Connect() is
> running.

Quote from the Indy online help for the Connected property:

"Connected is a Boolean function used to indicate when the connection to the 
peer is open and active."

I fail to see anything that even remotely suggests that it returns true when 
it is in the process of establishing a connection.


> That thread has no business querying the connection until after
> Connect() has been called and exited one way or the other.  During
> that time, the connection state is unstable, so of course the result
> of Connected() will be questionable during that time.

So you've said.  I disagree.


>> Who is to say that I am calling them out of order?
>
> I am.  Knowing Indy inside and out like I do,

Then why are you so bent on belittling me instead of pointing me in the 
direction of OnStatus?

Get off your high-horse, Remy.  A little humility would serve you well.

- Dennis 

"Dennis Jones" <nospam@nospam.com> wrote in message
news:45b9882b$1@newsgroups.borland.com...

> If the state is not known, then why does 'Connected' change from
false
> to true while it is trying to connect?

I already answered that earlier - the documentation explains exactly
what causes Connected() to return True.

> I fail to see anything that even remotely suggests that it returns
> true when it is in the process of establishing a connection.

Then you did not read it very carefully:

    TIdTCPConection.Connected()

    "Connected returns True when the connection contains a valid
IOHandler with a bound socket handle for the connection, and the
connection has not been closed unexpectedly."

In this case, "bound socket handle" does not mean "connected socket".
It means "allocated socket", as returned by the API socket() function.
TIdTPConnection.Connected() internally calls TIdIOHandler.Connected(),
which is a virtual method that involves all three of the following
methods (in this order):

    TIdIOHandlerStack.Connected()

        "Connected() calls the inherited method to retrieve the return
value for the function. The return value for the function is True when
the InputBuffer contains exisiting data, or when ClosedGracefully is
False and the InputBuffer is assigned."

    TIdIOHandlerSocket.Connected()

        "The return value for the method is determined by the values
provided by BindingAllocated() and the inherited Connected() method."

    TIdIOHandler.Connected():

        "The return value for the function is True when the
InputBuffer contains exisiting data, or when ClosedGracefully is False
and the InputBuffer is assigned."

Nothing in that says the connection has to actually be established.
Only that the socket has to be allocated and not considered
disconnected.


Gambit

"Dennis Jones" <nospam@nospam.com> wrote in message
news:45b9882b$1@newsgroups.borland.com...

> For someone who is supposed to know Indy so well, you seem to
> have missed the obvious solution to my query - the OnStaus event
> provides exactly what I want.

Connected() was never designed for what you were attempting anyway -
continuous polling from a separate thread.  If you have a workaround
that suits you, then so be it.  Have fun.


Gambit

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:45b999a5$1@newsgroups.borland.com...
>
> Then you did not read it very carefully:

No, I read it fine.  I apparently do not have the same documentation you do.

Here's the full quote from TIdTCPConnection.Connected:

"Connected is a Boolean function used to indicate when the connection to the 
peer is open and active. Connected calls CheckForDisconnect to to determine 
if the connection was closed normally or abruptly terminated, and returns 
true when the IOHandler indicates that it is Connected."


Further, my documentation makes no mention of TIdIOHandlerStack whatsoever 
and the description for TIdIOHandlerSocket.Connected says:

"Connected is an overriden Boolean function in TIdIOHandlerSocket that 
implements the method used to determine when the physical connection for the 
handler has been established, and is available for input/output operations.

Connected will indicate when the socket handle in Binding has been assigned 
and allocated."

According to that description, "is available for input/ouput operations" and 
"when the socket handle in Binding has been assigned and allocated" both 
suggests (as I read it) that Connected should return false unless the 
connection has been fully established (bound) and I can send/receive data.

I don't know what documentation you have, but it sure doesn't match what I 
have.  Are you reading Indy10 docs?

- Dennis 

"Dennis Jones" <nospam@nospam.com> wrote in message
news:45b9a652$1@newsgroups.borland.com...

> I apparently do not have the same documentation you do.

I quoted from the online documentation at Indy's website.

> According to that description, "is available for input/ouput
operations" and
> "when the socket handle in Binding has been assigned and allocated"
both
> suggests (as I read it) that Connected should return false unless
the
> connection has been fully established (bound) and I can send/receive
data.

The second part has nothing to do with whether the connection is
established.  A "bound" socket is not an "established" socket.
Binding, in this case, means the socket has been allocated in memory
and is bound (the API bind() function) to a local network adapter.

> Are you reading Indy10 docs?

Yes.  Those the basic logic of how Connected() works is the same in
Indy 9 as well.


Gambit

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:45ba4470$1@newsgroups.borland.com...
>
> The second part has nothing to do with whether the connection is
> established.  A "bound" socket is not an "established" socket.
> Binding, in this case, means the socket has been allocated in memory
> and is bound (the API bind() function) to a local network adapter.

Okay, but you must admit that the first part certainly implies that the 
connection is stable by the time Connected is true.

- Dennis