A private domain service penetration request method and system based on a micro-service gateway

Abstract

The application provides a private domain service penetration request method and system based on a micro-service gateway, which comprises the following steps: S1: a local micro-service gateway sends a registration request to a gateway relay service module and is authenticated by a micro-service gateway management service module; S2: when a public cloud service sends a request to a private domain intranet service, the public cloud micro-service gateway sends the request to the gateway relay service module, the gateway relay service controls signaling to be forwarded to the local micro-service gateway according to a routing key carried by the request; S3: after receiving the control signaling sent by the relay service, the local micro-service gateway sends a request to pull the request content of the public cloud service according to the control signaling parameters, and then forwards the request to the private domain service; S4: after the private domain service processes the request of the public cloud service, the response content is pushed to the gateway relay service module through the local micro-service gateway, then the response content is relayed and forwarded to the public cloud micro-service gateway, and finally the response content is forwarded to the public cloud service.

Description

Technical Field

[0001] This invention relates to a microservice gateway, and more particularly to a method and system for private domain service penetration requests based on a microservice gateway. Background Technology

[0002] Currently, local private domains can provide public domain names to enable data transmission between the local private domain and public cloud services, thus solving the passive data backhaul application scenario. However, maintaining the public domain name entry point involves domain names, certificates, security, etc., which is costly. Alternatively, the local private domain can actively poll the public cloud API interface. This method requires high-frequency access to ensure real-time performance, which generates a large number of useless HTTPS requests to the public cloud server.

[0003] Microservices are a software development technique in which a single application consists of many loosely coupled and independently deployable smaller components or services. In a microservices architecture, services are fine-grained, and protocols are lightweight. Because services are small and independently deployable, there is no longer a need for a central server to take action to change even a single line of text in the application. Summary of the Invention

[0004] This invention provides a method and system for private domain service penetration requests based on a microservice gateway, solving the problem of how microservices deployed in the public cloud can actively send requests to local private domain services through a microservice gateway in a hybrid cloud application scenario. The technical solution is as follows:

[0005] A method for private domain service penetration requests based on a microservice gateway includes the following steps:

[0006] S1: The local microservice gateway sends a registration request to the gateway relay service module. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained.

[0007] S2: When a public cloud service sends a request to a private intranet service, the public cloud microservice gateway sends the request to the gateway relay service module, which then forwards the routing control signaling to the local microservice gateway based on the routing key carried in the request.

[0008] S3: After receiving the control signaling sent by the relay service, the local microservice gateway sends a request to pull the request content of the public cloud service according to the control signaling parameters. The local microservice gateway reassembles the request content of the public cloud service pulled from the gateway relay service and forwards the reassembled request to the corresponding private domain service.

[0009] S4: After processing the public cloud service request, the private domain service pushes the response content to the gateway relay service module via an HTTP request through the local microservice gateway. The gateway relay service module then relays the response content to the public cloud microservice gateway, which in turn forwards the response content to the public cloud service.

[0010] Furthermore, step S1 includes the following steps:

[0011] S101: After the local microservice gateway starts, it uses the WebSocket protocol to initiate a registration request to the cloud service and establish a websocket connection. It uses the WebSocket Upgrade request to agree on additional control header parameters to carry client identity information.

[0012] S102: After receiving the registration request, the gateway relay service authenticates the microservice gateway through the microservice gateway management service. If the authentication fails, the gateway relay service directly rejects the registration request of the local microservice gateway with a 401 status code; if the authentication is successful, proceed to step S103.

[0013] S103: The gateway relay service maintains a local routing table and a global routing table for authenticated clients. The local routing table is in-process and its structure is unique ID = WebSocket connection. The global routing table is maintained through two sets of hash tables: route key = "unique ID + IP address of the service where the connection is located" and unique ID = "route key". This is used to implement addressing based on the route key and to remove global routing information when the client goes offline.

[0014] S104: After the gateway relay service establishes a WebSocket connection with the local microservice gateway, it sends back the client's TOKEN information via CONNECT_ACK signaling;

[0015] S105: After the local microservice gateway establishes a WebSocket connection, it periodically sends PING signals to the gateway relay service to keep the connection alive. If no PONG response signal is received for two cycles, the connection is automatically destroyed and the connection is rebuilt starting from step S101.

