KeepAliveTimeSec of TSslHttpServer

[sp0987 0]

Hi,

For Delphi11, we have been utilizing the ICS component suite. With the "TSslHttpServer" component, we recently discovered new behavior.

 

The "KeepAliveTimeSec & KeepAliveTimeXferSec" parameters are intended to shut the connections after an idle time, but when we set the property value to larger than "0," the entire webserver halted.

 

 

[Angus Robertson 574]

My public web servers have the line:

 

        Client.KeepAliveTimeSec := 120 ; // 13 July 2009 increase session timeout

 

and serve thousands of users a day without halting since that line was added.  I don't use KeepAliveTimeXferSec which is only effective during requests,

 

Both versions close the client, not the server.  Which ICS version are you using.

 

Angus

 

 

[sp0987 0]

we are using ICS_FMX-8.69-11

[Arnaud Bouchez 407]

IIRC the keep alive time out is not about idle time, but total existing time of the whole connection.

[sp0987 0]

It means that the connection remains active for the specified amount of time whether the server is active or not.

[Angus Robertson 574]

KeepAliveTimeSec is an idle timeout, from when the last data was received or sent on the client connection.  It is part of http/1.1 that leaves the connection open after a request, waiting for further requests and defaults to 10 seconds in all ICS web servers, XferSecs is five minutes.  It's not changed in years, except to support Int64 ticks. 

 

Quote

we are using ICS_FMX-8.69-11

Is this Windows Server or MacOS?  Why FMX for Windows? 

 

ICS v9 has the first new FMX samples in 10 years, I suggest you build the FMX sample IcsSslMultiWebServ and see if you can reproduce the problem, if so I'll look into it.

 

Angus

 

 

[sp0987 0]

Quote

 

I downloaded ICS_FMX-9.0-11 for windows and tested for KeepAliveTimeSec. even though the value of KeepAliveTimeSec is 0 or > 0 , it was observed that the server being stopped after 5 Mins when it was idle. 

[Angus Robertson 574]

KeepAliveTimeSec only effects remote clients not the server itself.  Are you saying a remote client connection was closed after five minutes, or the web server itself stopped after that time?  There is no server timeout or close down.  

 

Please private email me the complete log file from the ICS sample showing this activity, not just little extracts. 

 

Angus

 

[sp0987 0]

Am attaching the error log file.  It may be helpful to you.

SR-Network-Errors-09-12-23.log

[Angus Robertson 574]

Sorry, single line Windows errors in isolation are no-use.  I asked you to reproduce the error in the new IcsSslMultiWebServ sample and send me the log it generates.

 

Note that both KeepAliveTimeSec and KeepAliveTimeXferSec close the remote client connection, the latter after five minutes by default. If you want to keep an idle remote client open for more than five minutes, you have to set both to zero.  Neither will stop the server.

 

Angus

 

 

[sp0987 0]

As your suggestion i have set both to zero. Still the client connection closes after 5 minutes

[Angus Robertson 574]

Using the IcsSslMultiWebServ sample I asked you to test?  Can I please see the server log file?

 

Angus

 

[sp0987 0]

Attached the log

OverbyteIcsSslWebServ.log

[Angus Robertson 574]

The log shows several sessions from an older VCL web server sample, it does not log when buttons are clicked to start and stop the server. 

 

The two GET requests are closed after a few seconds, the server was closed about 90 seconds later, no idea why but unconnected to the client closing. 

 

I don't see any client connections held open by the browser, and certainly nothing closed after five minutes. 

 

The FMX IcsSslMultiWebServ sample has better logging straight to file, particularly when the Display HTTP protocol box is ticked, but does not log time stamps nor sessions closing, so would need some updating to log the problem you seem to be having. 

 

Angus

 

 

 

[sp0987 0]

Can you look into this?  webapp-20231004.log

[Angus Robertson 574]

The new log does not show any client connections. 

 

If you wish me to investigate an ICS problem, I need to be able to reproduce that problem or have extensive logs that clearly illustrate the problem such that it can be found and fixed. 

 

Those logs need to be annotated to show what I'm supposed to look at to see the problem.  The current ICS samples don't log sufficient detail to show when and why connections close, and why the server has been closed.  That information has never been needed, since the servers have been running in various versions for 20 years without unexpected closing being reported as a problem.

 

Angus

 

[sp0987 0]

On 9/12/2023 at 4:40 PM, Angus Robertson said:

Note that both KeepAliveTimeSec and KeepAliveTimeXferSec close the remote client connection, the latter after five minutes by default. If you want to keep an idle remote client open for more than five minutes, you have to set both to zero.  Neither will stop the server.

 

Even when I set both properties to Zero, it stills close the remote client connection after 5 minutes though the client is not idle.  

[Angus Robertson 574]

But those five minute client connections are not shown in either of the logs you posted.  How do you know the server closed the connection, and not the client, windows or a router? 

 

Angus

 

[sp0987 0]

In my working project ,I have seen this behaviour while debugging.

[sp0987 0]

Am attaching sample test case that describes my issue. Could you please go through it?SSLTest.7z

[Angus Robertson 574]

I see a project, without any explanation of what you are trying to achieve or how to use it. 

 

You have previously mentioned holding open client sessions for long periods, without saying how or why you are trying to do this. Web servers don't hold open connections. 

 

Then the server itself closing when a client closes? 

 

Sorry, without details, I can not investigate anything.    

 

Angus

[FPiette 384]

Fundamentally, HTTP protocol is a session-less protocol. It mean that between request-answer cycle either all involved parties are free to close the connection (client, server and in-between items such as proxies). Building an application on the fact that sometimes it is possible to have the connection remaining open for "some (long) time" is really a bad idea. Actually, cookies have been invented to overcome the disconnected state and yet link consecutive requests to the same client.

Edited October 12, 2023 by FPiette

[Fr0sT.Brutal 900]

2 minutes ago, FPiette said:

Building an application on the fact that sometimes it is possible to have the connection remaining open for "some (long) time" if really a bad idea

Streaming, WebSockets

[Angus Robertson 574]

The websocket protocol has a keep-alive feature, if data is not being sent regularly, it is designed to be kept open.  ICS does this for websocket client and server.  

 

ICS is quite capable of keeping sockets open for hours, but unless there is some traffic external routers and caches may decide the connection is dead and close it, I had to fix an FTP control channel issue where it was unexpectedly closed after a two hour upload of 50GB, needed to send keep-alives.  That was annoying and time consuming, the 50GB uploads worked, but because the control channel was dead were considered failed.

 

But here we are talking about a simple web server, the HTTP protocol allows keep-alive connections usually closing after a couple of idle minutes, I'm not aware it allows hours long connections without any traffic, and certainly the ICS web server is not designed or tested for that concept.

 

Angus

 

[Fr0sT.Brutal 900]

On 10/12/2023 at 4:18 PM, Angus Robertson said:

But here we are talking about a simple web server, the HTTP protocol allows keep-alive connections usually closing after a couple of idle minutes, I'm not aware it allows hours long connections without any traffic, and certainly the ICS web server is not designed or tested for that concept.

Yes, that is quite unusual for HTTP but possible (standard doesn't restrict AFAIK). However, empty (without keep-alive packets) connections are really the candidates for closing by network devices.