A method and system for in-vehicle screen projection in a weak network environment based on P2P

Abstract

The present invention relates to the field of vehicle-mounted wireless screen projection technology, and specifically to a vehicle-mounted screen projection method and system in a weak network environment based on P2P; in this method, the server generates a QR code after the user logs in, and creates a sub-thread waiting for connection and a sub-thread receiving data; the user establishes a network connection with the server by scanning the QR code generated by the server on the client, and starts a sub-thread to monitor the data transmission rate; after the connection between the client and the server is established, the client sends the screen size information to the server; it is determined whether the client is a video playback type screen projection; in this solution, when playing video projection or screen recording projection in a weak network environment, the system can dynamically adjust the image encoding frame number, bit rate, encoding profile, and level sent by the client according to the data transmission rate to reduce transmission delay.

Description

Technical Field

[0001] The present invention relates to the field of vehicle-mounted wireless screen projection technology, and in particular to a vehicle-mounted screen projection method and system in a weak network environment based on P2P. Background Art

[0002] The mainstream wireless screen projection protocols currently used domestically and internationally include AirPlay, Miracast, DLNA, WiDi, WDHI, BJCsat, and lelink. Some of these protocols rely on hardware support, some are only applicable to proprietary products, and some can only be used on certain operating systems, with various limitations. Furthermore, in weak network conditions, client-side video projection and playback are prone to lag, delays, and network outages, significantly impacting the user experience.

[0003] As described in the rejected invention patent application "Low-Latency Screen Projection Method" with publication number CN107396172A, when the receiving end normally receives the complete stream fragment within the delay time threshold, the received stream fragment is directly passed to the player for decoding and playback, outputting the real-time image. When the delay time threshold is exceeded and the receiving end does not receive the complete stream fragment, it requests the sending end to resend the stream fragment, and stores the re-received stream fragment in the network jitter buffer for reordering before passing it to the player. However, this solution is mainly reflected in the video stream fragment timeout retransmission mechanism, and does not specify the systems under which it can be used. The usage conditions are high and the practical performance is poor. Summary of the Invention

[0004] In view of the shortcomings of the existing technology, the purpose of the present invention is to provide a P2P-based in-vehicle screen projection method and system in a weak network environment, which has a wide range of applications, low usage costs, can play videos and realize screen recording and projection in a weak network environment, and effectively improve user experience.

[0005] To solve the above technical problems, the present invention provides a technical solution: the in-vehicle screen projection method in a weak network environment based on P2P, which is applied to the client and the server, and includes the following steps:

[0006] (1) The user logs in to their account on the client and server respectively;

[0007] (2) The server generates a QR code after the user logs in and creates a sub-thread waiting for connection and a sub-thread receiving data;

[0008] (3) The user establishes a network connection with the server by scanning the QR code generated by the server on the client, and starts a sub-thread to monitor the data transmission rate;

[0009] (4) After the connection between the client and the server is established, the client sends the screen size information to the server;

[0010] (5) Determine whether the client is a video playback screen projection. If not, take a screenshot, encode the screenshot to obtain first encoded data, send the first encoded data to the server, and the server decodes the first encoded data and then projects the screen for display;

[0011] If yes, and the data transmission rate is ≥ the preset rate, the video is captured and encoded, and the number of frames sent is dynamically adjusted to obtain second encoded data, and the second encoded data is sent to the server. The server decodes the second encoded data, plays the video, and displays it on the screen;

[0012] If yes, and the data transmission rate is less than the preset rate, the client sends the URL information to the server, and the server downloads, plays the video and displays it on the screen according to the received URL information;

[0013] During the encoding process of step (5), the newly created protocol message format is followed. In the protocol message format, the message includes screen projection screen, video playback projection videohttp, video playback position control videopos, playback rate control videorate, playback volume control videovolume, playback state control videostate, client screen width and height rect, heartbeat command noop, client exit exit, debugging error code getlasterror, each command occupies 3 bits, timestamp occupies 14 bits, buflen size occupies 6 bits, and buf represents the encoded data of the screenshot.

[0014] In the above solution, when playing video projection or screen recording projection in a weak network environment, the image encoding frame number, bit rate, encoding profile, and level sent by the client can be dynamically adjusted according to the data transmission rate to reduce transmission delay.