[0016] S106: The gateway relay service establishes a WebSocket connection with the client. It checks the connection periodically and destroys any connection that has not generated any signaling interaction for two cycles by periodically polling. The connection is also deleted from the routing table to ensure the validity of the connection.

[0017] Furthermore, in step S101, the registration request carries the identity information of the local microservice gateway, which includes a unique ID, routing key, LAN IP, and data signature. This information is transmitted via the HTTP request header when the gateway relay service sends the registration request.

[0018] After the WebSocket connection between the local microservice gateway and the gateway relay service is established, the WebSocket connection is kept alive through custom PING / PONG signaling. If the public cloud server does not receive a PING for two keep-alive cycles, it is considered disconnected. If the private intranet service client does not receive a PONG for two keep-alive cycles, it is considered disconnected. After disconnection, it will automatically reconnect according to step S101.

[0019] Further, step S2 includes the following steps:

[0020] S201: The public cloud service sends a request to the public cloud microservice gateway;

[0021] S202: After receiving a request from a public cloud service, the public cloud microservice gateway retrieves the client connection information of the private intranet service from the global routing table based on the routing key information in the request header.

[0022] S203: If the local microservice gateway for the private domain intranet service is offline, return a 502 status code directly with the error message: Client is offline;

[0023] S204: If the local microservice gateway is online, forward the request to the gateway relay service module according to the "IP of the service where the connection is located" in the connection information;

[0024] S205: After receiving the request, the gateway relay service module registers the request content in its pending hash table in the form of "client ID = request content";

[0025] S206: The gateway relay service retrieves the client WebSocket connection instance from the local routing table based on the client ID, and sends a processing request control signaling to the local microservice gateway. The content is the request ID and the domain name of the service in question.

[0026] Furthermore, step S3 includes the following steps:

[0027] S301: After receiving the request control signaling, the local microservice gateway sends an HTTPS request to the gateway relay service through the service domain name of the request to retrieve the request content according to the request ID, and uses the request header to carry the client ID and TOKEN information in the HTTPS request.

[0028] S302: When the gateway relay service receives a request to retrieve the request content based on the request ID, it first performs TOKEN authentication. After successful authentication, it queries and locks the request from the pending hash table based on the request ID, and sends the request content to the local microservice gateway. At the same time, the target service information of this request is transmitted through the response header.

[0029] S303: After the local microservice gateway retrieves the request content from the public cloud service, it reconstructs the HTTP request based on the target service and other information in the response header, and forwards the request content to the private domain service through the HttpClient in the local microservice gateway.

[0030] Furthermore, step S4 includes the following steps:

[0031] S401: After the private domain service business is completed, the processing result will be sent to the local microservice gateway.

[0032] S402: After receiving the response from the private domain service, the local microservice gateway pushes the response content of the private domain service to the gateway relay service via HTTPS through the interface for uploading response results based on the request ID, and carries information such as request ID, client ID, and token in the request header;

[0033] S403: After receiving the response push request from the local microservice gateway, the gateway relay service module performs TOKEN authentication, retrieves the request information from the pending hash table based on the request ID, and sends the response content to the public cloud microservice gateway.

[0034] S404: After receiving the response, the public cloud microservice gateway will forward the response content to the public cloud service.

[0035] A private domain service penetration request system based on a microservice gateway includes:

[0036] Public cloud microservice gateway: Used for routing and forwarding microservices within the public cloud, located on the public cloud side;

[0037] Gateway relay service module: used for local microservice gateway identity authentication, local microservice gateway routing table registration, local microservice gateway WebSocket long connection management, as well as interface request relay forwarding, control information distribution, etc., located on the public cloud side;

[0038] Microservice Gateway Management Service Module: Used to manage the identity of the local microservice gateway and the local microservice gateway identity authentication, located on the public cloud side;

[0039] Local microservice gateway: Used to register with the gateway relay service module on the public cloud side at runtime, listen for control signals issued by WebSocket, and route and forward requests to private domain services. It is located on the private domain intranet service side.

[0040] Furthermore, the gateway relay service module processes data as follows:

