we use InterBase on a Windows 2003 server, and in random intervals the client connection to the server takes 180 seconds (three minute) longer than usual. The application does not "hang" with the normal Windows warning in the title bar and continues happily after the delay.
Now the rate seems to have increased since some Windows 2008 servers have been added to the network.
As other applications in the network do not have similar "hangs" I suspect the (virtual) machine or the server process itself. We use the same InterBase database client and server software version in a different network without problems, so my first area of interest is the network (TCP/IP) of the machine. For the same reason I do not think it is a DNS problem, or is this a another candidate?
Are there possible technical explanations for such a delay, for example as a consequence of a full network buffer queue, for such a delay?
netstat -s shows unusccessful connection attempts, zero dropped datagrams received.
IPv4-Statistik
Empfangene Pakete = 1267651308
Empfangene Vorspannfehler = 0
Empfangene Adressfehler = 44827
Weitergeleitete Datagramme = 0
Empfangene unbekannte Protokolle = 0
Empfangene verworfene Pakete = 0
Empfangene übermittelte Pakete = 1267651006
Ausgabeanforderungen = 1097296840
Verworfene Routingpakete = 0
Verworfene Ausgabepakete = 0
Ausgabepakete ohne Routing = 0
Reassemblierung erforderlich = 14
Reassemblierung erfolgreich = 7
Reassemblierung erfolglos = 0
Erfolgreiche Datagrammfragmentierung = 7
Erfolglose Datagrammfragmentierung = 0
Erzeugte Fragmente = 14
ICMPv4-Statistik
Empfangen Gesendet
Meldungen 26579 26678
Fehler 0 0
Ziel nicht erreichbar 0 95
Zeitüberschreitung 0 0
Parameterprobleme 0 0
Quelldrosselung 0 0
Umleitungen 0 0
Echos 60 26523
Echoantworten 26519 60
Zeiteinträge 0 0
Zeiteintragantworten 0 0
Adressmasken 0 0
Adressmaskenantworten 0 0
TCP-Statistik für IPv4
Aktiv geöffnet = 69080
Passiv geöffnet = 16751143
Erfolglose Verbindungsversuche = 363
Zurückgesetzte Verbindungen = 633
Aktuelle Verbindungen = 11
Empfangene Segmente = 1265427823
Gesendete Segmente = 1096717835
Erneut übertragene Segmente = 570293
UDP-Statistik für IPv4
Empfangene Datagramme = 2136945
Keine Anschlüsse = 98648
Empfangsfehler = 2680
Gesendete Datagramme = 50088
One of the things that I always look for when I see a connection hang is reverse DNS lookup failure. Many applications attempt to resolve the DNS name of a connecting client just after the socket accept on the server side. When DNS does not resolve properly you can experience a hang after which things appear to proceed normally without issue. I have seen this with a wide variety of application services. The time delay of 3 minutes you mention does seem a bit long for this scenario. The typical connection delay that I see is less than 1 minute.
The problem disappeared when we re-installed the database server.