[0015] Furthermore, in step (5), the server determines whether a corresponding video file exists locally based on the received URL information. If so, the server decodes and plays the video and displays it on the screen, thereby improving practical performance.

[0016] Furthermore, the client and the server are connected to a cloud server via the network at the same time, and the cloud server stores resource files available for screen projection.

[0017] Furthermore, in step (5), while the client is downloading the video through the cloud server, the server is playing the video, and the client and the server perform synchronous detection of the playing progress according to preset conditions.

[0018] Furthermore, if the client does not perform any operation, the screen is turned off, and a heartbeat command noop is sent every first preset time to maintain the connection;

[0019] If the server does not receive any data from the client within the second preset time, it executes the disconnection logic and redisplays the QR code interface to wait for the client to reconnect;

[0020] If the client does not receive a response feedback from the server within the third preset time, the client executes the disconnection logic and attempts to reconnect to the server every fourth preset time until reconnection is achieved.

[0021] The in-vehicle screen projection system based on P2P weak network environment is applied to the client and the server, and the system includes a client login module, a server login module, a client connection module, a server connection module, a client encoding module, and a server playback module;

[0022] The client login module is configured to provide users with a way to log in to their personal accounts on the client;

[0023] The server login module is configured to provide users with a way to log in to their personal accounts on the server;

[0024] A client connection module configured to establish a communication connection with the server;

[0025] A server connection module configured to establish a communication connection with a client;

[0026] A client encoding module configured to encode the client's image information and send it to the server;

[0027] The encoding follows the newly created protocol message format. The message includes screen projection (screen), video playback projection (videohttp), video playback position control (videopos), playback rate control (videorate), playback volume control (videovolume), playback state control (videostate), client screen width and height (rect), heartbeat command (noop), client exit (exit), and debug error code (getlasterror). Each command occupies 3 bits, timestamp occupies 14 bits, buflen occupies 6 bits, and buf represents the encoded data of the screenshot.

[0028] The server-side playback module is configured to decode the code received from the client and display it on the screen.

[0029] In the above solution, when playing video projection or screen recording projection in a certain environment, the number of image encoding frames, bit rate, encoding profile, and level sent by the client can be dynamically adjusted according to the data transmission rate to reduce transmission delay.

[0030] Furthermore, the client encoding module first determines whether the client is a video playback screen projection, and if not, takes a screenshot, encodes the screenshot to obtain first encoded data, and sends the first encoded data to the server. The server playback module decodes the first encoded data and then projects the screen for display;

[0031] If yes, and the data transmission rate is greater than or equal to the preset rate, the video is captured and encoded, and the number of frames sent is dynamically adjusted to obtain second encoded data, and the second encoded data is sent to the server. The server playback module decodes the second encoded data, plays the video, and displays it on the screen;

[0032] If so, and the data transmission rate is less than the preset rate, the client sends the URL information to the server, and the server playback module downloads and plays the video and displays it on the screen based on the received URL information.

[0033] Furthermore, the server-side playback module determines whether a corresponding video file exists locally based on the received URL information. If so, the video is decoded, played, and displayed on the screen.

[0034] Furthermore, the client and server are simultaneously connected to the cloud server, which stores resource files available for screen projection. While the client encoding module downloads the video through the cloud server, the server playback module plays the video, and the client and server perform synchronous detection of the playback progress according to preset conditions.

[0035] Furthermore, if the client does not perform any operation, the screen is turned off, and a heartbeat command noop is sent every first preset time to maintain the connection;

[0036] If the server does not receive any data from the client within the second preset time, it executes the disconnection logic and redisplays the QR code interface to wait for the client to reconnect;

[0037] If the client does not receive a response feedback from the server within the third preset time, the client executes the disconnection logic and attempts to reconnect to the server every fourth preset time until reconnection is achieved.

[0038] Compared with the existing technology, this solution has the following significant advantages:

[0039] This solution designs a new message format. For client screen recording and projection, it adopts a corresponding low-latency video playback strategy and adaptively adjusts the sent projection image encoding frame data according to the data transmission rate, reducing transmission delay and lag, and supports automatic reconnection and restoration of projection after disconnection. For client playback of video projection, it uses the cloud server to download and play simultaneously, and the playback progress is synchronously detected at both ends, effectively improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings:

