Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a configuration switch to disable the "TCP Loopback Fast Path" option (Windows only) [CORE6004] #6254

Closed
firebird-automations opened this issue Feb 19, 2019 · 9 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: KS (karlox)

Assigned to: KS (karlox)

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

Commits: 971b9a8 8381154 ad106be 467708b 8ef3d6c f78ddaa 88f799a a0692f4 a769533 482c688 540c905

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

"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.

@firebird-automations
Copy link
Collaborator Author

Commented by: KS (karlox)

We already tried with Startup Type = "Automatic (Delayed Start)". It led to the error to occur less frequently, but it still happened.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

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 [https://support.microsoft.com/en-us/help/251192/how-to-create-a-windows-service-by-using-sc-exe ], 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.

@firebird-automations
Copy link
Collaborator Author

Commented by: KS (karlox)

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0.5 [ 10885 ]

Fix Version: 4.0 Beta 2 [ 10888 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

The patch was developed and tested by ticket author himself.
Thanks for contributing !

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ] => KS [ karlox ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Deferred

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant