Session Timeout Questions!!

[Shane Stump]

Howdy!

I have a couple of session time-out questions!!

1) There are so many time out properties!! What I want to do is set timeout properties as follows:

a) 15 seconds for my remote login/logout functions
b) 60 seconds for my other remote functions.

Which properties and when do I set them for each of the above?

2) Some of my users will be running my client app on 4G (LTE). I will have the server AutoSessionTimeout set to 30 minutes or so. I will set my client's AutoSessionsPing time to 15 minutes or so.

Will this keep the LTE network usage to a minimum? That is, I want use minimum network traffic to keep my sessions alive when NOT in use.

Thanks in advance!

Shane

[D.Tkalcec (RTC)]

1) All Timeout properties on TRtcHttpClient and TRtcHttpServer components are general communication timeouts and NOT specific to the request type being made. The main purpose of these Timeouts is to identify connections which have been dropped by peer, but no TCP/IP packet was received to notify us. You can either leave all these Timeout values unchanged, in which case default System timeouts will be used, or set maximum Timeout values you think would be appropriate for your setup. For example, if you expect that 60 seconds is the longest possible time you can imagine for any kind of a request or response to finish and reach its destination, you could use 60 as your general Timeout value. Just keep in mind that these Timeout values should serve more like a safety-net, to make sure you don't end up with a dead connection which never returns, but they shouldn't be too low, because you would start dropping healthy connections in case the Server takes longer to respond and that's a not a good thing.

PS. If you are using the Execute method to call remote functions in blocking mode, you can specify the Timeout value for each function through a parameter of the Execute method. But I wouldn't recommend using function-specific timeouts, nor would I recommend using blocking remote function calls if they can be avoided.

2) Yes, that should work. Just make sure to set the AutoConnect property to TRUE and enable all the required ReconnectOn properties.

By using general connection Timeouts, idle connections will be closed. With the AutoSessonTimeout property set on the Server, old Sessions will expire. Using AutoSessionsPing on the Client, Sessions which are still in use will be kept alive on the Server, even when there is no other traffic. And by using AutoConnect and ReconnectOn properties, the connection will be re-opened when needed.

Best Regards,
Danijel Tkalcec

[Shane Stump]

Howdy Daniijel!

Thanks for the informative answer!

I am finally getting back into my RTC application I wrote 5+ years ago and I finally remembered the difference between it and my WIN32 database applications! That is, a session and a connection aren't necessarily the same in RTC as they are in a normal database application.

But I do have a connection timeout question (non-blocking)! If I want a remote function to fail after ## seconds if it isn't successful, what is the best way to set this up amongst the 5 TimeoutAPI timeout values?

Thanks in advance!

Shane

[D.Tkalcec (RTC)]

Let me be clear that Timeout as well as TimeoutsOfAPI properties on the TRtcHttpClient component make absolutely no distinction between a remote function call and any other request sent to the Server. Also, please let me point out that all Timeout values are there ONLY as a safety-net, to make sure that a connection will be closed gracefully in case a TCP/IP packet responsible for notifying the peer about a connection being closed failed to reach its destination.

Using Timeouts to limit how long a Client is "willing" to wait for a Server to expecute a specific task and return with a result is a bad idea, because once a request has reached the Server, the Server will execute the request and try to start sending a response, wether the connection was closed by the Client or not in the meantime. And if you are using Sessions and you decide to close a connection on the Client side while the Server is still processing the last request, when the Client closes its connection (because of a forced Timeout on the Client side), opens a new connection and sends a new similar or identical request, once this new request reaches the Server, it will be unable to lock the same Session again if the previous call is still being processed, so the Server (not having any other choice) will send a response back to the Client, telling the Client that its "Session has expired". And then, the Client will have no other choice but to request a new Session on the Server and probably also go through the login process again, all just because of a premature Timeout on the Client. Also, depending on the Server type (Single- or Multi-Threaded) and the current Server load, it is possible that some functions will take much longer than anticipated. And then, because the whole communication process is asynchronous, you could end up with 2 or more requests from the same Client, reaching the Server at about the same time, causing even more problems.

While this does NOT answer your question, I hope it does explain why using Timeouts for specific tasks (like remote function calls) is a bad idea.

To make a long story short, Timeout and TimeoutsOfAPI properties only define general connection behavior. They are not task-specific.

