Tweaking the TCP timeout question

Hello,

I have a question related to the tweaking of TCP timeouts and retries.
Basically I have an application that connects to a remote server to
perform various operations. If the server dies however, it will
perform operations on a local database then sync up with the server
later. In linux, if the remote server is offline, the application
tries to reach the server for approximately 2 minutes before it gives
up and uses the local database. This of course makes the application
seem like it has hung.

I've done some research into tweaking tcp settings. I've found
various settings that I can tweak in the proc systems using sysctl.
I'm not sure which ones will work for this task. I'm currently
playing with:

tcp_orphan_retries
tcp_retries1
tcp_retries2

Does anyone know if I'm on the right track? Also I know these flags
alter the settings based on the retransmission timeout (RTO). Is
there anyway of tweaking the RTO? Or will tweaking one of the above
flags suffice?

Thanks in advance for your help

Kaman wrote:

> Hello,
>
> I have a question related to the tweaking of TCP timeouts and retries.
> Basically I have an application that connects to a remote server to
> perform various operations. If the server dies however, it will
> perform operations on a local database then sync up with the server
> later. In linux, if the remote server is offline, the application
> tries to reach the server for approximately 2 minutes before it gives
> up and uses the local database. This of course makes the application
> seem like it has hung.
>
> I've done some research into tweaking tcp settings. I've found
> various settings that I can tweak in the proc systems using sysctl.
> I'm not sure which ones will work for this task. I'm currently
> playing with:
>
> tcp_orphan_retries
> tcp_retries1
> tcp_retries2
>
> Does anyone know if I'm on the right track?

I think you are doing it the hard way...

The most common way to get around long connect times is to set the socket to
non-blocking, call connect(), then call select() on the socket with a reasonable
time-out, checking for errors and writability. If the select times out or shows
a socket error then you know the connect() has not completed and you can close
the socket. If select() returns that the socket is writable then the connect()
was successful.

> Also I know these flags
> alter the settings based on the retransmission timeout (RTO). Is
> there anyway of tweaking the RTO? Or will tweaking one of the above
> flags suffice?
>
> Thanks in advance for your help

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com