A connection migration method, electronic equipment and storage medium

Abstract

This application relates to the field of communication technology, disclosing a connection migration method, electronic device, and storage medium. The method is applied to a server and includes: obtaining the context information and file descriptor of an RTMPS connection on a first process; transmitting the context information and file descriptor of the RTMPS connection to a second process; on the second process, restoring an encryption / decryption session based on SSL-based context information from the RTMPS connection context information, and restoring the RTMPS connection on the encryption / decryption session based on RTMP-based context information from the RTMPS connection context information; and performing data transmission and reception on the second process based on the file descriptor. This method facilitates seamless configuration changes or version upgrades without disconnecting the RTMPS connection, improving user experience.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a connection migration method, electronic device, and storage medium. Background Technology

[0002] The introduction of Real-Time Message Protocol (RTMP) technology has effectively solved the problems of multiplexing and packetizing multimedia data transmission streams. However, with the increasing emphasis on network data security, there is a growing need to improve the security of the RTMP protocol. This has led to the development of the RTMPS protocol, which is now being used more and more widely in areas such as live streaming.

[0003] Among them, Real Time Message Protocol Secure (RTMPS) is based on Transport Layer Security (TLS) / Secure Socket Layer (SSL) technology at the bottom layer of RTMP technology to encrypt and decrypt audio and video data, avoid the risk of data eavesdropping, enhance the security of data communication, and allow secure streaming transmission through the stream between the cryptographic encoder and the Content Delivery Network (CDN), which can effectively solve the security problems of RTMP. Summary of the Invention

[0004] This application provides a connection migration method, electronic device, and storage medium, which at least helps to avoid disconnecting the RTMPS connection when configuration changes or version upgrades are made, and the user is unaware of it, thus improving the user experience.

[0005] According to some embodiments of this application, one aspect of this application provides a connection migration method applied to a server. The method includes: obtaining the context information and file descriptor of an RTMPS connection on a first process; passing the context information and file descriptor of the RTMPS connection to a second process; on the second process, restoring an encryption / decryption session based on SSL-based context information in the context information of the RTMPS connection, and restoring the RTMPS connection on the encryption / decryption session based on RTMP-based context information in the context information of the RTMPS connection; and performing data transmission and reception on the second process based on the file descriptor.

[0006] According to some embodiments of this application, another aspect of this application provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the connection migration method as described above.

[0007] According to some embodiments of this application, another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the connection migration method described above.

[0008] The technical solution provided in this application has at least the following advantages:

[0009] The server passes the RTMPS connection context information and file descriptor from the first process to the second process. The RTMPS connection context information includes both SSL-based and RTMP-based context information. This allows the second process to first restore the encryption / decryption session based on the SSL-based context information, and then further restore the RTMPS connection based on the RTMP-based context information. This enables subsequent data sending and receiving in the second process based on the file descriptor. This achieves seamless migration of the RTMPS connection from the first to the second process without any interaction between the server and external devices, ensuring external transparency. Even with configuration changes or version upgrades, the seamless migration of the RTMPS connection between the server and external devices ensures a consistently maintained and uninterrupted RTMPS connection, improving user experience. Attached Figure Description

[0010] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0011] Figure 1 This is a connection diagram for an existing live streaming scenario;

[0012] Figure 2 This is a flowchart of a connection migration method provided in one embodiment of this application;

[0013] Figure 3 This is another flowchart of the connection migration method provided in one embodiment of this application;

[0014] Figure 4This is another flowchart of the connection migration method provided in one embodiment of this application;

[0015] Figure 5 This is another flowchart of the connection migration method provided in one embodiment of this application;

[0016] Figure 6 This is another flowchart of the connection migration method provided in one embodiment of this application;

[0017] Figure 7 This is a flowchart of the existing TLS session recovery mechanism;

[0018] Figure 8 This is another flowchart of the connection migration method provided in one embodiment of this application;

[0019] Figure 9 This is an interactive flowchart of a connection migration method provided in one embodiment of this application;

[0020] Figure 10 This is a schematic diagram of the server structure provided in another embodiment of this application;

[0021] Figure 11 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0022] As described in the background section, RTMPS technology is an improvement on RTMP technology based on TLS / SSL technology to enhance the security of audio and video data transmission. It is widely used in fields such as live streaming.

