ESFramework 4.0 Quick Start (07) -- Re-login Mode

In the ESFramework framework, TCP-based server engines (including the Rapid engine) all adopt the following rule: by default, after a TCP connection is established between the client and the server, the server extracts the UserID attribute value of the message header from the first message sent by the client and binds it to the corresponding TCP connection. In this way, the server will know the user UserID corresponding to each TCP connection. When we ask the server to send a message to a client, the server will know which TCP connection is used to send the message. The TCP connection corresponds to the UserID one by one. a tcp connection can only correspond to one UserID. Similarly, a UserID can have one TCP connection at most.

 

I. Two logon Modes

In reality, this often happens: for example, if we use QQ, when we log on to location A with an account, it has not been deprecated yet, what happens when I use this account to log on to B? QQ uses A new connection to replace the old connection, that is, it notifies the client in the region that it has been congested (for example, the prompt "users with the same name have logged on elsewhere "), for subsequent communication, the server will be connected to the client of B.

This mode adopted by QQ is called the ReplaceOld mode in ESFramework. However, some applications may need to keep the connection of location A and ignore the connection of the new location B. In this case, we can adopt another mode: IgnoreNew. ESFramework defines the two modes through RelogonMode enumeration:

/// <Summary>
/// Re-login mode. When a user with the same name is received from another new connection, the User Manager processes the old connection.
/// </Summary>
Public enum RelogonMode
{
/// <Summary>
/// Ignore the new connection.
/// </Summary>
IgnoreNew = 0,

/// <Summary>
/// Replace the old connection with a new connection.
/// </Summary>
ReplaceOld
}

We can set the RelogonMode attribute of the User Manager IUserManager to control which re-login mode ESFramework adopts.

 

Ii. ESFramework's response to the two logon Modes

1. IgnoreNew Mode

If we adopt the IgnoreNew mode, when the server receives a message from a user with the same name from another new connection, ESFramework will trigger the NewConnectionIgnored event of IUserManager to notify the server application:

Event CbGeneric <string, IUserAddress> NewConnectionIgnored;

 

The first parameter string of the event is the ID of the user with the same name, and the second parameter is the client address of the new connection.

What should I do if the server has to schedule and handle this event? Generally, there are two things that must be done:

(1) notify the client corresponding to the new connection that a user with the same name is online, and the new connection will be closed.

(2) Close the new connection.

 

2. ReplaceOld Mode

If we adopt the ReplaceOld mode, when the server receives a message from a user with the same name from another new connection, ESFramework will trigger the SomeOneBeingPushedOut event of IUserManager to notify the server application:

Event CbGeneric <UserData> SomeOneBeingPushedOut;

That is, the client corresponding to the old connection with the same name is squeezed out, and the event parameter contains the relevant information of the old connection.

Correspondingly, the server must also schedule and process the event, and there are two things that must be done:

(1) notify the client corresponding to the old connection that there is a user connection with the same name, and the old connection will be closed.

(2) Close the old connection.

 

Iii. ESPlus makes the application of the re-login mode easier

The ESPlus. Application. Basic namespace in ESPlus processes all the things that the server must do when the above mentioned IgnoreNew mode or ReplaceOld mode is used. For example, the notification (New/old) client closes the (new/old) TCP connection.

The ESPlus. Application. Basic. Server. BasicMessageProcesser class predefines the NewConnectionIgnored and SomeOneBeingPushedOut events of IUserManager, notifies the client in the event processing function, and closes the connection to be closed.

So how does the client application know the notifications sent from the server?

When the relevant notifications are received by the Client Engine, ESPlus calls back the OnBeingPushedOut method of the ESPlus. Application. Basic. Passive. IBasicBusinessHandler interface or the OnHaveLogonNotify method:

/// <Summary>
/// OnBeingPushedOut is dropped by a user with the same name. At this time, the client engine has been Dispose.
/// Occurs in RelogonMode. ReplaceOld.
/// </Summary>
Void OnBeingPushedOut ();

/// <Summary>
/// Onhavelogonpolicy this method is called when a user with the same name has logged on and the current connection has been ignored (disabled by the server. At this time, the client engine has been Dispose.
/// Occurs in RelogonMode. IgnoreNew.
/// </Summary>
Void OnHaveLogonNotify ();

Therefore, as long as the client implements the two methods of the IBasicBusinessHandler interface, it can receive the notification that the user has been congested or logged on to the client with the same name.

 

Iv. Rapid engine and re-login Mode

The Rapid engine that supports ESFramework quick development uses the ESPlus just introduced. application. in the Basic namespace, all components related to the re-login processing have been automatically assembled. Therefore, the client only needs to implement the two methods of the IBasicBusinessHandler interface mentioned above to receive notifications from the server.

The Rapid engine uses the ReplaceOld mode by default. However, you can use a statement similar to the following to set the relogon mode of IUserManager to the IgnoreNew mode.

(IUserManager) rapidServerEngine. UserManager). RelogonMode = RelogonMode. ReplaceOld;

 

ESFramework 4.0 Overview

All articles in ESFramework 4.0 Quick Start

All articles in ESFramework 4.0 advanced edition Series