Equipment communication method and system based on browser and transit server

Abstract

The invention discloses a device communication method and system based on a browser and a transit server, the device communication system comprises a UDP device, the transit server and the browser, and the method comprises the following steps: the UDP device sends a registration request to the transit server for registration; bidirectional data flow connection is established between the browser and the transit server; the UDP device sends a UDP data packet to the transit server, and the transit server packages the UDP data packet and sends the packaged UDP data packet to the browser through bidirectional data stream connection; the browser sends an instruction to the transit server through the bidirectional data flow connection, the transit server converts the instruction into a UDP instruction packet, and the transit server forwards the UDP instruction packet to the UDP device. According to the invention, data transfer is carried out through the transfer server, the device and the browser, and the data is converted and transmitted in a UDP mode, so that the problems of high communication delay and high bandwidth consumption between the existing browser and the UDP device are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of network management, and particularly to a device communication method and system based on a browser and a relay server. Background Art

[0002] In the scenario of medical informatization, the information display screens in hospital corridors generally adopt a communication system based on the UDP protocol, and an end-to-end transmission delay of less than 300 ms is required. The traditional system architecture includes two core components, a control end and a display end. The control end uses an embedded system (such as a processor with an ARM architecture) or a dedicated PC software (developed with C++ / Qt), and sends control instructions through UDP broadcast. The display end is a display device equipped with a Linux embedded system, and receives and parses UDP data packets through socket programming.

[0003] With the development of Web technology, browsers have gradually become cross-platform control terminals. However, limited by the HTML5 security policy, browsers cannot directly create UDP socket connections. The existing indirect communication solution uses the WebSocket solution, and WebSocket depends on the TCP protocol, resulting in higher latency and bandwidth consumption, and cannot meet the low-latency requirements of medical scenarios, with significant defects. Summary of the Invention

[0004] To solve the above problems, the present invention provides a device communication method and system based on a browser and a relay server. The data is relayed between the relay server, the device, and the browser, and the data is converted to be transmitted via UDP, solving the problems of high communication latency and high bandwidth consumption between existing browsers and UDP devices.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] A device communication method based on a browser and a relay server, including a UDP device, a relay server, and a browser. The method includes the following steps:

[0007] The UDP device sends a registration request to the relay server for registration;

[0008] The browser establishes a two-way data stream connection with the relay server;

[0009] The UDP device sends a UDP data packet to the relay server, and the relay server encapsulates the UDP data packet and sends the encapsulated UDP data packet to the browser through the two-way data stream connection;

[0010] The browser sends instructions to the relay server through a bidirectional data stream connection. The relay server converts the instructions into UDP instruction packets and forwards the UDP instruction packets to the UDP device.

[0011] Further, the UDP device sends a registration request to the relay server for registration. The registration request includes a device ID and a device address. After receiving the registration request, the relay server establishes a data stream with the UDP device and assigns a session ID to the UDP device. Each UDP device corresponds to a unique session ID.

[0012] Further, the UDP device sends a heartbeat packet to the relay server at a preset period. When the relay server detects that any UDP device fails to send a heartbeat packet for more than a preset time, the UDP device is considered to have failed, and the registration information of the UDP device is cleared.

[0013] Further, the browser establishes a bidirectional data stream connection with the relay server. The specific implementation method is: the browser establishes a QUIC stream with the relay server through WebTransport.

[0014] Further, after the browser establishes a bidirectional data stream connection with the relay server, it also includes:

[0015] The browser sends a subscription request to the relay server. The subscription request includes the device ID of the UDP device. The relay server binds the data stream of the UDP device corresponding to the device ID to the QUIC stream.

[0016] Further, the relay server encapsulates the UDP data packet. The specific implementation method is: the relay server adds a metadata header to the UDP data packet and encapsulates it into a QUIC frame, and sends it to the browser through the QUIC stream. After receiving the QUIC frame, the browser returns an acknowledgment signal to the relay server. If the relay browser does not return an acknowledgment signal within a preset time after sending the QUIC frame, the QUIC frame is resent.

[0017] Further, the browser sends instructions to the relay server through a bidirectional data stream connection. The relay server converts the instructions into UDP instruction packets. The specific implementation method is: the browser transmits a QUIC frame to the relay server through the QUIC stream. The relay server extracts the metadata header from the QUIC frame and restores the QUIC frame to a UDP instruction packet.

