How Event registration works on disconnections

Remoting SDK
1

Delphi Server, Tokyo, latest RO/DA.
Supertcp Synapse. Using Olympia for session and event management. Delphi and .Net clients.

How events work under disconnection scenarios.

Scenario 1.
Client registers event “EVENTSINK” to server. Client loses connection to server, but session doesnt expire. Client reconnects. Does it has to re-gister again to the server?

R/ I will assume no, cause server has all the information about the client connection via Olympia.

Scenario 2.
Client registers event “EVENTSINK” to server. Client loses connection to server, but session DOES expires. Client reconnects. Does it has to re-register again to the server?

R/ Here I will assume yes, because session is no longer available on Olympia.

Scenario 3.
Client registers event “EVENTSINK” to server. Server crashes or is stopped. Client loses connection. Server is restarted. Session has NOT expired. Does client needs to register again to server?

R/ Here I will hope it shouldnt, cause if all the session and registration information is kept on Olympia it should be able to go restore itself accordingly, is that the case?

Scenario 4.
Server crashes or is stopped. Client loses connection. Server is restarted. Session expired. Does client needs to register again to server?

R/ I will expect to be the same as response on Scenario 2.

Please help me out on clarifying how it behaves so we can take the necessary precautions. High availabilty for us is key.

Thank you.

2

Hi,

we have two modes of events : Legacy (i.e. delphi compatible only) and .NET compatible.
for backward compatibility, default mode is Legacy.

difference:

  • In the legacy mode the event receiver will automatically perform a call to the server to register the client to receive the registered event sink(s), when you call RegisterEventHandlers client-side method.
  • In the .NET-compatible mode each session must be explicitly subscribed via the RegisterEventClient server-side method. The client can be unsubscribed via the UnRegisterEventClient server-side method. For example (based on the File Broadcast sample, the FileBroadcastService_Impl.pas file):
procedure TFileBroadcastService.uploadfinished(const filename: Unicodestring; const filesize: Int64);
begin
  // This line should be added so the event can reach the client:
  RegisterEventClient(GuidToString(ClientID), EID_FileEvents); 
  (EventRepository as IFileEvents_Writer).OnNewFileAvailable(Session.SessionID, filename, filesize);
end;

What mode you are using?

.NET compatible mode should solve your issues because you can put RegisterEventClient into login method

3

Hi Evegeny,

Thank you for the response. We have .Net clients and Delphi clients using the new way of registering (non-legacy).

We have a centralized login service used by many other services. Clients will login into the centralized login service but they may opt out from receiving sinks, so we can not have registering a client and login as a single action. We sent thousands of events and we want to reduce traffic on nodes where is not required.

That is why we are trying to understand the RO SDK behaviour under the scenarios mentioned above. We have wrappers around your classes to expose interfaces and act accordingly, now we are debating how to deal with the disconnections and re-subscribing of clients.

Could you tell me how the SDK works under those 4 scenarios described above?

Thanks in advance.

4

if session is valid, SessionNotFoundException exception isn’t raised so client won’t be re-login.

if session is expired, SessionNotFoundException exception will be raised so client will re-login

it depends on what EventRepository you are using. for DB-based like Olympia, information is keep, for InMemory* - doesn’t

you are right - the same as response on Scenario 2.

you can use the OnLoginNeeded event - it is fired only if SessionNotFoundException exception was raised on server-side and [re]login is required

5

Hi Evgeny,

I sent an email with the supertcp chat sample emulating the situation.

Usage:

Change the location of the olympia server to wherever you have one.

Start up the server (from Delphi IDE), start up 2 or more clients as regular executables.

Log them into the chat, chat something to verify all chats are getting messages.

Now STOP the process inside the Delphi IDE to force a crash without any normal exit strategy.

Re-start the Server from the IDE. Try to send a message from any of the clients, it will reconnect, but none of the clients will get a message. The server, having already persisted all the information regarding what event sinks and clients where connected should be able to restore its registrations unless the sessions had expired.

I dont know if I’m missing something, but if that is the expected behaviour (dont think so) it should definitely be changed to improve the SDK availability under problems.

Thank you.

6

thx for testcase.

in case of active event channels like superTCP, re-registration to events on server-side is required because this information isn’t keep in Olympia. it can be made via storing this info in session and reregistration to stored events in OnClientConnected event