[0041] Figure 1 This is a flowchart of the steps of the vehicle screen projection method in an embodiment of the present invention;

[0042] Figure 2 This is a schematic diagram of the Hongqilink protocol message format in this embodiment;

[0043] Figure 3 This is a schematic diagram of the module structure of the vehicle-mounted screen projection system in an embodiment of the present invention. DETAILED DESCRIPTION

[0044] The preferred embodiments of the present invention are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention and are not used to limit the present invention.

[0045] The mainstream wireless screen projection protocols currently available domestically and internationally include AirPlay, Miracast, DLNA, WiDi, WDHI, BJCsat, and lelink. AirPlay is a wireless technology developed by Apple that allows wireless streaming of audio, video, and images from iOS devices like iPhones and iPads to AirPlay-enabled devices via Wi-Fi. AirPlay only works with Apple products or authorized products within the same local area network.

[0046] The Miracast protocol was developed by the Wi-Fi Alliance and is a wireless screen projection protocol based on WiFi connection. Miracast wireless screen projection is the most widely compatible screen projection protocol, but this protocol does not support non-Android phones and smart TVs and requires the support of network cards, graphics cards and drivers to use.

[0047] The DLNA protocol is a set of interconnection protocols between PCs, mobile devices, and consumer electronics initiated by Sony, Intel, Microsoft, etc., which can project multimedia files to TVs or projectors. The DLNA protocol will no longer be updated since 2017.

[0048] WiDi is a way to support wireless screen projection on Windows 10 laptops. It can achieve wireless screen projection without installing software, but it depends on hardware support.

[0049] The WDHI protocol is an HDMI transmission solution that can achieve lossless transmission, but it is relatively expensive, the transmitter needs independent power supply, and requires barrier-free transmission.

[0050] Some of the mainstream screen projection protocols mentioned above rely on hardware support, some only work with their own products, and some only work on certain operating systems, resulting in various limitations. Furthermore, in weak network conditions, client-side video playback and projection may experience freezes, delays, and network interruptions, significantly impacting the user experience.

[0051] This solution proposes a P2P-based in-vehicle screen projection method and system in a weak network environment. It does not require the installation of new hardware or data cables and is not limited to operating systems such as Windows, iOS, Android, and Linux. The client and server are the same APP application. Screen projection can be used as long as both ends are connected to the Internet at the same time. It has a wide range of applications and low implementation costs.

[0052] Specifically, such as Figure 1 As shown, the in-vehicle screen projection method based on P2P in a weak network environment of the present invention is applied to the client and the server, and the method includes the following steps:

[0053] (1) The user logs in to their account on the client and server respectively;

[0054] (2) The server generates a QR code after the user logs in, and creates a connection waiting sub-thread and a data receiving sub-thread;

[0055] (3) The user establishes a network connection with the server by scanning the QR code generated by the server on the client, and starts a sub-thread to monitor the data transmission rate;

[0056] (4) After the connection between the client and the server is established, the client sends the screen size information to the server;

[0057] (5) Determine whether the client is a video playback screen projection. If not, take a screenshot, encode the screenshot to obtain first encoded data, send the first encoded data to the server, and the server decodes the first encoded data and then projects the screen for display;

[0058] If yes, and the data transmission rate is greater than or equal to the preset rate, the video is captured and decoded, and the number of frames sent is dynamically adjusted to obtain second encoded data, and the second encoded data is sent to the server. The server decodes the second encoded data, plays the video, and displays it on the screen;

[0059] If yes, and the data transmission rate is less than the preset rate, the client sends the URL information to the server, and the server downloads, plays the video and displays it on the screen according to the received URL information;

[0060] The above-mentioned preset rate is 3 Mbps in this embodiment. In actual use, the higher the preset rate, the better the effect, but it is basically not lower than 3 Mbps.