[0023] Specifically, as Figure 1 Taking the live streaming scenario shown as an example, the streaming media server needs to establish RTMPS connections with both the broadcaster's client and the viewer's client, as well as with the upstream server. Through the RTMPS connections established by the streaming media, the broadcaster's client can securely push the stream to the upstream server, while the viewer's client can securely pull the stream from the upstream server, presenting the broadcaster's view to the viewer in a live streaming format.

[0024] In order to provide better service, streaming media servers inevitably undergo configuration changes or version upgrades. However, configuration changes or version upgrades mean changes in status information or configuration information, which will cause the old process before the configuration change or version upgrade to malfunction. Therefore, after the configuration change or version upgrade, a new process needs to be created to replace the old process. The connection to the old process is then disconnected, and the connection is re-established on the new process to continue providing the relevant streaming media services.

[0025] During this process, the client will perceive that the RTMPS connection with the streaming media server has been interrupted, and the streaming media service will also be interrupted accordingly until the corresponding RTMPS connection is re-established in a new process, at which point the streaming media service can resume. This severely impacts the user experience.

[0026] To address the aforementioned issues, this application provides a connection migration method, a server, an electronic device, and a storage medium. The server transmits the context information and file descriptor of the RTMPS connection from the first process to the second process. This allows the second process to first restore the encryption / decryption session based on the SSL-based context information within the RTMPS connection context information, and further restore the RTMPS connection within the encryption / decryption session based on the RTMP-based context information. In subsequent communication, the second process sends and receives data based on the file descriptor, ultimately achieving the migration of the RTMPS connection from the first process to the second process. Furthermore, this process requires no interaction between the server and external devices, achieving external seamlessness. Thus, even with configuration changes or version upgrades, the RTMPS connection can be migrated seamlessly between the old and new processes, ensuring that the server's RTMPS connection with the external system remains intact and uninterrupted, thereby improving user experience.

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of this application to enable readers to better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments.

[0028] The division of the following embodiments is for ease of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0029] This application provides a connection migration method in one aspect. This method is applied to a server, where the server can be a streaming media server or similar device. In some embodiments, the flow of the connection migration method is as follows: Figure 2 As shown, it includes the following steps:

[0030] Step 201: Obtain the context information and file descriptor of the RTMPS connection on the first process.

[0031] In this embodiment, the first process is relative to the subsequent second process. The relationship between the first and second processes is that the first process is the older process created first, and the second process is the newer process created later.

[0032] In some cases, as mentioned above, embodiments of this application can be applied during configuration changes or version upgrades to achieve RTMPS connection migration. Therefore, taking a scenario of configuration changes or version upgrades as an example, the first process can be understood as a process created before the configuration change or version upgrade, and the second process is a process created after the configuration change or version upgrade is completed.

[0033] Of course, the above is just an example. In some scenarios where the connection on other processes created earlier needs to be disconnected and the corresponding connection needs to be restored on processes created later, the specific creation time of the first process and the second process may also be different, which will not be elaborated here.

[0034] In some cases, there may be multiple RTMPS connections on the server. Therefore, the server may create process groups to manage these RTMPS connections. That is, the server can have a first process group and a second process group created sequentially, and the first process group includes at least two first processes, and the second process group includes at least two second processes.

[0035] It should be noted that when multiple RTMPS connections exist on the server side, the first process in the first process group can be pre-created at startup. Each time an external RTMPS connection is established, one of the first processes in the first process group will be used. Furthermore, when the redundancy of the first process in the first process group decreases to a certain threshold, the creation of a new first process is allowed. The second process group can be created simultaneously based on the number of currently used first processes combined with a preset redundancy value, which will not be elaborated on here.

[0036] In this embodiment, the RTMPS connection on the first process refers to the RTMPS connection established by the server through the first process. The RTMPS connection can be established between the server and any (or any number of) objects.

[0037] by Figure 1Taking the scenario shown as an example, when the streaming media server configuration is updated or upgraded, if the upstream server has no problems and the streaming media server can push the stream to the upstream server normally, the streaming media server should migrate the RTMPS connection between the broadcast client and the streaming media server, as well as the RTMPS connection between the streaming media server and the upstream server, from the first process to the second process. Therefore, the RTMPS connections in the first process include the RTMPS connection between the broadcast client and the streaming media server, and the RTMPS connection between the streaming media server and the upstream server.