[0018] Further, when the browser sends a subscription request to the relay server, it also includes: the subscription request includes a guarantee level, and the relay server selects a retransmission strategy according to the guarantee level in the subscription request.

[0019] Further, it further includes: when the relay server establishes a connection with the UDP device or the browser, generating a session recovery token and sending the session recovery token to the UDP device or the browser. When the UDP device or the browser reconnects after disconnection, it sends the session recovery token to the relay server, and the relay server directly establishes a connection according to the session recovery token.

[0020] Through the above technical solution, the present invention has the following beneficial effects: establishing a connection through WebTransport, thereby realizing end-to-end low-latency real-time communication between the browser and the UDP device, and the UDP communication reduces system resource consumption and provides a lightweight deployment solution without NAT traversal. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a schematic diagram of the overall process of a device communication method based on a browser and a relay server of the present invention.

[0022] Figure 2 It is a schematic diagram of the structure of a device communication system based on a browser and a relay server in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0023] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0024] To make the above objects, features, and advantages of the present invention more obvious and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0025] Example 1

[0026] See Figure 1 , a device communication method based on a browser and a relay server, including a UDP device, a relay server, and a browser. The method includes the following steps:

[0027] The UDP device sends a registration request to the relay server for registration;

[0028] The browser establishes a two-way data stream connection with the relay server;

[0029] The UDP device sends a UDP data packet to the relay server, and the relay server encapsulates the UDP data packet and sends the encapsulated UDP data packet to the browser through the two-way data stream connection;

[0030] The browser sends instructions to the relay server through a bidirectional data stream connection. The relay server converts the instructions into UDP instruction packets and forwards the UDP instruction packets to the UDP device.

[0031] In an optional embodiment, the UDP device sends a registration request to the relay server for registration. The registration request includes a device ID and a device address. After receiving the registration request, the relay server establishes a data stream with the UDP device and assigns a session ID to the UDP device. Each UDP device corresponds to a unique session ID.

[0032] After the UDP device starts, it sends a registration request to the relay server, including data such as a device ID, IP / port, etc. The server assigns a unique session ID and maintains a device status table for recording heartbeat time, network quality, etc.

[0033] In an optional embodiment, the UDP device sends a heartbeat packet to the relay server at a preset period. When the relay server detects that any UDP device has not sent a heartbeat packet for more than a preset time, it is considered that the UDP device has failed, and the registration information of the UDP device is cleared.

[0034] Specifically, the UDP device sends a heartbeat packet every 30 seconds. The server sets a timeout threshold. When the UDP device does not send a heartbeat packet for more than the timeout threshold, the failed device is automatically cleared. The detection timeout threshold is 120 seconds. By having the device send heartbeat packets regularly, the server can monitor the online status of the device in real time. After setting a 120 - second timeout threshold and automatically clearing the failed device, it can release server resources in a timely manner, avoid processing invalid data, and ensure efficient allocation of system resources and data accuracy.

[0035] In an optional embodiment, the browser establishes a bidirectional data stream connection with the relay server. The specific implementation method is: the browser establishes a QUIC stream with the relay server through WebTransport.

[0036] Since current browsers cannot directly create UDP socket connections and can only use the WebSocket solution that relies on the TCP protocol, this application uses WebTransport and the QUIC protocol. The browser can communicate with the UDP device in a low - latency and highly multiplexed manner. QUIC reduces the connection establishment time based on the characteristics of UDP, avoids TCP head - of - line blocking, and supports reliable or unreliable transmission. It combines TLS encryption to ensure security and can bypass network restrictions. At the same time, the congestion control and weak - network optimization of QUIC improve stability and are suitable for scenarios such as real - time audio and video, Internet of Things, etc., to achieve fast and flexible end - to - end communication between the browser and the device.

[0037] WebTransport provides secure, multiplexed real-time transport and already has APIs for sending data reliably and unreliably. In reliable data transfer, the sender is notified of the success or failure of the data transfer. Failed transfers are typically re-sent until successful, after which the next data packet is sent. In unreliable transfer, there is no confirmation of transfer success, and packets that are not received are not delivered at all. It focuses more on transfer speed, and minor data loss is acceptable.

