HTTP is a stateless protocol. When a client sends a request to the server, the server does not know if this is the client's 1th or 42nd request. This poses a serious problem for ASP development because it is often necessary to associate a server-side variable with a particular client. For example, the site sends Barry Manilow CDs to other people while sending me the Jethro Tull CD I ordered because of the importance of this association. ASP handles this association through a unique customer identifier called the session ID, which is assigned when the customer starts his or her browser session.
Now let's look at some of the problems with traditional ASP and modern asp.net around the use of session IDs. Then, we discuss the session problem when running multiple Web servers.
What is a session ID
A session ID is a read-only value that uniquely identifies the customer who is currently accessing the server. In a classic ASP environment, session IDs are assigned sequentially, i.e. session ID 706616433 followed by session ID 706616434, and so on. Traditional ASP session IDs are stored on the client computer in the form of an encrypted, non-persistent cookie. For example, session ID 706616434 may be saved as a cookie Aspsessionidgqqgqgcs=jhmbobkcbinehlpkjhopabbe on the client.
Asp. NET, the session ID has changed. When using ASP.net, the session ID is a 120-bit string consisting of a URL-valid ASCII character. According to the Microsoft documentation, the resulting session ID value uses an algorithm that guarantees its uniqueness, thus avoiding a session conflict that occurs when two customers try to take the same ID. In addition, the randomness of the session ID makes it very difficult to determine the ID of an existing session, resulting in additional security. As with traditional ASP, ASP. NET session IDs are usually stored on the client computer as a non-persistent save cookie. This cookie format is slightly different than the traditional ASP, for example, Asp.net_sessionid=jhmbobkcbinehlpkjhopabbe.
In addition to maintaining the state of the traditional, non-persistent stored cookie method, ASP. NET also supports a session-state maintenance mode that does not use cookies. In the case where no cookie mode is enabled, ASP. NET embeds the join session ID in the URL that is sent back to the client. This provides session state persistence for customers who do not support cookies or disable cookie browsers. Given the use of cookies to keep track of customer information, we have reason to maintain a high level of concern over cookie-free mode.
How to use session IDs
Each request from the customer, a cookie containing the encrypted session ID is sent to the server if it exists. The server then determines the session ID that the cookie is associated with and recovers all session variables associated with the client. A new session ID is generated if the cookie does not exist, and the encrypted session ID cookie is sent to the client. This allows the ASP to track individual customers who visit the site. At the same time, the above mechanism also prompts ASP to establish the relationship between server-side session variables and single session. Session variables are divided into two types:
Content Collection
Static object (Staticobject) collection
The Content collection (Contents Collection) session variables under ASP and asp.net each associate a specific customer based on the session ID. These variables are actually a federated array, similar to the set of Visual Basic (Collection) objects. The principle of Session variables is exactly the same; the only essential difference is that they are associated with a particular session. Collection objects, however, can save and retrieve an array member of any type through a unique key.
The static object (Staticobject) collection contains the session-wide, global.asa <OBJECT> tags added to all objects in the application. Like a collection of content, the Staticobject collection is also a federated array and is accessed in the same way. However, the Staticobject collection contains only objects that are instantiated with <OBJECT> and do not contain objects that are instantiated with the Server.CreateObject method.
One client has only one session ID?
For a single Web server, the maintenance state is automatic in all cases. Customers get and only get a single session ID, and the session information is maintained by the server as long as the customer remains active on the site. However, maintaining state becomes more complex if the Web server is more than one, or if a separate application is in a virtual directory and the directory resides in the virtual directory of another application.
When you assign a session ID, each server operates independently. For this reason, Web Server A does not know that Web Server B has allocated session ID 706616434 to a customer. Therefore, if Web server A receives a client request with session ID 706616434, the request is treated as a session timeout, and Web Server A assigns a new session ID. When this happens, the customer loses its state on Web Server B, and must start from scratch if a repeat operation can occur. One way to avoid this problem is to ensure that all customers ' requests are sent to the same server.
Running an application under a virtual directory is one of the ways to implement isolation on multiple applications on the same Web server. But remember, when one application invokes another, a new session ID is generated. This discards the 1th session ID and all session variables for its associated store. Depending on the specifics of your application, the loss of status may not be a problem, but you must have sufficient knowledge of the problem when you debug the session.
Summary
is the ASP sufficient to meet the greatest challenges of creating a durable Web application?? Maintenance status. The ASP's state maintenance mechanism makes it possible for developers to develop satisfactory applications without creating their own proprietary state maintenance mechanisms. Using ASP, proactive planning, and hard work can create robust persistence applications.