Best Regards,
Danijel Tkalcec

[Shane Stump]

I understand what you are saying but unfortunately I have to have consistent task rules. For example in my reservation system processing a credit card is time limited to a user defined time-out (normally no more than 30 seconds).

Database transactions have a timeout value before failing.

I have to be able to as part of my internal API to be able to specify timeout values and have the client (and possibly server) handle them accordingly.

I will have to play with the timeout values as I really need to have an understanding how they are going to work with my system.

Best regards,

Shane

[D.Tkalcec (RTC)]

All Timeout and TimeoutsOfAPI properties are described in the HELP file.

Here is a short description of each TimeoutsOfAPI property:

1. ResolveTimeout = Domain Name resolution timeout (WinHTTP API).
- If domain name resolution takes longer than this time-out value, the action is canceled.

2. ConnectTimeout = Connection request timeout (WinINET and WinHTTP APIs).
- If a connection request takes longer than this time-out value, the request is canceled.

3. SendTimeout = Sending requests timeout (WinINET, WinHTTP and WinSock APIs).
- If sending a request takes longer than this time-out value, the send is canceled.

4. ResponseTimeout = Receive response headers to a request timeout (WinHTTP API).
- If a response takes longer than this time-out value, the request is canceled.

5. ReceiveTimeout = Receive response to a request timeout (WinINET, WinHTTP and WinSock APIs).
- If a response takes longer than this time-out value, the request is canceled.

All Timeout values are in seconds and only apply to the APIs listed above.
With the default property values (0), default System timeouts will be used.

These are general purpose timeouts, which will be applied to all communication processed by that specific TRtcHttpClient component.

Best Regards,
Danijel Tkalcec

[Shane Stump]

All Timeout and TimeoutsOfAPI properties are described in the HELP file.

Here is a short description of each TimeoutsOfAPI property:

1. ResolveTimeout = Domain Name resolution timeout (WinHTTP API).
- If domain name resolution takes longer than this time-out value, the action is canceled.

2. ConnectTimeout = Connection request timeout (WinINET and WinHTTP APIs).
- If a connection request takes longer than this time-out value, the request is canceled.

3. SendTimeout = Sending requests timeout (WinINET, WinHTTP and WinSock APIs).
- If sending a request takes longer than this time-out value, the send is canceled.

4. ResponseTimeout = Receive response headers to a request timeout (WinHTTP API).
- If a response takes longer than this time-out value, the request is canceled.

5. ReceiveTimeout = Receive response to a request timeout (WinINET, WinHTTP and WinSock APIs).
- If a response takes longer than this time-out value, the request is canceled.

All Timeout values are in seconds and only apply to the APIs listed above.
With the default property values (0), default System timeouts will be used.

These are general purpose timeouts, which will be applied to all communication processed by that specific TRtcHttpClient component.

Best Regards,
Danijel Tkalcec

I have read those and there in lies my understanding problem - #1 I can set to a small timeout value.

How does #2 through #5 affect a general task time limit? That is, if I have 30 seconds to complete a task, what should I set #2 to #5 though? I know you keep saying that this is a BAD design, but my tasks are simple and NOT large! That is, I won't be trying to send a multi-megabyte file back. I am hopefully going to be using RTC to write an API into my reservation system and most requests will at most be only a couple of kilobytes.

When I get into my office later this morning, I will try setting a few time limits and see how it works out. It looks like I will need to use my own sessions and as part of my API, include a START_TIME variable on each call so the server remote functions will know if the allotted task time takes too long.

Thanks for the help!

Shane

[D.Tkalcec (RTC)]

Here are all the communication steps, with the meaning of each TimeoutsOfAPI value:

1. Domain name has to be resolved, unless you will be using fixed IP addresses, in which case that step is skipped. ResolveTimeout plays a role here, but only if WinHTTP API is used. With other APIs, you have no direct control over this timeout.

2. Once we have an IP address and Port number, a connection has to be established. ConnectTimeout is important at this stage, but only when using the WinINET or WinHTTP API. With other APIs, again - no direct control is available at this point, the System decides how long it is ready to wait.

3. Then, a request is sent to the Server. Depending on the size of the request, this could take a while. SendTimeout is important here. This is one of two timeouts which are used by all APIs. Basically, it sets a timeout for sending a complete request to the Server.