[0038] When the streaming media server 12 is configured or upgraded, if there is a problem with the upstream server, the streaming media server cannot push the stream to the upstream server, which is equivalent to the RTMPS connection between the streaming media server and the upstream server being broken. At this time, the streaming media server no longer needs to migrate the RTMPS connection between the streaming media server and the upstream server from the first process to the second process. Therefore, the RTMPS connection on the first process only includes the RTMPS connection between the broadcast client and the streaming media server.

[0039] Of course, if there is a problem with the upstream server, the streaming media server will also retry another upstream server in the second process and establish an RTMPS connection with the other upstream server in the second process. This will not be elaborated further here.

[0040] In this embodiment, the field information of the RTMPS connection is used to restore the RTMPS connection, and the file descriptor is used for communication.

[0041] Understandably, in RTMPS technology, a message is encapsulated into one or more chunks and transmitted sequentially. Only by assembling all chunks corresponding to the same stream ID can a complete and accurate message be obtained. If a message is currently being assembled, and the assembly of its chunks is interrupted, directly obtaining the state information of the RTMPS connection based on the message in the interrupted state and passing it to the second process can easily lead to the second process being unable to fully recover the message.

[0042] Based on this, in some embodiments, such as Figure 3 As shown, before obtaining the context information and file descriptor of the RTMPS connection on the first process, the connection migration method further includes the following steps:

[0043] Step 205: When the exit time of the first process arrives, check whether there is a message currently being assembled on the first process.

[0044] Accordingly, the context information and file descriptor of the RTMPS connection on the first process are obtained as follows: if no message is currently being assembled on the first process, the context information and file descriptor of the RTMPS connection in the first process are obtained.

[0045] In this way, by detecting whether the message currently being assembled in the first process has been completed, the acquisition of the RTMPS connection's context information and file descriptor in the first process is performed when there is no message currently being assembled. This avoids assembling interrupted messages and transmitting messages that have not been fully assembled, thus avoiding the problem of incomplete message recovery.

[0046] However, if the message being assembled in the first process has not been completed when the exit time of the first process arrives, Figure 3 The illustrated embodiments are not limited thereto. In some embodiments, a certain time interval may be set to check again whether the message currently being assembled in the first process has been completed, until the exit time of the first process arrives and there are no messages currently being assembled in the first process, then the context information and file descriptor of the RTMPS connection in the first process are obtained. Alternatively, in some embodiments, such as Figure 4 As shown, after detecting whether the message currently being assembled in the first process has been completed, the connection migration method also includes the following steps:

[0047] Step 206: If a message is detected to be currently being assembled in the first process, control the first process to continue assembling the message to be assembled until the assembly of the message to be assembled is completed.

[0048] Step 205 includes step 2051: determining when the exit time of the first process has arrived; and step 2052: detecting whether there is a message currently being assembled on the first process.

[0049] In this way, by controlling the continued assembly of the currently being assembled message, the assembly process of the currently being assembled message can continue without being interrupted. Furthermore, after the currently being assembled message is completed, the context information and file descriptor of the RTMPS connection in the first process can be obtained, thus avoiding the problem of incomplete message recovery.

[0050] Step 202: Pass the RTMPS connection's site information and file descriptor to the second process.

[0051] This embodiment does not limit the way in which the site information and file descriptors of the RTMPS connection are passed to the second process.

[0052] In some embodiments, such as Figure 5 As shown, before passing the RTMPS connection's context information and file descriptor to the second process, the migration connection method also includes the following steps:

[0053] Step 207: Create a domain socket.

[0054] Taking server-side configuration updates as an example, in addition to creating a first process (group) and a second process (group), the server also creates a domain socket, and the second process inherits and listens on this domain socket. In one example, to create the domain socket, a migration module (ngx_rtmp_transfer_module) can be added to the server. The domain socket is set in the post-configuration callback of this module, along with the callback functions for handling the domain socket, as well as the receive and send functions, thus creating the domain socket.

[0055] Step 208: Connect the first process to the second process via a domain socket.

[0056] As mentioned earlier, the second process may belong to the second process group. In this case, the second process that the first process connects to may be the second process with a smaller load determined from the second process group using a load balancing algorithm.

[0057] Correspondingly, the RTMPS connection's context information and file descriptor can be passed to the second process via a domain socket.