[0038] In an optional embodiment, after the browser establishes a two-way data stream connection with the relay server, it further includes:

[0039] The browser sends a subscription request to the relay server. The subscription request includes the device ID of the UDP device, and the relay server binds the data stream of the UDP device corresponding to the device ID to the QUIC stream.

[0040] The relay server binds the device data stream to a specific browser session, which can achieve directional data transmission and permission control, ensure that the user only receives real-time information from authorized devices, and maintain the connection state by binding the data stream to build session associations, optimize resource allocation and reduce latency.

[0041] In an optional embodiment, the relay server encapsulates UDP data packets. The specific implementation method is: the relay server adds a metadata header to the UDP data packet and encapsulates it into a QUIC frame, and sends it to the browser through the QUIC stream. After receiving the QUIC frame, the browser returns an acknowledgment signal to the relay server. If the relay browser does not receive the acknowledgment signal within a preset time after sending the QUIC frame, it re-sends the QUIC frame.

[0042] QUIC is based on the UDP protocol, so there is no built-in packet guarantee mechanism. This retransmission strategy ensures that critical data is not lost by detecting timeouts and re-sending lost or delayed frames, thereby maintaining the integrity of communication, preventing data interruption or errors. In an unstable network environment, this mechanism allows the system to dynamically adjust the retransmission interval, helping the relay browser better cope with congestion, interference, or NAT / firewall issues, improving the overall transmission efficiency, rather than being overly conservative in retransmission like TCP.

[0043] In an optional embodiment, the browser sends an instruction to the relay server through the two-way data stream connection, and the relay server converts the instruction into a UDP instruction packet. The specific implementation method is: the browser transmits a QUIC frame to the relay server through the QUIC stream, and the relay server extracts the metadata header from the QUIC frame and restores the QUIC frame to a UDP instruction packet.

[0044] Since QUIC is based on the UDP protocol but adds a reliability layer, and the browser encapsulates data into QUIC frames according to this specification and sends them to the relay server. These frames contain metadata headers, which allow QUIC to handle packet loss, retransmission, and encryption without the browser directly operating on UDP. The relay server can quickly restore the UDP packets, which can effectively reduce latency and maintain low bandwidth overhead. At the same time, it solves the performance defects of WebSocket and provides an experience closer to native UDP.

[0045] In an optional embodiment, when the browser sends a subscription request to the relay server, it further includes: the subscription request includes a guarantee level, and the relay server selects a retransmission policy according to the guarantee level in the subscription request.

[0046] Specifically, the guarantee level includes two levels: unreliable and reliable. The reliable data stream is applicable to scenarios such as configuration instructions, and the unreliable data stream is applicable to scenarios such as real-time status updates. When it is detected that the browser or the UDP device times out without response and there is packet loss, if the guarantee level is the reliable level, then three retransmissions are performed at intervals of 50 ms, 100 ms, and 200 ms. If the guarantee level is unreliable, no processing is done and the data packet is directly discarded.

[0047] In an optional embodiment, it further includes: when the relay server establishes a connection with the UDP device or the browser, a session recovery token is generated and sent to the UDP device or the browser. When the UDP device or the browser reconnects after disconnection, the session recovery token is sent to the relay server, and the relay server directly establishes a connection according to the session recovery token.

[0048] After the device first establishes a secure connection with the server, the server will issue an encrypted session recovery token to the device, which contains the session key and parameters. When the device disconnects and reconnects, it can directly reuse this session recovery token to initiate a 0-RTT handshake without performing a full TLS handshake, thereby quickly restoring the session state and achieving efficient data transmission.

[0049] Example 2

[0050] See Figure 2 , a device communication system based on a browser and a relay server, including a UDP device, a relay server, and a browser. The method includes the following steps:

[0051] A device registration module, which is used to enable the UDP device to send a registration request to the relay server for registration;

[0052] A connection establishment module, which is used to establish a two-way data stream connection between the browser and the relay server;

[0053] A data sending module, which is used to enable a UDP device to send UDP data packets to a relay server. The relay server encapsulates the UDP data packets and sends the encapsulated UDP data packets to a browser through a bidirectional data stream connection;

[0054] An instruction sending module, which is used to enable the browser to send instructions to the relay server through the bidirectional data stream connection. The relay server converts the instructions into UDP instruction packets and forwards the UDP instruction packets to the UDP device.