[0041] Local microservice gateway authentication and local microservice gateway routing table registration refer to the process where, after the local microservice gateway starts up, it uses the WebSocket protocol to initiate a registration request to the cloud service and establish a WebSocket connection. It uses the WebSocket Upgrade request to specify additional control header parameters to carry client identity information. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained.

[0042] Local microservice gateway WebSocket long connection management refers to keeping WebSocket connections alive through custom PING / PONG signaling;

[0043] Interface request relay forwarding refers to the process where, when a public cloud service sends a request to a private intranet service, the public cloud microservice gateway sends the request to the gateway relay service module for request and response forwarding.

[0044] Control signaling refers to the sending of control signaling to the local microservice gateway for registration and authentication, as well as when a public cloud service sends a request to a private intranet service, in order to facilitate data transmission.

[0045] The aforementioned method and system for private domain service penetration requests based on microservice gateways enables public cloud services to proactively invoke private domain services transparently without requiring the provision of a private domain public domain name, only by opening external network access permissions. This includes functions such as business status feedback, configuration information distribution, and proactive status inspection. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of the structure of the private domain service penetration request system based on the microservice gateway. Detailed Implementation

[0047] like Figure 1 As shown, the private domain service penetration request system based on a microservice gateway includes:

[0048] 1. Public Cloud Microservice Gateway: Used for routing and forwarding microservices within the public cloud, located on the public cloud side;

[0049] 2. Gateway Relay Service Module: This module is used for local microservice gateway authentication, local microservice gateway routing table registration, local microservice gateway WebSocket long connection management, as well as interface request relay forwarding and control information distribution, and is located on the public cloud side; among which,

[0050] Local microservice gateway authentication and local microservice gateway routing table registration refer to the process whereby, after the local microservice gateway starts up, it uses the WebSocket protocol to initiate a registration request to the cloud service and establish a WebSocket connection. It uses the WebSocket Upgrade request to specify additional control header parameters to carry client identity information. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established, and the routing table is maintained.

[0051] Local microservice gateway WebSocket long connection management refers to the WebSocket connection being kept alive through custom PING / PONG signaling. The public cloud server considers the connection disconnected if it does not receive a PING for two keep-alive cycles, while the private domain intranet service client considers the connection disconnected if it does not receive a PONG for two keep-alive cycles.

[0052] Interface request relay forwarding refers to the process where, when a public cloud service sends a request to a private intranet service, the public cloud microservice gateway sends the request to the gateway relay service module for request and response forwarding.

[0053] Control signaling refers to the sending of control signaling to the local microservice gateway for registration and authentication, as well as when a public cloud service sends a request to a private intranet service, in order to facilitate data transmission.

[0054] 3. Microservice Gateway Management Service Module: Used to manage the identity of the local microservice gateway and the local microservice gateway identity authentication, located on the public cloud side;

[0055] 4. Local microservice gateway: Used to register with the gateway relay service module on the public cloud side at runtime, listen for control signals issued by WebSocket, and route and forward requests to private domain services. It is located on the private domain intranet service side.

[0056] Based on the private domain service penetration request system based on a microservice gateway, the implemented private domain service penetration request method includes the following steps:

[0057] S1: The local microservice gateway sends a registration request to the gateway relay service module. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained.

[0058] Specifically, the following steps are included:

[0059] S101: After the local microservice gateway is started, a registration request is sent to the cloud service using the WebScoket protocol and a websocket connection is established. The WebSocket Upgrade request is used to agree on additional control header parameters to carry client identity information;

[0060] The registration request carries the identity information of the local microservice gateway using the request header. The identity information includes information such as a unique ID, a routing key, a local area network IP, a data signature (using the SHA256 algorithm), etc. It is passed by sending the request header of the registration request to the gateway relay service module of the cloud service. The parameter format is: Authorization: DTCAuthV1 <JWT format content>;

[0061] S102: After the gateway relay service receives the registration request, it performs authentication through the microservice gateway management service. If the authentication fails, the gateway relay service directly rejects the registration request of the local microservice gateway with a 401 status code; if the authentication passes, it proceeds to step S103;

