Discussion on the problem of B/S judging browser disconnection_javascript skills

The client maintains the request through the script and the server. Each request refreshes a time. The server checks this time. If it is found that the time exceeds the predetermined time, it can be judged that the client browser has been closed. Then perform the corresponding operations. If you want to know which client browser was closed, you can bind the session to the polling object. Not all servers support long connections. This method is much more realistic than yours.
My personal opinion.
I first agree with these approaches . They can also achieve this requirement. They all update the last access time of the server through client polling and let the server detect timeout. Let me talk about my understanding of these two methods

1 How to judge the timeout on the server side and start a background thread for regular polling? Loop to check if each session exceeds the interval?
2 If threads are used, what is the interval or cycle judged by the server, 1 second, 10 seconds, 20 seconds...
3 If everyone uses a 10 second interval, the customer can also bear this interval, let's See the results
1) I don’t know which server does not support long connections. If you download a 100G file, wouldn’t it work? Do you have to disconnect n times in the middle?
2) Each of your clients needs to issue a new request within 10 seconds for the server to respond, but mine does not need to
3) Pay attention to concurrency issues during polling operations, that is, synchronous access The problem is that your data must be stored in the application or other custom global data structures, and multi-threading does not have this problem
4) Polling is single-threaded and processed uniformly, while long connections are multi-threaded
5) Disconnecting the client after each request refresh can reduce the number of connections occupied by the server and increase the number of concurrencies, but it relatively increases the burden of each request.
4 Key difference: If the request must be made within 0.1 seconds accurate Reaction, if the connection is found to be disconnected, it must be processed immediately. I think my multi-threaded solution will be more effective, because it is difficult for the browser to issue 10 requests in such a short period of time. For long connections, you only need to reduce the interval between sending data.



Summary:
Demands determine the application.
The shorter the judgment timeout required by the system, the greater the advantage of the long connection solution. The longer the time, the stronger the availability of polling. Specific decisions need to be made based on the application.
For general B/S judgment, most chat rooms and online population statistics are polling operations on the go. When a person leaves the chat room, the online list will not be updated immediately, but IM programs (QQ/MSN), etc. will be updated relatively accurately.

If you need to make an accurate judgment, I think long connection is one of the solutions I can think of; the other is client plug-ins, such as applet, Flash, ActiveX, etc. using socket, but the mechanism and long connection are not the difference.
Two tips

1. It's OK to achieve a 0.1 response, but it's not possible to achieve an "accurate" response of 0.1 seconds. Although the TCP protocol is a long-term connection, it does not stipulate that when one end of the CS is disconnected, the other end can quickly know it (otherwise there will be no "heartbeat" protocol that is not standard in TCP later). This is related to the support of the intermediate network hardware. This is also true in reality. Of course, I don’t know if the moderator may have written this article as well as the one above, so I don’t know what network this system is going to run on.

2. Since the article mentioned "previous page". It seems that this system should not be a QQ or game server. The background is probably running an ordinary WEB server, IIS or APACHE. . Their design goals are clear, so they will have a maximum number of connections. On the surface, it doesn't matter if thousands of people are online at the same time. Due to the short connection, the number of concurrencies at the same time is usually enough. But if the connection must be maintained even if the client is inactive, then this number will soon reach a dead limit.
Even games or IM tools, typically QQ, dare not use TCP to connect to the server for a long time.

So my conclusion is that if you plan to do a project where at most 1 or 2 hundred people will be online at the same time (rather than active at the same time), you can use the original poster’s method. If the number of people increases, including flash, activeX, socket... it will be impossible to use long connections, and it is better to use UDP.