Howto disconnect client (on serverside) after session expired


(triple-m) #1

Hi there, we have an old project here. Delphi 2007, RemObjects 6.0.61.1029. Nevertheless - i hope Nothing has changed concernig my “problem”. We are using a Synapse SuperTCPServer with lots of clients.
Now: in some circumstances the clients sessions will expire. On Serverside this is being monitored in SessionManagerSessionDeleted event. Even if the session is expired or not. The problem: From now the events obviously will not reach the concerning clients anymore.
The easiest way now would be to disconnect the concerning clients from Serverside. The client would then reconnnect, relogin and get a new session.

But how can one access the client channel to disconnect? I did not find it.


(EvgenyK) #2

if client session is deleted, client should do re-login.
or in your case, client was able to communicate with server after deleting session?


(triple-m) #3

Yes i agree. The client should re-login. But for many reason we should “fix” the problem at server side. Actually the problem happens because of an old bug: Daylight saving - session timeout issue?
Im sure this has been fixed meanwhile. But its also not possible to upgrade the remobjects version because of some strange policies. After this daylight saving issue the clients keep connected - but with lost session on the server. This is why i want to disconnect the client(s) from the server. How to do this? How do i get to the concernig client socket to disconnect it? If i could so - the client(s) will reconnect and relogin and the “once in a year problem” is solved.


(EvgenyK) #4

you are using a quite old version of RO SDK. mentioned bug was fixed long time ago.
Can you review these workarounds:

  • periodically, client should call server method and check for client session via new channel/message and it should pass ClientID from main message as parameter. server should check this session and return True/False, so client will know if relogin is needed. you can use SessionManager.FindSession(Param1, False);
  • another workaround could be in increasing session duration from 15 min to, say, 75 min so session will be valid after daylight saving.