Board index » delphi » Lost Connection

2003-12-09 01:03:27 AM
delphi143
I'm using the TIdTCPServer component for a custom telnet server, and before
writing a response out to the client, I want to check the connection to make
sure it is still an active connection. But the Connected property isn't
accurate when I check.
if (ASender.Thread.Connection.Connected) then
begin
ASender.Thread.Connection.WriteLn(sResponse);
QRouterLog(ClientLog(ASender.Thread), 'Response Sent: ' + sLineBreak +
sLineBreak + sResponse , AppSettings);
end else
QRouterLog(ClientLog(ASender.Thread), 'Unable to send response,
connection may be dead', AppSettings);
I've tried calling the CheckIfConnected method, but it is still not update
accurately. I know in fact the connection is lost or broken because in
testing, I issue my command then close the telnet widnow immediately. So
the Connected property should be false, and ytet it is not.
So how do I check that it is indeed an active and valid connection before
trying to write out my response?
 

"JSheble" <XXXX@XXXXX.COM>writes
graceful by the client. It will not be able to detect premature
disconnects, at least not for awhile. TCP is designed to keep sockets
"alive" under such conditions. They will remain "active" until an internal
timeout eventually occurs inside the socket stack itself. Until then, Indy
has no way of knowing whether the socket is valid or not,
will just have to wait until the socket is invalidated by the stack and
operations start failing eventually.
Gambit
 

It was an inherited application, and the developer originally used the
TIdTCPServer component.
What advantages, if any, would I have to switch it? Or prehaps rewrite the
app using the TIdTelnetServer component?
"Remy Lebeau (TeamB)" <XXXX@XXXXX.COM>writes

So if I am reading this correctly, there's nothing I can do to detect if the
client has dropped their connection at all? Would the TIdTelnetServer
component allow me to detect if the client dropped the connection? The
reason I ask, is this is actually more of a messaging server, and I am using
a telnet interface so that it is easy to test and use from a manual point of
view using a telnet connection and parmeterized commands. They pass me an
XML structure, I parse it, ship it through a shipping engine, build a
response XML, and send it back. But in reality, it is another application
that is connecting to this thing and using it. From time to time, they're
dropping their connection ungracefully, but I am still sending out a
response. So it looks as if responses are getting lost. If I could tell
the connection is no longer there, then I can log the response instead, and
we can then audit or track from there.
"Remy Lebeau (TeamB)" <XXXX@XXXXX.COM>writes

Get the client to thank the server i.e. respond to the response. It
you don't get a response to the response then log it, try again what
ever you require is one way the other if your comms is effectively
point to point is a heart beat messsage write an integer out to the
client. it adds one to it and sends it back. No or incorrect response,
kill the server side socket which after writing an appropriate event
handler will cause the client to re-open communications with a new
one.
 

"JSheble" <XXXX@XXXXX.COM>writes
such as the network going down unexpectedly, then the disconnect is not
detected right away. That is a "feature" of TCP itself, not Indy
specifically. The socket stack is designed to persist active connections
for a period of time during outages, in case the network comes back up in a
timely fashion and the stack can reestablish the same connection internally.
Small network outages are common, especially over the Internet. Most of the
time, you won't even notice the outages, and neither will Indy.
As long as both sides of the connection actively close down the socket
connection gracefully, meaning they both call Disconnect() and such, then
yes, Indy (and the socket stack) will detect the disconnect immediately. It
is the "premature" disconnects that are not detected right away, because the
socket stack itself is keeping the socket "alive" for an extra period of
time. Eventually, if the connection cannot be reestablished, then the
socket stack will timeout and invalidate the socket, at which point Indy
will start detecting errors. But that may not happen for about a minute at
least (or possibly longer).
specifically. This effects all TCP-based servers in general.
doesn't know that the socket is truely gone for awhile.
gracefully, then there is no problem. But if you do have to deal with
premature disconnects as well, then the most reliable way to shorten the
timeout is to simply require the client to send the server "keepalive"
packets every so often, to let the server know that the client is still
active. If the server does not receive a packet in a timely fashion, then
just assume the client is gone and shut down the socket.
Gambit
 

"JSheble" <XXXX@XXXXX.COM>wrote in news:3fd5fd66$1
@newsgroups.borland.com:
section on this as well as demos in Indy in Depth.
www.atozed.com/indy/
Qualified help FAST with Indy Experts Support
from the experts themselves:
www.atozed.com/indy/experts/support.html
ELKNews - Get your free copy at www.atozedsoftware.com
 

Speaking of Indy In Depth, is it still being published and updated?
Not heard a word.
Chad Z. Hower aka Kudzu writes:

MrT <XXXX@XXXXX.COM>wrote in news:XXXX@XXXXX.COM:
smal updates have been uploaded over the past 2 months, and many are in the
works now.
Want to keep up to date with Indy?
Join Indy News - it free!
www.atozed.com/indy/news/
ELKNews - Get your free copy at www.atozedsoftware.com
 

Hi:
I thought you sent out notices by e-mail to those of us who purchased
Indy In Depth
I remember getting at least one???
Chad Z. Hower aka Kudzu writes:

MrT <XXXX@XXXXX.COM>wrote in news:XXXX@XXXXX.COM:
email notifications and it will probably be online and working in a week or
two.
Want more Indy stuff? Try the Atozed Indy Portal at
www.atozedsoftware.com/
* More Free Demos
* Free Articles
* Extra Support
ELKNews - Get your free copy at www.atozedsoftware.com
 

Hi:
I went there and coulc not log in. I then supplied info to get userid
and pass sent by email I got it and tried to login again. Again failed.
Subscription still valid.
I am loooking for info on EIdSocketClosed.
Chad Z. Hower aka Kudzu writes:

MrT <XXXX@XXXXX.COM>wrote in news:XXXX@XXXXX.COM:
Got Indy? Got the book?
www.atozed.com/indy/book/
 

Hi.
I'm using IBX, Delphi 7.
I'm tying to close application when I have lost connection with server.
<code>
procedure TformMain.FormCreate(Sender: TObject);
begin
Application.OnException := AppException;
[...]
end;
procedure TformLogowanie.AppException(Sender: TObject; E: Exception);
var
IBErrorCode: Integer;
begin
if E is EIBInterBaseError then
begin
IBErrorCode := (E as EIBInterbaseError).IBErrorCode;
if IBErrorCode = 335544721 then
begin
with DM do
Application.MessageBox('Lost connection!', 'Error',
mb_IconError);
DM.IBdatabase.ForceClose;
DM.IBdatabase.CloseDataSets;
Application.Terminate;
end;
end;
end;
</code>
The problem is that When I close application I have "Dataset open" error.
What I am doing wrong?
Sorry for my english.
--
Krzysztof
 

On Jun 27, 4:07 pm, "Shaolin" <XXXX@XXXXX.COM>writes:
good luck