Maintain ASP session Status

HTTP is a stateless protocol. When the client sends a request to the server, the server does not know whether this is the client's 1st or 42nd requests. This is a serious problem for ASP development, because it is often necessary to associate server variables with specific clients. For example, when a website sends my Jethro Tull CD to me and sends Barry Manilow CD to others, this association plays an important role. ASP processes this association through a unique customer identifier called the session ID. This session ID is assigned when the customer starts his or her browser session.

Now let's take a look at some problems existing in the use of traditional ASP and modern ASP. NET session IDs. Then, we will discuss the session issue when running multiple web servers.
What is session ID?

Session ID is a read-only value that uniquely identifies the client currently accessing the server. In the classic ASP environment, session IDs are allocated in order, that is, session IDs 706616433 are followed by session IDs 706616434. Traditional ASP session IDs are stored on the client in the form of encrypted, non-persistent cookies. For example, session ID 706616434 may be stored on the client as the cookie aspsessionidgqqgqgcs = jhmbobkcbinehlpkj1_abbe.

The session ID in ASP. NET varies. When ASP. NET is used, session ID is a 120-bit string consisting of valid ASCII characters of the URL. According to the instructions in Microsoft documents, the generated session ID value is unique.AlgorithmTo avoid session conflicts when two customers attempt to use the same ID. In addition, the randomness of session IDs makes it very difficult to determine the existing session IDs, resulting in additional security. Like traditional ASP, session IDs of ASP. NET are usually stored on the client as non-persistent cookies. The cookie format is slightly different from that of traditional ASP. For example, Asp.net _ sessionid = jhmbobkcbinehlpkj1_abbe.

In addition to the traditional, non-persistent cookie maintenance method, ASP. NET also supports session State maintenance mode that does not use cookies. When no cookie mode is enabled, ASP. NET embeds the session ID in the URL sent back to the client. In this way, session persistence is provided for customers who do not support cookies or disable cookie browsers. Considering the use of cookies to track customer information, we have reason to keep a high degree of attention to the non-Cookie mode.

How to Use session ID
Each time a customer sends a request, the cookie containing the encrypted session ID is sent to the server if it exists. The server then determines the session ID associated with the cookie and restores all session variables associated with the customer. If the cookie does not exist, a new session ID is generated, and the encrypted session ID cookie is sent to the client. In this way, ASP can track individual customers accessing the website. At the same time, the above mechanism also prompted ASP to establish the association between server-side session variables and a single session. Session variables are divided into two types:

Content set
Staticobject set
The contents collection session variables under ASP and ASP. NET are associated with specific customers based on session IDs. These variables are actually a union array, similar to the Collection object of Visual Basic. Session variables have the same principle. The only essential difference is that they are associated with a specific session. The Set object can store and retrieve any type of array members through a unique key.

A static object (staticobject) set contains a session range and is added to the application using the <Object> tag of Global. Asa.ProgramAll objects in. Like the content set, the staticobject set is also a union array, and its access method is the same. However, the staticobject set only contains objects instantiated with <Object>, and does not contain objects instantiated using the server. Createobject method.

Does a customer have only one session ID?
For a single web server, the maintenance status is automatic under any circumstances. The customer can obtain only one session ID, and the session information is maintained by the server as long as the website customer remains active. However, if there is more than one web server, or a separate application is located in a virtual directory where the directory resides in the virtual directory of other applications, maintenance becomes more complex.

When allocating session IDs, each server operates independently. Because of this, 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 customer request with a session ID 706616434, the request is processed as a Session Timeout, and web server a allocates a new session ID. In this case, the customer loses his/her status on Web Server B, and must start from scratch when repeated operations may occur. One way to avoid this problem is to ensure that all client requests are sent to the same server.

Running an application in a virtual directory is one of the ways to isolate and run multiple applications on the same web server. But remember, when an application calls another application, a new session ID is generated. In this way, 1st session IDs and all session variables associated with the storage are discarded. Depending on the specific circumstances of the application, the loss of status may not be a problem, but you must have a sufficient understanding of this problem when debugging sessions.

Summary
Is ASP sufficient to cope with the biggest challenges faced by creating persistent Web applications ?? Maintenance status. The ASP State maintenance mechanism allows developers to develop satisfactory applications without having to create their own proprietary State maintenance mechanism. Using ASP, careful planning in advance, coupled with hard work, may create a solid persistent application.