After an unsuccessful attempt to connect the auxiliary port (isc_que_events) any subsequent api call that needs to communicate with the server hangs forever (so the client application hangs forever)
Configure the server (superserver) so that the firewall does not block the main service port (3050) but blocks the specified Aux port (3060 in this case)
--- firebird.conf ---
#RemoteServiceName = gds_db
#RemoteServicePort = 3050
RemoteAuxPort = 3060
Make a connection to the remote server using tcp/ip then call isc_que_events which will timeout after 10-15 seconds with a isc_network_error (335544721). Now make a call that requires communication with the server (e.g. isc_start_transaction ) and the application (library) will hang forever
Right now I can see that it goes wrong when it tries to send the subsequent packet to the server ( port->send(packet) ) but the debugger didnt go any further into the code from there so unsure excatly where after that it fails.
What I've seen on linux is another bug, causing all server to hang indefinitely due to races.
This is an old issue, not a regression in 2.1 or 2.5. Your connection did not hang completely, it's just waiting for a ConnectionTimeout which is 180 sec by default. I agree that this is not very good value for today, but do not think it's worth changing default.
I mark an issue to be fixed before 3.0 beta cause this is really not a good behavior.
To avoid such long waits please set ConnectionTimeout to something about 1-2 seconds for LANs, for WANs this depends upon expected timeouts.