[0062] S103: The gateway relay service maintains a local routing table and a global routing table for the authenticated client. The local routing table is within the process, and the structure of the local routing table is unique ID = WebSocket connection. The global routing table is maintained through two hash tables with routing key = "unique ID + service IP where the connection is located" and unique ID = "routing key", which is used to implement addressing based on the routing key and removing global routing information when the client goes offline;

[0063] S104: After the gateway relay service establishes a WebScoket connection with the local microservice gateway, it returns the client TOKEN information through the CONNECT_ACK signaling;

[0064] S105: After the local microservice gateway establishes a WebSocket connection, it periodically sends a PING signaling to the gateway relay service to keep the connection alive. If it does not receive a PONG response signaling for two cycles, the connection is automatically destroyed and the connection is re-established starting from step S101;

[0065] S106: The gateway relay service establishes a WebSocket connection with the client. Through periodic polling checks, connections that have not had any signaling interactions for two cycles are directly destroyed and removed from the routing table to ensure the validity of the connection.

[0066] In addition, after establishing a WebSocket connection between the local microservice gateway and the gateway relay service module, the WebSocket connection is kept alive through custom PING / PONG signaling. If the public cloud server does not receive a PING for two keep-alive cycles, it is considered disconnected. If the private domain intranet service client does not receive a PONG for two keep-alive cycles, it is considered disconnected. After disconnection, it automatically reconnects according to step S101.

[0067] S2: When a public cloud service sends a request to a private intranet service, the public cloud microservice gateway sends the request to the gateway relay service module, which then forwards the control signaling to the local microservice gateway based on the routing key carried in the request; specifically, this includes the following steps:

[0068] S201: Public cloud service 2 sends a request to the public cloud microservice gateway;

[0069] S202: After receiving the request from public cloud service 2, the public cloud microservice gateway retrieves the client connection information of the private domain intranet service from the global routing table based on the routing key information in the request header: X-GW-RoutingKey:<routing key value>.

[0070] S203: If the local microservice gateway for the private domain intranet service is offline, return a 502 status code directly with the error message: Client is offline;

[0071] S204: If the local microservice gateway is online, forward the request to the gateway relay service module according to the "IP of the service where the connection is located" in the connection information;

[0072] S205: After receiving the request, the gateway relay service module registers the request content in its pending hash table in the form of "client ID = request content";

[0073] S206: The gateway relay service retrieves the client's WebSocket connection instance from the local routing table based on the client ID, and sends a processing request control signaling to the local microservice gateway: HTTP_PROXY_REQUEST_V1, content = request ID, domain name of the service in question.

[0074] S3: After receiving the control signaling sent by the relay service, the local microservice gateway sends a request to pull the public cloud service request content according to the control signaling parameters. The local microservice gateway reassembles the public cloud service request content pulled from the gateway relay service and forwards the reassembled request to the corresponding private domain service; including the following steps:

[0075] S301: After receiving the control signaling HTTP_PROXY_REQUEST_V1, the local microservice gateway sends an HTTPS request to the gateway relay service through the domain name of the service in which the request is located to retrieve the request content according to the request ID, and uses the request header to carry information such as the client ID and TOKEN in the HTTPS request.

[0076] S302: When the gateway relay service receives a request to pull the request content based on the request ID, it first performs TOKEN authentication. After successful authentication, it queries and locks the request from the pending hash table based on the request ID, finds the request content of public cloud service 2, and responds to the local microservice gateway with the request content. At the same time, the target service information of public cloud service 2 is transmitted through the response header.

[0077] S303: After the local microservice gateway retrieves the request content from public cloud service 2, it reconstructs the HTTP request based on the target service and other information in the response header, and forwards the request content to private domain service 1 through the HttpClient in the local microservice gateway.

[0078] S4: After processing the public cloud service request, the private domain service pushes the response content to the gateway relay service module via an HTTP request through the local microservice gateway. The gateway relay service module then relays the response content to the public cloud microservice gateway, which in turn forwards the response content to the public cloud service.

[0079] Specifically, the following steps are included:

[0080] S401: After the private domain service 1 completes its business processing, it will respond with the processing result to the local microservice gateway;

