ClementDoss
|
|
« on: December 21, 2014, 08:49:50 PM » |
|
Hi,
I'm building a rtcServer that will handle remote functions and also user sessions. At the server side, I'm creating the user session and all the classes I need to keep the user data in the session. At the client side, I have some doubts. I have multiple TRtcClientModule and each will deal with a specific group of functions. For example: One Clientmodule will access /UserAPI, another /CustomerAPI, another /OrdersAPI. In each TrtcClientModule I have an OnLogin/ OnLoginAbort / OnLoginResult.
What I need to do is very simple. Once the session has expired, the user must enter login/password again, at any point in the client application. Is there a way to manage the sessions in one component only, or should I specified the logins events for each ClientModule? Should I use HttpClient on SessionOpen and SessionClose ?
Can sessions have different timeout values? For example: Session of machine 1 expires in 5 minutes. Session in machine 2 expires in 10 minutes. Can this expiration timeout be define from the client side? What is the correct way to define the session timeout
Happy holidays! Clément
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #1 on: December 22, 2014, 01:57:48 PM » |
|
Because there is only one Session per TRtcHttpClient component, it does not matter which TRtcClientModule will be used to create that Session, since all TRtcClientModule components will be sharing that same Session data on the Server.
Each Session object has its own "KeepAlive" property, which defines how long that Session should remain alive before it is allowed to expire. This means that you can set a different Timeout value on the Server for each one of your Clients - for example, inside your "login" remote function - by using the "KeepAlive" property of the Session object. The last KeepAlive value will be used to define how long the Session has to remain on the Server before it is allowed to expire.
Session data is NOT automatically transferred between the Server and its Clients. Except for the Session ID, which will be automatically sent by the TRtcClientModule to the TRtcServerModule with each request, because it is required to find and lock the Session object for use on the Server side, no Session parameters or data are sent automatically from the Client to the Server or back. So ... whatever you want to do with Sessions on the Server, has to be done on the Server.
Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
ClementDoss
|
|
« Reply #2 on: December 23, 2014, 03:46:46 PM » |
|
I'm not willing to pass any session information from server to client. I want to be sure RTC is managing the session for me, and I want to understand and use it correctly.
What confuses me is "Client side session" and "Server side session". The server side session will remain active until it expires. I can control the session expiration using the server side keepalive property. In order to maintain a session alive for 5 min, setting KeepAlive := 5 * 60 * 1000 would be enough? (No other properties or settings would be required? )
The client side session will have only the session ID. This session will remain opened until the application is closed, right? My application has a simple "login/password" protection. When the server session expires, the application must request a login / password before allowing application usage. By setting the login events on a TrtcClientModule, RTC will detect the server side session has expired, and the ClientModule will trigger the login event that will allow the user to authenticate again.
Is this the correct way to setup logins in RTC?
Best regards, Clément
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #3 on: December 23, 2014, 04:13:52 PM » |
|
1. The KeepAlive value, like most other time based values on RTC components, is in seconds and not in milliseconds, which means that 5 minutes will be 5 * 60 and not 5 * 60 * 1000. You can find this information in the property description (HELP file or property comments in source code).
2. You do not need to store any Session information on the Client, if you do not want to. The Client only needs the Session ID, which will be sent from the Server and updated on the Client every time a new Session is opened by the Server - provided you are using Automatic Sessions with RTC remote functions. If a Session expires on the Server and you are using Automatic Sessions, a new Session will be opened on the Server and the Client will receive the new Session ID, updating it locally - until the Application closes or the Session expires again.
3. The purpose of Session expiration is to clean up Server Memory if a Client loses connection and does not return, so the Session should normally be set up to remains active from the first Client login until the time the Client logs out or loses connection for "too long". The easiest way to achieve this is to use the AutoSessionPing feature on the TRtcClientModule, which would keep a Session alive on the Server when it is not being actively used. This avoids a situation where a Session would expire on the Server because of user inactivity. The AutoSessionPing feature works by periodically sending a remote function call to the Server when no other data is being sent, keeping the Session alive.
Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
ISIGest
RTC Expired
Posts: 121
|
|
« Reply #4 on: April 17, 2015, 06:57:39 PM » |
|
I've a simply question: What happens if a Client Call a function and the server reply later "AutoSessionsLive" seconds?
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #5 on: April 17, 2015, 07:56:07 PM » |
|
Nothing will happen to the Session which was in use by the Server, because only Sessions which are NOT in use will expire, and the Session expiration time is updated automatically before the Server releases the lock on a Session.
Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
ISIGest
RTC Expired
Posts: 121
|
|
« Reply #6 on: April 18, 2015, 08:26:58 AM » |
|
This is not really true On my server I've set (Module) AutoSession := True; AutoSessionLive := 30; If from my client I call a function and the server take more than 30 seconds to reply, all work but after reply: if AutoSyncEvents and not Sender.inMainThread then Sender.Sync(Call_DataReceived) else if Response.StatusCode=410 then // Status 410 = Gone: Session ID invalid, clear local Session info. begin Call_SessionExpired(Sender); <--- EXPIRED!! end
Can you test this?
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #7 on: April 18, 2015, 09:05:38 AM » |
|
1. Is your Server single-threaded or Mult-iThreaded? In other words, what is the value of the "MultiThreaded" property on the TRtcHttpServer component?
2. If your Server is Multi-Threaded, how many Clients with longer-running execute methods do you have on the Server when your Sessions start expiring?
3. If your Server is Multi-Threaded, have you modified any global variables from the rtcThrPool unit (increased or decreased) to customize RTC Thread pool performance or capabilities?
Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
ISIGest
RTC Expired
Posts: 121
|
|
« Reply #8 on: April 18, 2015, 09:42:17 AM » |
|
Yes it's multithread, and I have 10-12 clients connected with 2 connection for each (request and callback).
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #9 on: April 18, 2015, 09:52:22 AM » |
|
When the Clients are NOT actively using the Server to make remote function calls, are they periodically making simple remote function calls to the Server in order to ensure that their Sessions will NOT expire? For example, by using the AutoSessionsPing property and OnPing event on the TRtcClientModule component? Fact is, that a Session can NOT expire when it is locked (in use) and that Session expiration time is updated automatically before a Session is unlocked. Because of this mechanism, the only possibility in which a Session could expire, is when it has NOT been in use for longer than specified AutoSessionsLive period while Session cleanup is performed, which happens ONLY when another Session gets unlocked. If you think this is NOT the case, then please create a simple Client and Server example Project to demonstrate the problem and send me the source code by E-Mail, along with steps to reproduce the issue, so I can debug it on my development machine: PS. Sessions do NOT stay locked while waiting for a Delayed Call timeout to expire. If you are using "callbacks" (PrepareDelayedCall and the TRtcDelayedCall class), you need to make sure that your "callback" returns to the Client (by using a short enough Timeout for the Delayed Call), even if there is no data to send back, before the Session expires. Sessions ONLY stay locked while your code is being processed inside the "OnExecute" event. Once your event execution is done, the Session will be unlocked again. Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
ISIGest
RTC Expired
Posts: 121
|
|
« Reply #10 on: April 18, 2015, 04:53:48 PM » |
|
Unfortunately I cannot recompile my server I did other tests on a local server but all work. I can debug only a client. Is there a way to check why a session is expired on client?
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #11 on: April 18, 2015, 05:55:50 PM » |
|
Sessions do NOT expire on the Client, so I'm not really sure what you are asking.
But ... when a Server reports back to the Client that his Session has expired, it means that the Client has requested access to a Session which was NOT found in the list of available but currently unlocked (not in use) Sessions on the Server. This can either mean that (A) the Session has expired and was removed from the list of Sessions, or it can mean that (B) the Session has been locked by another Client connection which is currently being processed on the Server, or that (C) the IP Address of the Client has changed and the RtcServerModule is set up with the AutoSessionsLock property value of sesIPFwdLock or sesIPLock - in which case the Client will no longer be able to access his Session data, even if his Session is still there.
PS. If you are unable to recompile your Server, how do you expect to fix the problem?
Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
|