I am using TClientSocket and TServerSocket to comunicate with a server the problem is that sometimes connection is lost either by the server issuing me the following exceptions : Error on WsaSend, acess violation etc or by the Client : Asychronious socket error.
Witch is the best method to recover from these errors and keep the connection open no mather what ?
There is no such thing as "keeping the connection open no matter what". What if the cable gets cut? The best you can do is to send a heartbeat on some interval to let intermediate routers know you are still interested in using that connection, and to carefully handle all errors, and, if necessary, re-establish the connection.
Great question... what you're receiving is WSAECONNABORTED (Asynchronous Socket Error 10053).
How did i prevent it from happening in MY code ? well, there's something called Keepalive, if you look carefully into the name, Keep-Alive, it meant to keep the connection alive, just send Null data to the connection (Can be One-way), that's all...
i made a Timer (named it TmrKeepAlive) and set its interval to 5000ms (5 seconds), More info on KeepAlive.
Edit: Also, if you don't want to write your own KeepAlive mechanism, check this out
Related
I use a TIdFTP control to connect to an FTP server. It seems that my FTP connection is terminated by something (ftp server/firewall?) after 60 seconds of inactivity. Once the connection was terminated I cannot use the FTP control (TIdFTP) anymore because its status is undefined. For example, every time I try to REconnect I get the same (10038) error. However, FTP.Connected shows True. Trying FTP.Disconnect gives me a 'connection closed gracefully' error and the control remains connected. The only solution is to end the program and start it again.
The NAT Keep Alive is already set to 15000.
How to reset the status of the FTP control (how do I disconnect)?
I use a TIdFTP control to connect to an FTP server. It seems that my FTP connection is terminated by something (ftp server/firewall?) after 60 seconds of inactivity
TIdFTP has a NATKeepAlive property to avoid that exact issue from happening when connected through an FTP-unaware router/firewall. During a transfer, TCP keepalives are temporarily enabled on the control connection so it does not get closed prematurely.
However, FTP.Connected shows True.
That means the IOHandler.InputBuffer likely has unread data in it. Connected() is designed to return True if read operations can still be satisfied even if the socket has been closed.
Trying FTP.Disconnect gives me a 'connection closed gracefully' error
By default, Disconnect() sends a QUIT command to the server before closing the socket. Since the connection is already gone, that send fails.
Disconnect() has an optional ANotifyPeer parameter that you can set to False to skip the QUIT command.
You should also Clear() the IOHandler.InputBuffer after an unexpected disconnect to clear out any unread data.
The only solution is to end the program and start it again.
That is never the solution. Worse case, you could simply destroy the TIdFTP object and create a new one. But if you follow the steps above, you should not need to resort to even that.
You cannot keep TIdFTP open. The connection will be closed from server side for every timed out time.
As you use this component to fetch or put file to file server for a time interval, You can connect just before using the TIDFTP, and disconnect it after the usage. Then you do not need to bother about freeing the component and connection failures.
I have a server application which runs on a Linux machine. I can connect this application from Windows/Linux machines and can send/recieve data. After a few hours, something occurs and I get following error on the client side.
On Windows: An existing connection was forcibly closed by the remote host
On Linux: Connection timed out
I have made a search on the web and found some posts which suggest to increase/decrease OS's keep alive time. However, it didin't work for me.
Can I found a soultion to this problem or should I simply try to reconnect to the server when the connection is forcibly closed?
EDIT: I have tracked the situation. I sent a data to the remote node and sent another data after waiting 5 hours. Sending side sent the first data, but whet the sender sent the second data it didn't response. TCP/IP stack of the sender repeated this 5 times by incrementing the times between retries. Finally, sender reset the connection. I can't be sure why this is happening (Maybe because of a firewall or NAT - see Section 2.4) but I applied two different approach to solve this problem:
Use TCP/IP keep alive using setsockopt (Section 4.2)
Make an application level keep alive. This is more reliable since the first approach is OS related.
It depends on what your application is supposed to do. A little more information and perhaps the code you use for listening and handling connections could be of help.
Regardless, technically a longer keep alive time, should prevent the OS from cutting you off. So perhaps it is something else causing the trouble.
Such a thing could be router malfunction or traffic causing your keep-alive packet to get lost.
If you aren't already testing it on a LAN (without heavy trafic) I suggest doing so.
It might also be due to how your socket is handled (which I can't determine from your question)
This article might help.
Non blocking socket with timeout
I'm not used to how connections are handled on Linux, but I expect the OS won't cut off a connection unnecessary.
You can re-establish connection as a recovery, but you need to take into account that not all disconnects are gentle, and therefore you could end up making recovery on a connection you actually wish to be closed.
Since it is TCP, it will do its best to make a gentle disconnect, but you can send a custom message telling the server or client not to re-establish the connection right before disconnecting. That way you be absolutely sure, despite that it should be unnecessary to do so.
I have a Windows Service that works with an advantage database and occasionally makes some http calls. On rare occasions these calls can be very long. To the tune that my database connection times out. I'm not using a Data Module or anything. Just creating the connection manually.
My primary question is what usually prevents the connection from timing out if I just haven't used it in a while? Do the TAdsComponents send a keep alive message that gets called in the background somehow? Is that dependent on the vcl so I don't have that in my service? Somehow I feel like creating a thread to make my http call, and in the main thread checking for it to finish every few seconds would prevent the connection from dying. Is that ever true?
Yes, there is a keepalive mechanism as you expect. The client (for all communication types, TCP, UDP, Shared memory) sends a "ping" to the server every so often to let the server know that connection is still alive. The frequency of that keepalive ping is based on the server configuration parameter CLIENT_TIMEOUT. With the default settings, I believe the keepalive ping is sent every 30 seconds.
The keepalive logic runs in a separate thread that is started by the code that handles the communication. In other words, it does not depend on any of the VCL components; if you have a connection to the server, then that thread should be running.
One way to check if your connections are timing out is to look in the Advantage error log. There should be 7020 errors corresponding to timed out connections.
Some things that come to mind that might result in timed out connections include:
The client process being suspended for some reason so that the keepalive thread could not run. This seems unlikely.
The keepalive thread was killed for some reason. This also seems unlikely; you would have to go out of your way to make this happen.
A firewall may close the connection if there is no activity for a time. I would think, though, that a 30 second interval would be sufficient to prevent that.
A firewall may disallow the UDP keepalive packets. Firewalls, by nature, are "suspicious" of UDP packets. You might make sure you are using TCP/IP.
im using indy10 for my communications, and sometimes when a client disconnects it raises an exception, i was wondering whats the safest way to disconnect a connection (TIdContext) ?
and what should i do on the OnDisconnect even and similar?
thanks.
Raising an exception is normal behavior. Indy is designed to make heavy use of exceptions, not only for error handling but also for internal notifications and such. OnDisconnect is fired when TIdTCPServer detects that the connection is finished, either because the client disconnected (and TIdTCPServer handled the exception for you) or because an uncaught exception occured in your OnExecute handler code. Either way, use OnDisconnect to perform any cleanup you need. TIdTCPServer will close the socket for you after the OnDisconnect event handler exits.
I just want to add something about sockets internal work (TCP) that I know:
All that server and client does, they sends pieces of data to each other. Server differs from the client only so that he is passive until any client don't send a connection request first. But if client want or forced to break the connection, all is need to do is stop send data to server. To gracefully close a connection client may send special data about this event, like saying "goodbay" by phone, but this is not absolutely required. Simply imagine phone call from you (client) to any service (server). You start conversation with "hello" and service worker responds. If you accidently press reset on your phone, call will lost. But service still continue his work. And you may make call it again. Nothing bad happens from that.
All what you need to care about is stable and correct client and server work by itself. Check incorrect sending and receiving data. Try to reconnect when it needed from client. If some exception throws inside client it must be processed as needed and its normal situation when current connection was lost by such forced events.
Everything else has already answered by Remy Lebeau.
I'm looking to detect local connection loss. Is there a mean to do that, as with the events on the Corelabs components ?
Thanks
EDIT:
Sorry, I'm going to try to be more specific:
I'm currently designing a prototype using datasnap 2009. So I've got a thin client, a stateless server app and a database server.
What I would be able to do is to detect and handle connection loss (internet connectivity) between the client and the server app to handle it appropriately, ie: Display an informative error message to the user or to detect a server shutdown to silently redirect on another app server.
In 2-tier I used to manage that with ODAC components, the TOraSession have some events to handle this issues.
Normally there is no event fired when a connection is broken, unless a statement is fired against the database. This is because there is no way of knowing a connection loss unless there is some sort of is-alive pinging going on.
Many frameworks check if a connection is still valid by doing a very small query against the server. Could be getting the time from a server. Especially in a connection pooling environment.
You can implement a connection checking function in your application in some of the database events (beforeexecute?). Or make a timer that checks every 10 seconds.
Spawn a thread on the client which periodically sends some RPC 'Ping' or 'Heartbeat' commands to the server.
if this fails, the client knows that something happened to the connection
if the server does not hear the client anymore for some time period (for example, two times the heartbeat interval), he can conclude that the client disconnected, however this requires a stateful server (and your design is stateless so it would require event processing in a secondary system, which could be fed through a message queue)