[0081] S402: After receiving the response from private domain service 1, the local microservice gateway pushes the response content of private domain service 1 to the gateway relay service via HTTPS through the interface for uploading response results based on request ID, and carries information such as request ID, client ID, and token in the request header;

[0082] S403: After receiving the response push request from the local microservice gateway, the gateway relay service module performs TOKEN authentication, retrieves the request information from the pending hash table based on the request ID, and sends the response content to the public cloud microservice gateway.

[0083] S404: After receiving the response, the public cloud microservice gateway will forward the response content to the public cloud service;

[0084] In this invention, TCP long connections can also be used instead of WebSocket long connections to implement the signaling channel between the public cloud microservice gateway and the local microservice gateway.

[0085] The present invention has the following advantages:

[0086] (1) It has millisecond-level real-time performance;

[0087] (2) Minimize the number of invalid network requests to improve service performance;

[0088] (3) Private domain services do not require separate maintenance of public domain names to provide services;

[0089] (4) The signaling messages transmitted through the signaling channel are short, compact, and have high real-time performance. The length of the request and response messages transmitted through the data channel can vary as needed to meet the needs of various scenarios.

[0090] (5) The transmission tunnel uses the commonly used application layer protocol technology wss+https, and there are a large number of mature toolchains available for site operation and maintenance, certificate management, traffic control, monitoring, etc.

Claims

1. A method for private domain service penetration requests based on a microservice gateway, comprising the following steps: S1: The local microservice gateway sends a registration request to the gateway relay service module. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained. S2: When a public cloud service sends a request to a private intranet service, the public cloud microservice gateway sends the request to the gateway relay service module, which then forwards the control signaling to the local microservice gateway based on the routing key carried in the request. S3: After receiving the control signaling sent by the relay service, the local microservice gateway sends a request to pull the request content of the public cloud service according to the control signaling parameters. The local microservice gateway reassembles the request content of the public cloud service pulled from the gateway relay service and forwards the reassembled request to the corresponding private domain service. S4: After the private domain service finishes processing the public cloud service request, it pushes the response content to the gateway relay service module via an HTTP request through the local microservice gateway. The gateway relay service module then relays the response content to the public cloud microservice gateway, which in turn forwards the response content to the public cloud service. Step S1 includes the following steps: S101: After the local microservice gateway starts, it uses the WebSocket protocol to initiate a registration request to the cloud service and establish a websocket connection. It uses the WebSocket Upgrade request to agree on additional control header parameters to carry client identity information. S102: After receiving the registration request, the gateway relay service authenticates the microservice gateway through the microservice gateway management service. If the authentication fails, the gateway relay service directly rejects the registration request of the local microservice gateway with a 401 status code; if the authentication is successful, proceed to step S103. S103: The gateway relay service maintains a local routing table and a global routing table for authenticated clients. The local routing table is in-process and its structure is unique ID = WebSocket connection. The global routing table is maintained through two sets of hash tables: route key = unique ID + IP address of the service where the connection is located and unique ID = route key. This is used to implement addressing based on the route key and to remove global routing information when the client goes offline. S104: After the gateway relay service establishes a WebSocket connection with the local microservice gateway, it sends back the client's TOKEN information via the CONNECT_ACK signaling. S105: After the local microservice gateway establishes a WebSocket connection, it periodically sends PING signals to the gateway relay service to keep the connection alive. If no PONG response signal is received for two cycles, the connection is automatically destroyed and the connection is rebuilt starting from step S101. S106: The gateway relay service establishes a WebSocket connection with the client. It checks the connection periodically and destroys any connection that has not generated any signaling interaction for two cycles by periodically polling. The connection is also deleted from the routing table to ensure the validity of the connection.

2. The method for private domain service penetration requests based on a microservice gateway according to claim 1, characterized in that: In step S101, the registration request carries the identity information of the local microservice gateway, which includes a unique ID, routing key, LAN IP, and data signature. This information is transmitted via the HTTP request header when the gateway relay service sends the registration request.