[0058] In other words, the process communication method of sockets (Unix domain sockets) can be used to pass the context information and file descriptors of the RTMPS connection from the first process to the second process.

[0059] Of course, the above is just one example. In some embodiments, shared storage and other methods can be used to transfer the field information and file descriptors of the RTMPS connection from the first process to the second process. These will not be elaborated on here.

[0060] In addition, in some embodiments, the site information and file descriptors of the RTMPS connection can be base64 encoded and encapsulated in JSON format before being transmitted.

[0061] Step 203: In the second process, based on the SSL-based field information in the field information of the RTMPS connection, the encryption / decryption session is restored, and based on the RTMP-based field information in the field information of the RTMPS connection, the RTMPS connection on the encryption / decryption session is restored.

[0062] It is understandable that, since encryption and decryption sessions involve two types of information: encryption and decryption context and encryption and decryption information, the recovery of encryption and decryption sessions will involve the recovery of encryption and decryption context, the recovery of encryption and decryption information, or the recovery of encryption and decryption context plus the recovery of encryption and decryption information.

[0063] Therefore, in some embodiments, the recovery of the encryption / decryption session includes the recovery of the encryption / decryption context. Based on the characteristics of RTMPS, the encryption / decryption context that needs to be recovered mainly includes SSL_CTX*ctx and SSL*ssl. In this case, the SSL-based context information may include SSL_SESSION information and CIPHER SPEC information. This is because the information required for the recovery of SSL_CTX*ctx and SSL*ssl is typically contained within the SSL_SESSION information and CIPHER SPEC information. Furthermore, as... Figure 6 As shown, the encryption / decryption session can be restored based on the SSL-based site information in the RTMPS connection's site information through the following steps:

[0064] Step 2031: Configure the SSL context based on the SSL_SESSION and CIPHER SPEC information to restore the encryption / decryption context.

[0065] Step 2032: After restoring the encryption / decryption session based on the encryption / decryption context, restore the RTMPS connection on the encryption / decryption session according to the RTMP-based context information in the context information of the RTMPS connection.

[0066] In this way, by restoring the encryption and decryption context, it is ensured that the encryption and decryption keys and other information recovered in the second process are still the same as those in the first process, so that encryption and decryption can continue to be performed normally in the second process based on the restored connection.

[0067] In some cases, SSL context settings are performed based on SSL_SESSION and CIPHER SPEC information to restore the encryption / decryption context. This can be achieved by extracting the necessary information for SSL_CTX*ctx and SSL*ssl from the SSL_SESSION and CIPHER SPEC information and writing it to the corresponding locations of SSL_CTX*ctx and SSL*ssl.

[0068] It should be noted that the reason why the above embodiments do not directly pass SSL_CTX*ctx is that SSL_CTX*ctx is a domain-level context, which is used for the same domain. It mainly involves information such as certificate files, protocol versions, and callback functions. Therefore, SSL_CTX*ctx involves a large number of scattered structure pointers, making it infeasible to directly pass SSL_CTX.

[0069] therefore, Figure 6 The illustrated embodiment transmits SSL_SESSION and CIPHER SPEC, which contain the information required for SSL_CTX*ctx, so that SSL_CTX*ctx can be set in the second process according to the required information. By taking advantage of the fact that the certificate-related configuration of the domain name generally does not change, it is ensured that the second process will obtain SSL_CTX with the same domain name as the first process. This is equivalent to passing SSL_CTX*ctx from the first process to the second process, but without directly transmitting SSL_CTX*ctx.

[0070] It's also important to note that SSL*SSL is a connection-level context, one for each RTMPS connection. The relevant state fields and SSL_SESSION need to be passed. Unlike SSL_CTX*ctx, it doesn't have a large number of scattered structure pointers; therefore, the state fields and SSL_SESSION can be directly passed. In other words, in some embodiments, the information required by SSL*SSL, such as state fields and SSL_SESSION, can be passed directly by calling the corresponding interfaces. For example, this can be achieved by calling the i2d_SSL_SESSION and d2i_SSL_SESSION application programming interfaces (APIs). i2d_SSL_SESSION is used in the first process to obtain session information by calling the SSL_get_session function, serialize it, and then pass the serialized data to the second process. d2i_SSL_SESSION is used in the second process to receive data from the first process, deserialize it, and then set the deserialized session information into the SSL context by calling the SSL_set_session function.

