Discussion on browser disconnection judgment by B/S

The client uses scripts and the server to keep the request. Each request refresh a time. The server checks the time. If the time exceeds the specified time, it can be determined that the browser of the client is closed. Then perform corresponding operations. If you want to know that the client browser is closed, you can bind the session to the polling object. Persistent connections are not supported by all servers. This method is more realistic than you.
My personal opinion.
First, I agree with these practices.They can also achieve this. They all update the last access time of the server through the client round-robin, so that the server detection times out. Let me talk about my understanding of these two methods.

1. How does the server determine the timeout and start a background thread to perform regular polling? Check whether the interval of each session is exceeded cyclically?
2. If a thread is used, the server determines the interval or cycle, which is 1 second, 10 seconds, or 20 seconds ..
3. If you use a 10-second interval, the customer can afford the interval. Let's look at the result.
1) I still don't know which server does not support persistent connections. If you download a GB file, isn't it? Must I disconnect n times in the middle?
2) each of your clients needs to send a new request within 10 seconds for the server to respond.
3) Pay attention to the concurrency issue during polling operations, that is, synchronous access. Your data must be stored in the application or other custom global data structures, and multithreading does not.
4) Polling is a single thread for unified processing, while persistent connections are multithreading.
5) disconnecting after each request refresh on the client can reduce the number of connections that occupy the server and increase the number of concurrent connections, but this increases the burden on each request.
4Key differences:If you want0.1Required in secondsPrecisionIn response, it was found that the connection was disconnected and should be processed immediately. I think my multi-threaded solution will be more effective, because it is difficult for the browser to send 10 requests in that short time. For persistent connections, you only need to reduce the interval between data transmission.



Summary:
The requirement determines the application.
The shorter the timeout time required by the system, the greater the advantage of the persistent connection solution, the longer the time, and the stronger the availability of polling. Make a choice based on your application.
For the general B/S judgment, most chat rooms and online user statistics are on-line round robin. When a person leaves the chat room, the online list will not be updated immediately, but the IM program (QQ/MSN) will be updated relatively accurately.

If you need accurate judgment, I think persistent connection is one of the solutions I can think of; the other is the client plug-in, such as applet, Flash, ActiveX, etc, however, there is no difference between the mechanism and persistent connection.
Two tips

1. A 0.1 response is acceptable, but a 0.1-second "precise" response is not acceptable. Although the TCP protocol is a persistent connection, but it does not stipulate that when one end of CS is disconnected, the other end will be quickly known (otherwise there will be no "Heartbeat" protocol that is not standard for TCP later ), this is related to the support of intermediate network hardware. This is also true in reality. Of course, I don't know what else the moderator may have mentioned in this article, so I don't know on what network the system is going to run on.

2. The article mentioned "Previous Page ". It seems that this system should not be a QQ or game server, and the background may be running a common WEB server, IIS or APACHE .. Their design goals are clear, so there will be a limit on the maximum number of connections. On the surface, thousands of people are online at the same time. It doesn't matter. Due to the use of short connections, the concurrency at the same time is usually enough. However, even if the customer is not active and the connection needs to be maintained, the number of connections will soon be suspended.
Even games or IM tools, such as QQ, do not dare to use TCP for persistent connection to the server.

So my summary is that if you are going to launch a website with a maximum of people at the same time (rather than simultaneously active), you can use the method of the landlord. If the number of people increases, flash, activeX, socket... all cannot use persistent connections, and UDP is preferred.