[0061] Among them, in the encoding process of step (5), the newly created hongqilink screen projection protocol message format of this scheme is followed. In the protocol message format, the message includes screen projection screen, video playback projection videohttp, video playback position control videopos, playback rate control videorate, playback volume control videovolume, playback state control videostate, client screen width and height rect, heartbeat command noop, client exit exit, debugging error code getlasterror, each command occupies 3 bits, timestamp occupies 14 bits, buflen size occupies 6 bits, buf represents the encoded data of the screenshot, specifically as follows Figure 2 shown.

[0062] The design principle of this message is to use as few bytes as possible and allow a certain packet loss rate. Because screen recording and projection continuously send compressed images and refresh the display in an overlay manner, a certain packet loss rate is allowed to meet low latency in weak network conditions and ensure user experience.

[0063] In step (5), the server determines whether the corresponding video file exists locally based on the received URL information. For example, before screen projection, the server copies the video file to the server or caches the video file locally. If it exists, the server directly decodes and plays the video and projects it for display.

[0064] The client and server are connected to a cloud server that stores resource files for screen projection. While the client is downloading the video from the cloud server, the server is playing the video. The client and server can provide feedback on the playback progress according to preset conditions, in this embodiment, every second, to perform synchronization detection of the playback progress.

[0065] If there is no operation on the client, the screen is turned off, and a heartbeat command noop is sent every first preset time, which is 5 seconds in this embodiment, to maintain the connection.

[0066] If the server does not receive any data sent by the client within the second preset time, which is 10 seconds in this embodiment, the server executes the disconnection logic and redisplays the QR code waiting interface to wait for the client to reconnect.

[0067] If the client does not receive a response feedback from the server within the third preset time, which is 10 seconds in this embodiment, the disconnect logic is executed, and attempts to reconnect to the server every fourth preset time, which is 3 seconds in this embodiment, until reconnection.

[0068] The QR code can be generated using the open source QRcode library. A QR code image is generated based on the IP address and port number. The client can scan the code and obtain the IP address and port number to establish a network connection.

[0069] The client starts a sub-thread to monitor the data sending rate. When the client takes screenshots or projects the screen in a weak network environment, it is necessary to dynamically adjust the number of frames and frame rate of compressed images sent per second according to the data sending rate, thereby reducing the data volume of the message.

[0070] For screen recording and projection, you can use the cross-platform OpenGI, and for video playback, you can use a library based on ffmpeg. For example, the Android system can use ijkplayer to play videos.

[0071] In the above solution, a new message format is designed. For client screen recording and projection, a corresponding low-latency video playback strategy and adaptive adjustment of the sent projection image encoding frame data are adopted according to the data transmission rate to reduce transmission delay and lag, and support automatic reconnection and restoration of projection after disconnection. For client playback of video projection, the cloud server is used to download and play at the same time, and the playback progress is synchronously detected at both ends, which effectively improves the user experience.

[0072] like Figure 3 As shown, the in-vehicle screen projection system based on P2P in a weak network environment of the present invention is applied to the client and the server, and the system includes a client login module, a server login module, a client connection module, a server connection module, a client encoding module, and a server playback module;

[0073] The client login module is configured to provide users with a way to log in to their personal accounts on the client;

[0074] The server login module is configured to provide users with a way to log in to their personal accounts on the server;

[0075] A client connection module configured to establish a communication connection with the server;

[0076] A server connection module configured to establish a communication connection with a client;

[0077] A client encoding module configured to encode the client's image information and send it to the server;

[0078] The encoding follows the newly created protocol message format. The message includes screen projection (screen), video playback projection (videohttp), video playback position control (videopos), playback rate control (videorate), playback volume control (videovolume), playback state control (videostate), client screen width and height (rect), heartbeat command (noop), client exit (exit), and debug error code (getlasterror). Each command occupies 3 bits, timestamp occupies 14 bits, buflen occupies 6 bits, and buf represents the encoded data of the screenshot.

[0079] The server-side playback module is configured to decode the code received from the client and display it on the screen.

[0080] Specifically, the client encoding module first determines whether the client is a video playback type screen projection. If not, it takes a screenshot, encodes the screenshot to obtain first encoded data, and sends the first encoded data to the server. The server playback module decodes the first encoded data and then projects the screen for display.

[0081] If yes, and the data transmission rate is greater than or equal to the preset rate, the video is captured and encoded, and the number of frames sent is dynamically adjusted to obtain second encoded data, and the second encoded data is sent to the server. The server playback module decodes the second encoded data, plays the video, and displays it on the screen;

