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

Set the SO_KEEPALIVE option on the client TCP socket [CORE2752] #3147

Closed
firebird-automations opened this issue Nov 13, 2009 · 22 comments
Closed

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Vladimir Arkhipov (arkinform)

It will be useful for server applications, which connects to remote firebird servers (for example, replication servers)

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Vladimir, SO_KEEPALIVE is used by server sockets to detect dead clients. I suppose you wish to check for dead server in your case. But client (unlike server) always can check, is server alife or not, using any API call (information, for example). Next, when server socket detects dead client, it has absolutely clear idea what to do - release all resources, required for that client. Can you explain what should be done in your example? Stop replication thread? Not sure this is good idea.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Vladimir Arkhipov (arkinform)

Yes, I wish to check for dead server (rather for connection abort). In my case replication thread is freezing for a long time (usually for unlimited time) and I want to detect it. Of course I can "ping" the remote port in separated thread, but connection may be already restored, anyway my exist database connection may be dead. More, I need to free this thread but closing database connection from another thread is not very safe. In addition I have many databases (about 30) and I need database pooling for each thread. And freezing prevent from normal processing of next databases in pool. And in this case SO_KEEPALIVE will be applicable.

@firebird-automations
Copy link
Collaborator Author

Commented by: Vladimir Arkhipov (arkinform)

What about resolution for this issue?

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I'm scheduling this ticket for v3.0, as v2.5 is already frozen for changes. BTW, I'm not really convinced this is a bug per se. It more looks like an improvement request.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

I'm still not absolutely sure that this will work. Keepalive packets are used to check for presence of the other side of network socket when there is *no* network activity on the socket. When replication request from server to another server is sent, it means presence of activity on the socket, therefore generic IP timeouts should work here.

@firebird-automations
Copy link
Collaborator Author

Commented by: Vladimir Arkhipov (arkinform)

Is it possible to use SO_RCVTIMEO and SO_SNDTIMEO socket options instead of SO_KEEPALIVE ?! But on some platforms these options may be unsupported. BTW, I agree that this issue is improvement, sorry :)

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

issuetype: Bug [ 1 ] => Improvement [ 4 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Frank Schlottmann-Goedde (fsg)

In the meantime, until this has made it into the official codebase you may use <http://libkeepalive.sourceforge.net/> for a workaround.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Alexander Peshkov [ alexpeshkoff ] => Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

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

resolution: Fixed [ 1 ]

Fix Version: 2.5.1 [ 10333 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

summary: Add an ability to set SO_KEEPALIVE option on client socket => Set the SO_KEEPALIVE option on the client TCP socket

@firebird-automations
Copy link
Collaborator Author

Commented by: Vladimir Arkhipov (arkinform)

Can you append timeout parameters for KeepAlive sockets in firebird.conf for server and fbclient API for clients?
It will be more clear and easier for configuring and managing.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

These settings are system-wise, they don't belong exclusively to Firebird. So changing them at runtime (what may require admin rights, BTW) sounds like a bad idea.

@firebird-automations
Copy link
Collaborator Author

Commented by: Vladimir Arkhipov (arkinform)

I don't suggest to change system settings.
In Windows, for example, you can set SIO_KEEPALIVE_VALS in WSAIoctl function per connection.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms741621(v=vs.85).aspx
I think in linux you can do it too.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I'm not so sure regarding Linux and especially other unices.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

After some googling, it looks like IPPROTO_TCP + TCP_KEEPINTVL might make it possible. Not sure it's supported in all platforms though.

@firebird-automations
Copy link
Collaborator Author

Commented by: Vladimir Arkhipov (arkinform)

I think if it can be done in Windows and all Linux then this is sufficient for introducing this feature in Firebird. But it is your decision :)

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test => Cannot be tested

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

2 participants