Let’s talk about the purpose of this mechanism first. Until now, Battlefield knows that this mechanism has two uses:
First of all, the problem of multi-server sharing session, everyone should be able to understand this. When a website If the number of users is too large, a server cluster will be used, for example, a dedicated server for login. After the user logs in through the login server, the login server saves the user's login information session, and other accessed servers, such as the movie server, do not have this session, then we have to share this session through a unique identifier of the session - the specific session The sharing is beyond the scope of this article, please check the information yourself.
The second purpose is to verify different sessions of the same user, which is more difficult to understand. Let's put it this way, when a user does not request a connection through a browser, but requests data through a socket or other methods, we must first perform user login verification on him. After the verification is successful, we will issue a sessionid to him, and then He carries this sessionid every time he makes a request. We use this sessionid to determine whether the session already exists. If it exists, we assume that the user has logged in...
For the first question, we can save the sessionid in It can be implemented in the database. This method is relatively safe and widely used, but it is not the scope of our discussion
The second question is actually very simple. Take a look at the code
When verifying it first Generate a sessionid;