[0082] If so, and the data transmission rate is less than the preset rate, the client sends the URL information to the server, and the server playback module downloads and plays the video and displays it on the screen based on the received URL information.

[0083] The above-mentioned preset rate is 3 Mbps in this embodiment. In actual use, the higher the preset rate, the better the effect, but it is basically not lower than 3 Mbps.

[0084] The server-side playback module determines whether the corresponding video file exists locally based on the received URL information. If so, it decodes, plays the video and displays it on the screen.

[0085] The client and server are connected to a cloud server, which stores resource files available for screen projection. While the client encoding module downloads the video from the cloud server, the server playback module plays the video. The client and server can provide feedback on playback progress based on preset conditions (in this embodiment, every second), performing synchronous playback progress detection.

[0086] If there is no operation on the client, the screen is turned off, and a heartbeat command noop is sent every first preset time, which is 5 seconds in this embodiment, to maintain the connection.

[0087] If the server does not receive any data sent by the client within the second preset time, which is 10 seconds in this embodiment, the server executes the disconnection logic and redisplays the QR code waiting interface to wait for the client to reconnect.

[0088] If the client does not receive a response feedback from the server within the third preset time, which is 10 seconds in this embodiment, the disconnect logic is executed, and attempts to reconnect to the server every fourth preset time, which is 3 seconds in this embodiment, until reconnection.

[0089] The QR code can be generated using the open source QRcode library. A QR code image is generated based on the IP address and port number. The client can scan the code and obtain the IP address and port number to establish a network connection.

[0090] The client starts a sub-thread to monitor the data sending rate. When the client takes screenshots or projects the screen in a weak network environment, it is necessary to dynamically adjust the number of frames and frame rate of compressed images sent per second according to the data sending rate, thereby reducing the data volume of the message.

[0091] For screen recording and projection, you can use the cross-platform OpenGI, and for video playback, you can use a library based on ffmpeg. For example, the Android system can use ijkplayer to play videos.

[0092] In the above solution, a new message format is designed. For client screen recording and projection, a corresponding low-latency video playback strategy and adaptive adjustment of the sent projection image encoding frame data are adopted according to the data transmission rate to reduce transmission delay and lag, and support automatic reconnection and restoration of projection after disconnection. For client playback of video projection, the cloud server is used to download and play at the same time, and the playback progress is synchronously detected at both ends, which effectively improves the user experience.

[0093] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art will be able to modify the technical solutions described in the aforementioned embodiments or substitute equivalents for some of the technical features. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A method for in-vehicle screen projection in a weak network environment based on P2P, characterized in that: The method is applied to the client and the server, and includes the following steps: (1) The user logs in to their account on the client and server respectively; (2) The server generates a QR code after the user logs in, and creates a sub-thread waiting for connection and a sub-thread receiving data; (3) The user establishes a network connection with the server by scanning the QR code generated by the server on the client, and starts a sub-thread to monitor the data transmission rate; (4) After the client and the server establish a connection, the client sends screen size information to the server; (5) determining whether the client is a video playback screen projection device; if not, taking a screenshot, encoding the screenshot to obtain first encoded data, and sending the first encoded data to the server; the server decodes the first encoded data and then projects the screen for display; If yes, and the data transmission rate is greater than or equal to the preset rate, the video is captured and encoded, and the number of frames sent is dynamically adjusted to obtain second encoded data, and the second encoded data is sent to the server. The server decodes the second encoded data, plays the video, and displays it on the screen; If yes, and the data transmission rate is less than the preset rate, the client sends the URL information to the server, and the server automatically downloads and plays the video and displays it on the screen according to the received URL information; During the encoding process of step (5), the newly created protocol message format is followed. In the protocol message format, the message includes screen projection screen, video playback projection videohttp, video playback position control videopos, playback rate control videorate, playback volume control videovolume, playback state control videostate, client screen width and height rect, heartbeat command noop, client exit exit, debugging error code getlasterror, each command occupies 3 bits, timestamp occupies 14 bits, buflen size occupies 6 bits, and buf represents the encoded data of the screenshot.