[0071] Similar to the encryption / decryption context recovery process described above, current TLS has a session recovery mechanism. Under this mechanism, the communication process between the server and client is as follows: Figure 7 As shown, the process includes the following:

[0072] 1. When the client and server first connect, use an empty SessionTicket TLS extension in the Client Hello message.

[0073] 2. After the server parses the SessionTicket extension from the Client Hello message, if it selects to support it, it will also attach an empty SessionTicket extension to its own Server Hello message to tell the client that it supports session resumption.

[0074] 3. Next, the handshake process can continue. After the client sends the ChangeCipherSpec message and the Finished message, the server encrypts these encrypted parameters to generate a ticket and sends it to the client via the NewSessionTicket message.

[0075] 4. The client saves the ticket. If the client wants to resume the connection via session, it can attach the ticket to the SessionTicket TLS extension of the Client Hello message. In this case, the extension will no longer be empty.

[0076] Therefore, Figure 6 The embodiments shown are similar to the encryption / decryption context recovery in the session recovery mechanism when restoring the encryption / decryption context; the main difference lies in how... Figure 7 The restoration of the encryption / decryption context shown is to restore the historical connection in a new connection initiated by the client, while Figure 6 The restoration of the encryption / decryption context shown does not require the client to initiate a new connection. Therefore, in some cases, it can be adopted... Figure 7 The existing session recovery mechanism shown uses the same steps as ClientHello and ChangeCipherSpec to restore the encryption / decryption context, which will not be elaborated here.

[0077] Of course, the above is just an example. In some cases, other SSL contexts can be set, which will not be elaborated here.

[0078] In this way, restoring the encryption / decryption context in a manner similar to existing session recovery mechanisms facilitates better compatibility with existing RTMPS protocols.

[0079] In some embodiments, restoring the encryption / decryption session includes restoring the encryption / decryption information. In this case, the SSL-based session information may include RECORD_LAYER information. This is because encryption / decryption information is typically maintained using RECORD_LAYER information in RTMPS; therefore, the required encryption / decryption information can be obtained through the RECORD_LAYER information. Thus, as... Figure 8 As shown, the encryption / decryption session can be restored based on the SSL-based site information in the RTMPS connection's site information through the following steps:

[0080] Step 2033: Configure SSL caching based on RECORD_LAYER information to restore encryption / decryption information.

[0081] Step 2034: After restoring the encryption / decryption session based on the encryption / decryption information, restore the RTMPS connection on the encryption / decryption session according to the RTMP-based field information in the field information of the RTMPS connection.

[0082] As mentioned earlier, there may be various scenarios for the RTMPS connection on the first process, and the corresponding encryption and decryption information may differ. For example, if there is no downlink connection on the first process, there is no need for messages to be sent. Furthermore, the encryption and decryption information may also differ depending on how the information received on the first process is processed. For instance, if all the information received on the first process has been decrypted, there is no need to recover the uncracked information.

[0083] Furthermore, OpenSSL uses SSL3_RECORD as the smallest unit, which contains the receive and send buffers SSL3_BUFFER, namely the rbuf array and the wbuf array. In the RECORD_LAYER structure, there is also an rrec array used to store the decrypted content.

[0084] Therefore, recovering encrypted and decrypted information based on the RECORD_LAYER information can be achieved in the following ways: If the first process has cached but undecrypted information, recover the cached but undecrypted information based on the rbuf array in the RECORD_LAYER information; if the first process has information to be sent, recover the information to be sent based on the wbuf array in the RECORD_LAYER information; if the first process has decrypted information but it has not been read by the application layer, recover the decrypted information but it has not been read by the application layer based on the rrec array in the RECORD_LAYER information.

[0085] In this way, by restoring the corresponding encryption and decryption information based on the different encryption and decryption information caching situations in the first process, the encryption and decryption information can be fully restored in the second process, thus avoiding subsequent encryption and decryption failures in the second process.

[0086] Of course, the above embodiments have described the recovery of the encryption / decryption context and the recovery of the encryption / decryption information separately. In some embodiments, the above embodiments can be combined to achieve both the recovery of the encryption / decryption context and the recovery of the encryption / decryption information. The relevant implementation details have been described previously and will not be repeated here.

[0087] To help those skilled in the art better understand how to recover an RTMPS connection on an encryption / decryption session based on RTMP-based field information, the following explanation will be provided.

