Issue Details (XML | Word | Printable)

Key: CORE-6004
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: KS
Reporter: KS
Votes: 0
Watchers: 6

If you were logged in you would be able to see more operations.
Firebird Core

Add a configuration switch to disable the "TCP Loopback Fast Path" option (Windows only)

Created: 19/Feb/19 11:09 AM   Updated: 19/Apr/19 05:40 AM
Component/s: Engine
Affects Version/s: 3.0.4
Fix Version/s: 3.0.5, 4.0 Beta 2

Environment: Windows 8/2012 and higher

QA Status: Deferred

 Description  « Hide
We recently ran into a problem with the "TCP Loopback Fast Path" option (introduced with CORE-4563).

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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 19/Feb/19 05:06 PM
"Remote Access Management Service" is only active on hosts which also have Remote Desktop Services/Terminal Services active, which is not a typical Firebird install environment.

Please try the Startup Type = "Automatic (Delayed Start)" setting in the Services Control Panel, on the Firebird service, and report back.

KS added a comment - 19/Feb/19 07:21 PM
We already tried with Startup Type = "Automatic (Delayed Start)". It led to the error to occur less frequently, but it still happened.

Sean Leyne added a comment - 19/Feb/19 09:13 PM - edited
As I see it, as you point out, the problem is with your specific installation not with the Firebird engine. So, I don't believe that this issue should be considered a high priority change.

You could create a function to install/register the Firebird service or use the "SC.exe" command-line utility [ ], to add the dependency on the "Remote Access Management" service. In this case, Windows would only start the Firebird engine after that service had been started.

KS added a comment - 20/Feb/19 03:10 PM
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.

Vlad Khorsun added a comment - 21/Feb/19 10:03 PM
The patch was developed and tested by ticket author himself.
Thanks for contributing !