We recently ran into a problem with the "TCP Loopback Fast Path" option (introduced with CORE4563).
Having a Windows 2016 Server (as a guest OS using VMWare) newly booted, any already established local TCP connections are broken in the moment the (optional) "Remote Access Management Service" Windows service starts up. This affects only local TCP connections having the Fast Path option enabled. For Firebird, this results in errors like "ISC ERROR MESSAGE: Error writing data to the connection". After reestablishing the connection all works fine and doesn't break again. I verified that this issue doesn't occur when the Fast Path option isn't used. I don't think that this a problem in Firebird, because other loopback TCP connections between different system components (other than Firebird) that make use of the Fast Path option were affected in the same way.
As the Fast Path option is generally desirable but may cause problems under some rare conditions, I think it favourable to have a config switch allowing to disable it. It's sufficient to have this switch on the server side, because the Fast Path option will only become active if both sides (client + server) opt in for it.
Here's my proposal for a new Firebird.conf section (to be added after " #TcpNoNagle = 1"):
# Either enables or disables the "TCP Loopback Fast Path" feature (SIO_LOOPBACK_FAST_PATH).
# Applies to Windows (version 8/2012 or higher) only.
# Type: Boolean, default 1 (true)
#TcpLoopbackFastPathOption = 1
We also discussed the idea of defining a service dependency, but there are a number of concerns:
1. We don't want Firebird to be stopped when the "Remote Access Management" service is being stopped. I think this is what would happen with the dependency.
2. The "Remote Access Management" service may be present on the computer or not. Our setup would need to detect that etc., which may be not easy with the setup tools we're using.
3. Also, the "Remote Access Management" service might be added (or removed) later when our setup has completed already.
4. We're not even sure if that dependency would really resolve the problem in all cases. It may depend on the timing or the internal activities of the services after startup, not simply a question of the startup order.