EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Keep-alive on TElSimpleSSLClient?

Posted: 09/15/2010 15:58:11
by Kendall Rogers (Basic support level)
Joined: 09/15/2010
Posts: 2

I am currently using the Simple SSL Client and we're noticing a problem where if the server port becomes closed after, say 30 mins from a firewall, the server won't ack the new port that it opens up, so that when the client sends, it thinks it should still use the new port.

What it appears from our testing is that there is a 2 hour keep-alive that is being used with the component, and searching through the forums here, I've found the other components you use do indeed have a 2 hour keep-alive on them. However it doesn't appear that the SSL Client has any way of changing that value (if it exists in that component) so we're attempting to figure out if we can change it and how we'd go about doing so.

Any help is greatly appreciated!
Posted: 09/15/2010 23:21:22
by Ken Ivanov (Team)

Thank you for contacting us.

Not sure that I understand what exactly you are trying to achieve. If the server is restarted, you will have to set up a new SSL connection to it from scratch. You won't be able to proceed with the connections that have been already established, as all the underlying TCP channels are closed as a result of server restart.

SSL/TLS protocol does not support keep-alives by itself (neither TCP/IP stack does). The value of 2 hours is the default *timeout value* maintained by Windows for TCP/IP stack; this means that a pending blocking operation, such as connect, send or receive, will be terminated by error if its execution time exceeds this time period (unless greater timeout value is explicitly specified). Timeout value to be used by the component can be adjusted with the SocketTimeout property.

If you need to "ping" the server periodically not to have the connection closed by the firewall, you will have to implement your own application level keep-alive support (such as NOOP command in FTP).
Posted: 09/16/2010 12:06:02
by Kendall Rogers (Basic support level)
Joined: 09/15/2010
Posts: 2

I'll try and clarify a bit to see if there's something we're missing as I got a bit more information on the issue, but I think your post gives the answer we're going to have to go with.

Our client opens the SSL connection with the server on a particular port say port 1 for the client and port 1000 for the server, starts a session, and sits idle for some time. The server has a firewall set to close idle sessions (not ports) after 30 mins, but doesn't tell the server that it has done so, so the port remains open. Our client then tries to send after 30 mins, but because the session has ended, it gets rejected, and the client tries to send on port 2. If it tries to send on a new port (sending a new syn to the server), the server still thinks the client should be connected on the old one, and continues to try redirecting the client to the old session (which the firewall will prevent), and does not send a sny-ack back to the client.

During our testing, we've monitored a keep-alive packet that is indeed being sent, but we weren't sure who was sending it, the component or Windows, and it fires exactly every two hours. We wanted to check the component first for two reasons. The first is that it would much easier and more ideal to change a component setting if possible.

As for the second reason, we've found that Windows does indeed have a KeepAliveTime registry setting it uses to send a keep-alive packet across all tcp/ip devices, but the setting is only set in the server versions of windows, which is not the OS we're running. We've tried adding the registry value, but no change has occurred in the packet timing.

I think our solution will have to be sending our own packet out to keep this session from being closed by the servers firewall. If there's something I'm missing here, please let me know. Thanks!
Posted: 09/16/2010 21:58:46
by Ken Ivanov (Team)

Thank you for the detailed explanation.

Yes, the easiest solution for you would be to use your own application level keep-alive signals. The problem is not resolvable on TCP level (it is not possible to substitute one connection with another with the use of the interface provided by TCP sockets), so it would be much easier just to prevent session closures. Changing a system-wide keep-alive setting is also not that good, as it may affect other programs.



Topic viewed 1376 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!