[0088] RTMPS uses TLS / SSL protocol to encrypt and decrypt audio and video data at the underlying layer of the RTMP protocol. In essence, RTMPS is a combination of RTMP and TLS / SSL protocols, with TLS / SSL serving as the underlying protocol. Therefore, restoring RTMPS involves first restoring the TLS / SSL-based encryption / decryption session, and then restoring the RTMP connection over that session, thus restoring the RTMP connection. In other words, restoring the RTMPS connection over the encryption / decryption session is based on the RTMP-based context information within the RTMPS connection's context information; essentially, it's about restoring the RTMP connection based on this context information. Therefore, the RTMP-based context information used to restore the RTMP connection can include the following:

[0089] 1. Advanced Video Coding (AVC) header, Advanced Audio Coding (AAC) header, metadata, etc. If the RTMP connection is used to push the stream from the broadcaster to the streaming media server, then the AVC header, AAC header, and metadata need to be migrated; that is, the live information includes the AVC header, AAC header, and metadata. The AVC header, AAC header, and metadata are used by the streaming media server to retry the upstream server. In other words, if the upstream server fails, only the RTMP connection between the client and the streaming media server needs to be migrated. After the migration, the streaming media server attempts to connect to other upstream servers based on the AVC header, AAC header, etc.

[0090] 2. tcUrl, app, stream name, stream name parameters, swfUrl, pageUrl. This information is specified by the RTMP protocol and needs to be transmitted for both pulling and pushing streams.

[0091] 3. ACK information. This includes, but is not limited to, in_bytes and in_last_ack, used to send ACKs to the client and needs to be passed to the second process for seamless integration.

[0092] 4. play: This indicates whether the stream is being pulled. This identifier is only included in the live stream information when the stream is being pulled, and is used to distinguish between pulling and pushing the stream.

[0093] Step 204: Data is sent and received on the second process based on the file descriptor.

[0094] In this way, the server passes the RTMPS connection context information and file descriptor from the first process to the second process. This allows the second process to first restore the encryption / decryption session based on the SSL-based context information within the RTMPS connection context information, and then further restore the RTMPS connection itself based on the RTMP-based context information. This enables subsequent data sending and receiving in the second process based on the file descriptor, ultimately achieving the migration of the RTMPS connection from the first process to the second process. Furthermore, this process requires no interaction between the server and external devices, achieving external seamlessness. Thus, even with configuration changes or version upgrades, the RTMPS connection can be migrated seamlessly between the old and new processes, ensuring that the server's RTMPS connection with the external system remains intact and uninterrupted, improving the user experience.

[0095] To facilitate a better understanding of the connection migration method provided in the above embodiments by those skilled in the art, the following will be combined with Figure 8 Please provide an explanation.

[0096] like Figure 9As shown, at time T0, the client has established an RTMPS connection to the upstream server through the server's first process. At time T1, a configuration update is performed. At time T2, the configuration update is complete, and the exit time for the first process is set (set close and wait complete message). At time T3, the exit time for the first process arrives, and since there are no messages being assembled, migration begins. During the migration process, the first process first connects to the second process via a domain socket (connect Unix socket). Then, the first process obtains and prepares the information to be migrated (prepare transfer info), which includes RTMP-based context messages (including protocol context, stream information, AVC / AAC header, metadata), file descriptors (fd), and SSL-based context information (including SSL_SESSION information, RECORD_LAYER information, and CIPHER SPEC information). The second process then initializes the domain socket connection (init transfer connection). At time T4, the transfer information is sent (send transferinfo), and the first process exits (exit). After receiving the transfer information, the second process performs relevant processing (handle transferinfo) to restore the encryption / decryption session and further restore RTMPS. Thus, at time T5, the client establishes an RTMPS connection to the upstream server through the server's second process.

[0097] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this patent.

[0098] Another aspect of this application embodiment also provides a server, such as Figure 10 As shown, it includes:

[0099] The acquisition module 1001 is used to acquire the context information and file descriptors of the RTMPS connection on the first process.

[0100] The transfer module 1002 is used to transfer the field information and file descriptor of the RTMPS connection to the second process.

[0101] The processing module 1003 is used to restore the encryption / decryption context based on the SSL-based context information in the context information of the RTMPS connection in the second process, and to restore the RTMPS connection on the encryption / decryption session based on the RTMP-based context information in the context information of the RTMPS connection.

