Good day

I was playing with TidTelnet client and it seemed that it never detects network outage or premature disconnect. 

On inspecting the source:

{code}
procedure TIdTelnetReadThread.Run;
begin
  if FClient.IOHandler.InputBufferIsEmpty then begin
    FClient.IOHandler.CheckForDataOnSource(IdTimeoutInfinite);
  end;
  if not FClient.IOHandler.InputBufferIsEmpty then begin
    if FClient.ThreadedEvent then begin
      FClient.Negotiate;
    end else begin
      Synchronize(FClient.Negotiate);
    end;
  end;
  FClient.IOHandler.CheckForDisconnect;
end;
{code}

.... I saw the FClient.IOHandler.CheckForDataOnSource(IdTimeoutInfinite);. It seems to me that this will wait forever until data is received. If that is the case then the client will never detect premature disconnects. Am I mistaken?

The reason that I am asking is because the test app I play with does not detect premature disconnects. In the source it also seems that the read part in Negotiate is not placed in a try..except and I only know how a conventional Indy component like TidTCPClient would detect disconnects and that is to try and read or write which eventually would lead to an exception.

How does TidTelnet client do it? How would I know when it happens?

Thank you

PeaShooter_OMO wrote:

> How would that work? Let's say that I would try to implement the
> OnDisconnect/OnStatus trigerring and submit it to you?

Yes.  Then I would review it, tweak it if needed, and check it in if viable.

> Is there documentation to explain coding standards and procedures
> to follow before a patch can even be considered by you?

No.  Just submit whatever you have and I will review it.

--
Remy Lebeau (TeamB)

> Active: just me.
> 
> Semi-active: 1 or 2, as time permits.

Wow, that puts what you do even into a whole new level.

> And occasional patches from Embarcadero or end users.

How would that work? Let's say that I would try to implement the OnDisconnect/OnStatus trigerring and submit it to you? Is there documentation to explain coding standards and procedures to follow before a patch can even be considered by you?

PeaShooter_OMO wrote:

> Interesting to see some Indy11 ones in there.

Just tossing around ideas.  We don't have a definitive feature/fix list for 
Indy 11 yet.  The ones marked for 11 tend to be big/non-trivial changes that 
would not be suitable for 10.

> If I may ask; how many other active members are currently
> working on Indy?

Active: just me.

Semi-active: 1 or 2, as time permits.

And occasional patches from Embarcadero or end users.

--
Remy Lebeau (TeamB)

Interesting to see some Indy11 ones in there.

I have a deep appreciation for what you and the rest of the Indy team is doing with Indy. I usually stand in awe at the control and discipline shown handling Indy as a project. Well done to you and the guys. Thanks for a great suite.

If I may ask; how many other active members are currently working on Indy?

PeaShooter_OMO wrote:

> Can these issues be viewed in some way by the general public?

Yes, they are available on Google Code (http://code.google.com/p/indyproject/) 
and CodePlex (http://indy.codeplex.com/).

And please, don't comment on the duplication.

--
Remy Lebeau (TeamB)

> I have added it to the issue trackers.

Can these issues be viewed in some way by the general public?

> I am also busy with things outside of forums.

Absolutely.

> I don't have time to verify it, I'll just take your word for it.

Thank you.

> I have added it to the issue trackers.

Thanks again. I appreciate your input.

PeaShooter_OMO wrote:

> I know you are "freakishly" busy helping people with their network
> questions on numerous forums and web pages

I am also busy with things outside of forums.

> but is there any chance you would be willing to verify this on your side?

I don't have time to verify it, I'll just take your word for it.

> I wonder if it would be possible to have this included in a future
> "feature adjustment" for indy?

I have added it to the issue trackers.

--
Remy Lebeau (TeamB)

> > Use a packet sniffer instead, such as Wireshark.
> 
> I will try that

I tested with a packet sniffer and found that the KeepAlives actually do work correctly and because of noticing when it fires I realized that I misinterpreted the help on SetKeepAliveValues. I apologize for that.

I do still request that you consider my last request on my previous post:

> Unfortunately no event is triggered, not even OnStatus. As you would most probably know the OnDisconnect does occur when the Telnet's Disconnect is called though.
> 
> I know you are "freakishly" busy helping people with their network questions on numerous forums and web pages but is there any chance you would be willing to verify this on your side? 
> If you find that it actually is as I described then I wonder if it would be possible to have this included in a future "feature adjustment" for indy? Basically to have the OnStatus event triggered on the occasion of the TelnetThread terminating because of a network outage or premature disconnect?