3. The method for private domain service penetration requests based on a microservice gateway according to claim 1, characterized in that: After the WebSocket connection between the local microservice gateway and the gateway relay service is established, the WebSocket connection is kept alive through custom PING / PONG signaling. If the public cloud server does not receive a PING for two keep-alive cycles, it is considered disconnected. If the private intranet service client does not receive a PONG for two keep-alive cycles, it is considered disconnected. After disconnection, it will automatically reconnect according to step S101.

4. The method for private domain service penetration request based on a microservice gateway according to claim 1, characterized in that: Step S2 includes the following steps: S201: The public cloud service sends a request to the public cloud microservice gateway; S202: After receiving a request from a public cloud service, the public cloud microservice gateway retrieves the client connection information of the private intranet service from the global routing table based on the routing key information in the request header. S203: If the local microservice gateway for the private domain intranet service is offline, return a 502 status code directly with the error message: Client is offline; S204: If the local microservice gateway is online, forward the request to the gateway relay service module according to the "IP of the service where the connection is located" in the connection information; S205: After receiving the request, the gateway relay service module registers the request content in its pending hash table in the form of "client ID = request content"; S206: The gateway relay service retrieves the client's WebSocket connection instance from the local routing table based on the client ID, and sends a processing request control signaling to the local microservice gateway. The content is the request ID and the domain name of the service in question.

5. The method for private domain service penetration request based on a microservice gateway according to claim 1, characterized in that: Step S3 includes the following steps: S301: After receiving the request control signaling, the local microservice gateway sends an HTTPS request to the gateway relay service through the service domain name of the request to retrieve the request content according to the request ID, and uses the request header to carry the client ID and TOKEN information in the HTTPS request. S302: When the gateway relay service receives a request to retrieve the request content based on the request ID, it first performs TOKEN authentication. After successful authentication, it queries and locks the request from the pending hash table based on the request ID, and sends the request content to the local microservice gateway. At the same time, the target service information of this request is transmitted through the response header. S303: After the local microservice gateway retrieves the request content from the public cloud service, it reconstructs the HTTP request based on the target service information in the response header and forwards the request content to the private domain service through the HttpClient in the local microservice gateway.

6. The method for private domain service penetration requests based on a microservice gateway according to claim 1, characterized in that: Step S4 includes the following steps: S401: After the private domain service business is completed, the processing result will be sent to the local microservice gateway. S402: After receiving the response from the private domain service, the local microservice gateway pushes the response content of the private domain service to the gateway relay service via HTTPS through the interface for uploading response results based on the request ID, and carries the request ID, client ID, and token information in the request header; S403: After receiving the response push request from the local microservice gateway, the gateway relay service module performs TOKEN authentication, retrieves the request information from the pending hash table based on the request ID, and sends the response content to the public cloud microservice gateway. S404: After receiving the response, the public cloud microservice gateway will forward the response content to the public cloud service.

7. A private domain service penetration request system based on a microservice gateway, characterized in that, include: Public cloud microservice gateway: Used for routing and forwarding microservices within the public cloud, located on the public cloud side; Gateway relay service module: used for local microservice gateway identity authentication, local microservice gateway routing table registration, local microservice gateway WebSocket long connection management, as well as interface request relay forwarding and control information distribution, located on the public cloud side; Microservice Gateway Management Service Module: Used to manage the identity and authentication of local microservice gateways, located on the public cloud side; Local microservice gateway: Used to register with the gateway relay service module on the public cloud side at runtime, listen for control signals issued by WebSocket, and route and forward requests to private domain services. It is located on the private domain intranet service side. The gateway relay service module processes data as follows: Local microservice gateway authentication and local microservice gateway routing table registration refer to the process where, after the local microservice gateway starts up, it uses the WebSocket protocol to initiate a registration request to the cloud service and establish a WebSocket connection. It uses the WebSocketUpgrade request to specify additional control header parameters to carry client identity information. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained. Local microservice gateway WebSocket long connection management refers to keeping WebSocket connections alive through custom PING / PONG signaling; Interface request relay forwarding refers to the process where, when a public cloud service sends a request to a private intranet service, the public cloud microservice gateway sends the request to the gateway relay service module for request and response forwarding. Control signaling refers to the sending of control signaling to the local microservice gateway for registration and authentication, as well as when a public cloud service sends a request to a private intranet service, in order to facilitate data transmission.

Images