4. When the request is received on the Server, the Server will be processing that request and preparing a response, then sending the response to the Client.

5. The Client will get the response headers first. ResponseTimeout plays a role here, but only when using the WinHTTP API. This timeout defines the maximum allowed time between sending the complete request to the Server and receiving the first response data back.

6. Then, the rest of the response will be arriving, until the complete response is on the Client. ReceiveTimeout is important at this stage and is available on all APIs. When using the WinHTTP API, this would be the time you are willing to wait for a response to be received, starting with the header - down to the last byte. With all the other APIs (WinInet, WinSock and BSD on other platforms), this is the maximum time allowed from (A) sending the last byte from the request and finishing with all the processing on the Server and receiving the complete response back (B).

7. When the next request has to be sent out, if the connection is already established and active, steps 1 and 2 will be skipped, so ... repeat from step 3.

In a nutshell ... if you ignore the requirement for a domain name to be resolved and a connection to be established, which should not take more than a few seconds on a modern internet connection, it is safe to say that SendTimeout defines the time allowed for a request to be sent to the Server, while ReceiveTimeout defines the time allowed for the request to be processed on the Server and a complete response to be received back on the Client.

I hope this helps.

Best Regards,
Danijel Tkalcec

[Shane Stump]

Daniijel!!

Thank you very much!! That is what I was looking for!!

As I am sure you figured out QUICKLY, I am NOT a TCP/IP expert!

All my other projects with RTC have been in a controlled LAN environment.

This project will be used by the National Park Service here in the US and the first place they want to test is a barrier island which will be using so-so 4G!!

Again, many thanks!

Shane

[D.Tkalcec (RTC)]

By the way ... you can also manually inteterrupt asynchronous RTC communication tasks at any time by calling DisconnectNow(True) on the TRtcHttpClient component. This is useful if you want to allow the user to interrupt a pending request, or if you want to implement your own task-specific timeouts (for example by using a TTimer component).

Best Regards,
Danijel Tkalcec

[Shane Stump]

By the way ... you can also manually inteterrupt asynchronous RTC communication tasks at any time by calling DisconnectNow(True) on the TRtcHttpClient component. This is useful if you want to allow the user to interrupt a pending request, or if you want to implement your own task-specific timeouts (for example by using a TTimer component).

Best Regards,
Danijel Tkalcec

Thanks!

I am going to writing my own Remote Function class now (i.e. a datamodule) that will be used with a Progress Dialog class I have! That is, the RTC components will be used on a worker thread.

Since my remote app will only allow ONE remote call at a time, I should be able to get this working!

Again, I appreciate your patience and information!

Best Regards,

Shane

[Shane Stump]

Daniijel!

Follow up question!

I have been experimenting with using AutoSessions and calling remote functions.

Since I will always be using a STATIC ip address for the server and the overhead seems minimal, I have basically been opening / closing (Disconnect) the connection after a successful or failed remote call. The session on the client / server as you have described is NOT affected by doing so. I also have my own client worker thread doing a "session ping" on the remote server if necessary.

My reasoning for handling connections this way is that it makes connection exception management simple since I only need to use a connection when a remote function is called.

Do you see any MAJOR problems with doing it this way?

Best Regards,

Shane

P.S. I have also gotten the timeouts to work as expected since my worker thread handles the timing and uses the DisconnectNow() function you mentioned if needed!

[D.Tkalcec (RTC)]

If your Client is working with a single Server, so there is no need to change the Address of the Server between requests, you would be saving a lot of time and some TCP/IP overhead if you would be using the AutoConnect and ReconnectOn properties and reusing connections, instead of opening and closing a connection for every single request. Especially with short requests like yours, manually opening and closing a connection can have a MAJOR impact on your Client and Server performance. Not only will the Client be wasting time between requests, the Server will also have more work to handle frequent opening and closing of Client connections.

In short, you will definitely have a performance penalty and some network traffic penalty for opening and closing connections manually for each request, but ... if performance is not an issue for you (wasting a second or more for every request - just to open and close a connection), there are no other MAJOR disadvantages when manually opening and closing a connection instead of reusing the connection with the AutoConnect and ReconnectOn properties.

Best Regards,
Danijel Tkalcec

[Shane Stump]

Thanks for the answer!

I will try it with the AutoConnect() and Reconnect and see how it goes!

Best!

Shane