[0055] The embodiments disclosed in this specification are only an illustration of the unilateral features of the present invention. The protection scope of the present invention is not limited to this embodiment, and any other functionally equivalent embodiments fall within the protection scope of the present invention. For those skilled in the art, various corresponding changes and deformations can be made according to the technical solutions and concepts described above, and all these changes and deformations should fall within the protection scope of the claims of the present invention.

Claims

1. A device communication method based on a browser and a relay server, characterized in that It includes a UDP device, a relay server, and a browser. The method includes the following steps: The UDP device sends a registration request to the relay server for registration; The browser establishes a two-way data stream connection with the relay server; The UDP device sends a UDP data packet to the relay server, and the relay server encapsulates the UDP data packet and sends the encapsulated UDP data packet to the browser through the two-way data stream connection; The browser sends an instruction to the relay server through the two-way data stream connection. The relay server converts the instruction into a UDP instruction packet and forwards the UDP instruction packet to the UDP device.

2. The device communication method based on a browser and a relay server according to claim 1, wherein The UDP device sends a registration request to the relay server for registration. The registration request includes a device ID and a device address. After receiving the registration request, the relay server establishes a data stream with the UDP device and assigns a session ID to the UDP device. Each UDP device corresponds to a unique session ID.

3. A device communication method based on a browser and a relay server according to claim 1, characterized in that The UDP device sends a heartbeat packet to the relay server at a preset period. When the relay server detects that any UDP device has not sent a heartbeat packet for more than a preset time, the UDP device is regarded as invalid, and the registration information of the UDP device is cleared.

4. A device communication method based on a browser and a relay server according to claim 1, characterized in that The browser establishes a two-way data stream connection with the relay server. The specific implementation method is: the browser establishes a QUIC stream with the relay server through WebTransport.

5. The device communication method based on a browser and a relay server according to claim 4, characterized in that, After the browser establishes a two-way data stream connection with the relay server, it further includes: The browser sends a subscription request to the relay server. The subscription request includes the device ID of the UDP device, and the relay server binds the data stream of the UDP device corresponding to the device ID to the QUIC stream.

6. The device communication method based on a browser and a relay server according to claim 5, wherein, The relay server encapsulates the UDP data packet. The specific implementation method is: the relay server adds a metadata header to the UDP data packet and encapsulates it into a QUIC frame, and sends it to the browser through the QUIC stream. After receiving the QUIC frame, the browser returns an acknowledgment signal to the relay server. If the relay browser does not receive an acknowledgment signal within a preset time after sending the QUIC frame, it resends the QUIC frame.

7. A device communication method based on a browser and a relay server according to claim 4, characterized in that, The browser sends an instruction to the relay server through the two-way data stream connection. The relay server converts the instruction into a UDP instruction packet. The specific implementation method is: the browser transmits a QUIC frame to the relay server through the QUIC stream. The relay server extracts the metadata header from the QUIC frame and restores the QUIC frame to a UDP instruction packet.

8. A device communication method based on a browser and a relay server according to claim 6, characterized in that, The browser sends a subscription request to the relay server, and it further includes: the subscription request includes a guarantee level, and the relay server selects a retransmission strategy according to the guarantee level in the subscription request.

9. The device communication method based on a browser and a relay server according to claim 1, wherein It further includes: When the relay server establishes a connection with the UDP device or the browser, it generates a session recovery token and sends the session recovery token to the UDP device or the browser. When the UDP device or the browser reconnects after disconnection, it sends the session recovery token to the relay server, and the relay server directly establishes a connection according to the session recovery token.

10. A device communication system based on a browser and a relay server, characterized in that, It includes a UDP device, a relay server, and a browser. The method includes the following steps: A device registration module, which is used to enable the UDP device to send a registration request to the relay server for registration; A connection establishment module, which is used to establish a two-way data stream connection between the browser and the relay server; A data sending module, which is used to enable the UDP device to send UDP data packets to the relay server, and the relay server encapsulates the UDP data packets and sends the encapsulated UDP data packets to the browser through the two-way data stream connection; An instruction sending module, which is used to enable the browser to send instructions to the relay server through the two-way data stream connection, the relay server converts the instructions into UDP instruction packets, and the relay server forwards the UDP instruction packets to the UDP device.

Images