2. The method for in-vehicle screen projection based on P2P in a weak network environment according to claim 1 is characterized in that: In step (5), the server determines whether a corresponding video file exists locally based on the received URL information. If so, the server decodes and plays the video and displays it on the screen.

3. The method for in-vehicle screen projection based on P2P in a weak network environment according to claim 1, characterized in that: The client and the server are connected to a cloud server through a network at the same time, and the cloud server stores resource files available for screen projection.

4. The method for in-vehicle screen projection in a weak network environment based on P2P according to claim 3 is characterized in that: In step (5), while the client is downloading the video through the cloud server, the server is playing the video, and the client and the server perform synchronous detection of the playing progress according to preset conditions.

5. The method for in-vehicle screen projection based on P2P in a weak network environment according to claim 4 is characterized in that: If the client does not perform any operation, the screen is turned off, and the heartbeat command noop is sent every first preset time to maintain the connection; If the server does not receive any data sent by the client within the second preset time, the server executes the disconnection logic and redisplays the QR code interface to wait for the client to reconnect; If the client does not receive a response feedback from the server within the third preset time, the client executes the disconnection logic and attempts to reconnect to the server every fourth preset time until reconnection is achieved.

6. A vehicle-mounted screen projection system based on P2P in a weak network environment, characterized by: The system is used to implement the in-vehicle screen projection method based on P2P in a weak network environment according to any one of claims 1 to 5. The system is applied to the client and the server, and includes a client login module, a server login module, a client connection module, a server connection module, a client encoding module, and a server playback module; The client login module is configured to provide a user with a way to log in to a personal account on the client; The server login module is configured to provide a user with a way to log in to a personal account on the server; The client connection module is configured to establish a communication connection with the server; The server connection module is configured to establish a communication connection with the client; The client encoding module is configured to encode the image information of the client and send it to the server; The encoding follows a newly created protocol message format. In the protocol message format, the message includes screen projection (screen), video playback projection (videohttp), video playback position control (videopos), playback rate control (videorate), playback volume control (videovolume), playback state control (videostate), client screen width and height (rect), heartbeat command (noop), client exit (exit), and debugging error code (getlasterror). Each command occupies 3 bits, timestamp occupies 14 bits, buflen size occupies 6 bits, and buf represents the encoded data of the screenshot. The server-side playback module is configured to decode the code received from the client and display it on the screen.

7. The vehicle-mounted screen projection system based on P2P in a weak network environment according to claim 6 is characterized in that: The client encoding module first determines whether the client is a video playback screen projection. If not, it takes a screenshot, encodes the screenshot to obtain first encoded data, and sends the first encoded data to the server. The server playback module decodes the first encoded data and then projects the screen for display; If yes, and the data transmission rate is greater than or equal to the preset rate, the video is captured and encoded, and the number of frames sent is dynamically adjusted to obtain second encoded data, and the second encoded data is sent to the server. The server playback module decodes the second encoded data, plays the video, and displays it on the screen; If so, and the data transmission rate is less than the preset rate, the client sends the URL information to the server, and the server playback module automatically downloads and plays the video and displays it on the screen according to the received URL information.

8. The vehicle-mounted screen projection system based on P2P in a weak network environment according to claim 7 is characterized in that: The server-side playback module determines whether a corresponding video file exists locally based on the received URL information. If so, it decodes, plays the video, and displays it on the screen.

9. The vehicle-mounted screen projection system based on P2P in a weak network environment according to claim 7 is characterized in that: The client and the server are simultaneously connected to a cloud server via the network. The cloud server stores resource files that can be used for screen projection. While the client encoding module downloads the video through the cloud server, the server playback module plays the video, and the client and the server perform synchronous detection of the playback progress according to preset conditions.

10. The vehicle-mounted screen projection system based on P2P in a weak network environment according to claim 9 is characterized in that: If the client does not perform any operation, the screen is turned off, and the heartbeat command noop is sent every first preset time to maintain the connection; If the server does not receive any data sent by the client within the second preset time, the server executes the disconnection logic and redisplays the QR code interface to wait for the client to reconnect; If the client does not receive a response feedback from the server within the third preset time, the client executes the disconnection logic and attempts to reconnect to the server every fourth preset time until reconnection is achieved.

Images