Real-time Iot problem: client Socket programming in B/S architecture? -

I am involved in an Iot project, from the underlying PLC to the server, and then to the customer PC for real-time monitoring. If you want the client to implement cross-platform as much as possible, you need to consider implementing the BS architecture. However, the BS architecture has a very obvious defect, that is, you cannot establish a persistent connection to display real-time data, do you have any good ideas or solutions for mutual analysis and discussion. Some research and consideration have been made to use HTML5 on the client side, but the popularity of html5. If the description is not weekly, please forgive me. We hope this will be conducive to the future implementation of the IOT project. ------------- I am involved in an Iot project, from the underlying PLC to the server, and then to the customer PC for real-time monitoring. If you want the client to implement cross-platform as much as possible, you can consider the implementation of the B/S architecture. However, the B/S architecture has a very obvious defect, that is, you cannot establish a persistent connection to display data in real time, do you have any good ideas or solutions for mutual analysis and discussion.
Some research and consideration have been made to use HTML5 on the client side, but the popularity of html5.
If the description is not weekly, please forgive me. We hope this will be conducive to the future implementation of the IOT project.
--------------------------------
Do you know the advantages and disadvantages of html5?
--------------------------------
The answer and our current solution have been unified:
Web Front-end uses HTML5 to implement websocket. Earlier browsers use flash or Socket. IO Websocket communication.
The server also implements websocket.
--------------------------------
I read the title again and want to explain why it is client Socket programming in B/S architecture?
The biggest advantage of the B/S structure is that it can be operated anywhere without installing any special software. . Cross-platform development is an important factor in client development in the future.
The Development Trend of Iot systems is to perfectly combine the advantages of B/S and C/S. That is to say, Iot application systems can be released and run in the form of B/S, at the same time, it is highly operable in the C/S mode.
In the future, Iot is a big data era. The client will display data, and data analysis must be placed on backend servers. Therefore, Web Broswer is a good method, however, Iot also has real-time control and data display problems, such as calling remote cameras and fire alarms at home. This is what the HTTP protocol currently cannot do. Therefore, the Socket method is required to ensure real-time performance.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~
I am afraid to express my humble opinions on the Internet of Things. I hope you can correct the mistakes. Reply content: Suppose you write a Javascript Applet and send an HTTP request every 1 s to get data at the same URL, you may naturally think that this will lead to repeated connection establishment for sending and receiving, which is not good.

But in fact, HTTP 1.1 enables the Keep-Alive feature by default and allows connection reuse. That is to say, if your browser is not too old, this kind of polling program is actually more efficient than you think-because only when you send the request for the first time will you establish a connection for you, and then you will continue to send the request to use the same connection first. Therefore, persistent connections have been implemented for a long time. And is not even realized by programmers.

The problem you encounter is not a "persistent connection" problem, but a "Push/pull" problem of data. That is to say, what you really want is that the server can ActiveContinuously send data to the client, which is exactly the weakness of the HTTP protocol. This is also an important reason why websocket exists.

One way is to use http://socket.io And so on. Another solution that is easily overlooked is to use an improved round-robin solution: comet.

Of course, I don't know the traffic per unit time of the data that you need to display in real time, and the latency adequacy, so I can't provide suggestions for other aspects. In fact, flash plug-ins can be combined to support websocket browsers,
1. flash can enable socket link. embed an invisible flash on the page, and the receiving message logic is encapsulated here. Then, the javascript and flash are used for message interaction.
2. If the browser supports websocket, websocket is preferred. The message interface can be defined. Websocket
To be compatible with older browsers, consider http://socket.io And so on. Take a look at this figure.

Http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet Http://socket.io .
As for compatibility issues, do we have to make things that are cutting-edge in the Internet of Things? Do we still have to push forward technological advances. 1. For more information about the round-robin method, see @ Lin Jian's answer.

2. the pseudo-persistent connection mode is also called the persistent polling mode. After the client is linked to the server, the server should not be disconnected. The trunk mode is used to output data, similar to the status in which the page has not been loaded. If the client finds that the link is disconnected by the gateway, it will reconnect. The server can also implement the push mechanism. Early web chat rooms were basically implemented in this way.
Supplement: Earlier web pages used long polling in iframe mode, while new requests were in Ajax mode. After reading the web chat, this mode is also used. This mode has the best browser compatibility.

3. websocket

4. browser plug-ins

Supplement: For details, see
Comet (programming)