[0102] The transceiver module 1004 is used to send and receive data based on file descriptors in the second process.

[0103] It is not difficult to see that this embodiment is a server embodiment corresponding to the method embodiment, and this embodiment can be implemented in conjunction with the method embodiment. The relevant technical details mentioned in the method embodiment are still valid in this embodiment, and will not be repeated here to reduce repetition. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the method embodiment.

[0104] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.

[0105] Another aspect of this application embodiment also provides an electronic device, such as... Figure 11 As shown, it includes: at least one processor 1101; and a memory 1102 communicatively connected to at least one processor 1101; wherein the memory 1102 stores instructions executable by at least one processor 1101, the instructions being executed by at least one processor 1101 to enable at least one processor 1101 to perform the connection migration method described in any of the above method embodiments.

[0106] The memory 1102 and processor 1101 are connected via a bus. This bus can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors 1101 and memory 1102. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 1101 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 1101.

[0107] Processor 1101 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 1102 can be used to store data used by processor 1101 during operation.

[0108] Another aspect of this application provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the above-described method embodiments.

[0109] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0110] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A connection migration method, characterized in that, Applied to the server side, the method includes: Obtain the context information and file descriptor of the RTMPS connection on the first process; The field information of the RTMPS connection and the file descriptor are passed to the second process; In the second process, the encryption / decryption session is restored based on the SSL-based site information in the site information of the RTMPS connection, and the RTMPS connection on the encryption / decryption session is restored based on the RTMP-based site information in the site information of the RTMPS connection. Data is sent and received based on the file descriptor in the second process; The SSL-based site information includes SSL_SESSION information and CIPHER SPEC information, and the recovery of the encryption / decryption session includes the recovery of the encryption / decryption context; The step of restoring the encryption / decryption session based on the SSL-based site information in the site information of the RTMPS connection includes: The SSL context is set according to the SSL_SESSION and CIPHER SPEC information to restore the encryption / decryption context; The SSL-based site information includes RECORD_LAYER information, and the recovery of the encryption / decryption session includes the recovery of the encryption / decryption information; The step of restoring the encryption / decryption session based on the SSL-based site information in the site information of the RTMPS connection includes: Configure SSL caching based on the RECORD_LAYER information to restore encryption and decryption information.

2. The connection migration method according to claim 1, characterized in that, The step of setting the SSL context based on the SSL_SESSION and the CIPHER SPEC information includes: Extract the necessary information for SSL_CTX *ctx and SSL *ssl from the SSL_SESSION and CIPHER SPEC information and write it to the corresponding positions of SSL_CTX *ctx and SSL *ssl.

3. The connection migration method according to claim 1, characterized in that, The step of recovering the encrypted / decrypted information based on the RECORD_LAYER information includes: If there is cached but undecrypted information in the first process, the cached but undecrypted information is recovered according to the rbuf array in the RECORD_LAYER information; If there is information to be sent in the first process, the information to be sent is recovered according to the wbuf array in the RECORD_LAYER information; In the case where there is decrypted information in the first process but it has not been read by the application layer, the decrypted information but not read by the application layer is recovered according to the rrec array in the RECORD_LAYER information.

4. The connection migration method according to claim 1, characterized in that, Before obtaining the context information and file descriptor of the RTMPS connection on the first process, the method further includes: When the exit time of the first process arrives, it is detected whether there is a message currently being assembled on the first process. If there is no message currently being assembled on the first process, the site information of the RTMPS connection in the first process and the file descriptor are obtained.

5. The connection migration method according to claim 4, characterized in that, After detecting whether the message currently being assembled in the first process has been completed, the method further includes: If a message is detected to be currently being assembled on the first process, the first process is controlled to continue assembling the message to be assembled, so that after the message to be assembled is completed, the site information of the RTMPS connection in the first process and the file descriptor are obtained.

6. The connection migration method according to claim 1, characterized in that, Before passing the RTMPS connection's site information and the file descriptor to the second process, the method further includes: Create a domain socket; Connect the first process to the second process via the domain socket; The step of passing the site information of the RTMPS connection and the file descriptor to the second process includes: The RTMPS connection's site information and the file descriptor are transmitted to the second process via the domain socket.

7. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the connection migration method as described in any one of claims 1 to 6.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the connection migration method as described in any one of claims 1 to 6.

Images