Cross-platform file transmission method, terminal equipment and storage medium

Abstract

The invention is suitable for the field of data processing, and discloses a cross-platform file transmission method, terminal equipment and a storage medium. The cross-platform file transmission method comprises: according to a preset identifier, obtaining target service information of a target mDNS service in a detected mDNS service list, the target mDNS service being published by a receiving end in a local area network; extracting equipment information of the receiving end from the target service information, wherein the equipment information comprises an IP address and a port number; establishing TCP connection with a receiving end according to the IP address and the port number; and executing a file transmission operation according to the TCP connection, wherein the file transmission operation comprises a data sending operation or a data receiving operation. According to the invention, the cross-platform compatibility in a local area network environment is enhanced while the transmission efficiency is improved.

Description

Technical Field

[0001] The present invention belongs to the field of data processing, and particularly relates to a cross-platform file transfer method, a terminal device, and a storage medium. Background Art

[0002] The need for cross-platform file transfer stems from the trends of multi-device office work, remote collaboration, data backup, cross-platform operation, and mobile office work. Cross-platform file transfer tools require devices to "discover" each other within a local area network. mDNS (Multicast DNS) can achieve zero-configuration device identification through the.local domain name, without the need to manually enter an IP or configure the network.

[0003] In actual implementation, the traditional mDNS solution still needs to obtain the IP / port through an additional protocol (such as SSDP) after discovering the service, and the steps are cumbersome. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a cross-platform file transfer method, a terminal device, and a storage medium, which can solve the problem that in the related art, the traditional mDNS solution still needs to obtain the IP / port through an additional protocol (such as SSDP) after discovering the service, and the steps are cumbersome.

[0005] The first aspect of the present invention provides a cross-platform file transfer method, including: According to a preset identifier, obtain target service information of a target mDNS service in the detected mDNS service list, where the target mDNS service is published by a receiving end within a local area network; Extract device information of the receiving end from the target service information, where the device information includes an IP address and a port number; Establish a TCP connection with the receiving end according to the IP address and the port number; Execute a file transfer operation according to the TCP connection, where the file transfer operation includes a data sending operation or a data receiving operation.

[0006] Optionally, in the first implementation manner of the first aspect of the present invention, the step of executing a file transfer operation according to the TCP connection includes: If there is file data to be sent, divide the file data into multiple data packets; Sequentially send the multiple data packets to the receiving end through the TCP connection.

[0007] Optionally, in the second implementation manner of the first aspect of the present invention, the step of dividing the file data into multiple data packets if there is file data to be sent includes: If there is file data to be sent, send an inquiry request to the receiving end; If a response result of confirmed reception in response to the inquiry request is detected, split the file data into the multiple data packets.

[0008] Optionally, in the third implementation manner of the first aspect of the present invention, after the step of sequentially sending the multiple data packets to the receiving end through the TCP connection, the method further includes: After the file data transmission is completed, detect the md5 verification result returned by the receiving end; If the md5 verification result is detected, determine whether the file data is successfully sent according to the md5 verification result; If it is determined that the file data is successfully sent, disconnect the TCP connection.

[0009] Optionally, in the fourth implementation manner of the first aspect of the present invention, after the step of establishing a TCP connection with the receiving end according to the receiving end IP address and the receiving end port number, the method further includes: Periodically receive heartbeat packets; If the heartbeat packet is not received within a preset time, disconnect the TCP connection.

[0010] Optionally, in the fifth implementation manner of the first aspect of the present invention, the step of extracting the device information of the receiving end from the target service information includes: Parse the device information of the receiving end from the txtRecord field in the target service information.

[0011] Optionally, in the sixth implementation manner of the first aspect of the present invention, the step of obtaining the target service information of the target mDNS service from the detected mDNS service list according to a preset identifier includes: Obtain the respective target service information corresponding to each mDNS service in the detected mDNS service list.

[0012] Determine the target service information from the respective target service information according to the preset identifier.

[0013] Optionally, in the seventh implementation manner of the first aspect of the present invention, before the step of obtaining the target service information of the target mDNS service from the detected mDNS service list according to a preset identifier, the method further includes: Publish a preset mDNS service in the local area network, where the preset mDNS service is used to provide the local device information of the local machine, the preset service information of the preset mDNS service carries the preset identifier, and the local device information includes the local IP address and the local port number.

[0014] In a second aspect, an embodiment of the present invention provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the above cross-platform file transfer method are implemented.

[0015] In a third aspect, an embodiment of the present invention provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the steps of the above cross-platform file transfer method are implemented.

[0016] In a fourth aspect, an embodiment of the present invention provides a computer program product, which when running on a terminal device causes the terminal device to execute the above cross-platform file transfer method.

[0017] The beneficial effects of the embodiments of the present invention compared with the prior art are as follows: By directly embedding the IP address and port number of the receiving end in the target service information of the mDNS service, the sending end can directly resolve the complete network connection parameters from the service information after discovering the target mDNS service, eliminating the need for secondary interaction through additional protocols such as SSDP in the traditional solution. It effectively simplifies the process of establishing communication between devices, reduces the configuration complexity of cross-platform file transfer, and at the same time effectively avoids the redundant header overhead of traditional HTTP / FTP protocols through direct connection transmission based on the TCP protocol, enhancing the cross-platform compatibility in the local area network environment while improving the transmission efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the following drawings are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings without creative efforts based on these drawings.

[0019] Figure 1 It is a schematic diagram of an embodiment of the cross-platform file transfer method in an embodiment of the present invention; Figure 2 It is a schematic diagram of a specific embodiment of step S104 of the cross-platform file transfer method in an embodiment of the present invention; Figure 3 It is a schematic diagram of a specific embodiment of step S1041 of the cross-platform file transfer method in an embodiment of the present invention; Figure 4 It is a schematic diagram of a specific embodiment after step S103 of the cross-platform file transfer method in an embodiment of the present invention; Figure 5Schematic diagram of an embodiment of a terminal device in an embodiment of the present invention. Detailed implementation manners

[0020] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0021] It should be noted that the terms "including", "comprising" and "having" and any variations thereof in the specification and claims of the present invention and the above-mentioned drawings are intended to cover non-exclusive inclusion. For example, a process, method, terminal, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes unlisted steps or units, or optionally further includes other steps or units inherent to these processes, methods, products or devices. In the terms in the claims, specification and drawings of the present invention, relational terms such as "first" and "second" are only used to distinguish one entity / operation / object from another entity / operation / object, and do not necessarily require or imply any such actual relationship or order between these entities / operations / objects.

[0022] Referring to "embodiment" herein means that a specific feature, structure or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein may be combined with other embodiments.

[0023] The need for cross-platform file transfer stems from the trends of multi-device office work, remote collaboration, data backup, cross-platform operation and mobile office work. Cross-platform file transfer tools require devices to "discover" each other within a local area network. mDNS (Multicast DNS) can achieve zero-configuration device identification through the.local domain name, without manually entering an IP or configuring the network.

[0024] In actual implementation, traditional mDNS solutions still need to obtain the IP / port through an additional protocol (such as SSDP) after discovering the service, and the steps are cumbersome.

[0025] In view of this, embodiments of the present invention provide a cross-platform file transfer method, a terminal device, and a storage medium. By directly embedding the IP address and port number of the receiving end into the target service information of the mDNS service, the sending end can directly resolve the complete network connection parameters from the service information after discovering the target mDNS service, eliminating the need for secondary interaction through additional protocols such as SSDP in the traditional solution. This effectively simplifies the process of establishing communication between devices, reduces the configuration complexity of cross-platform file transfer, and at the same time effectively avoids the redundant header overhead of traditional HTTP / FTP protocols through direct connection transmission based on the TCP protocol, enhancing cross-platform compatibility in the local area network environment while improving transmission efficiency.

[0026] To illustrate the technical solution of the present invention, specific embodiments will be described below.

[0027] Figure 1 The figure shows a schematic flowchart of the implementation of a cross-platform file transfer method provided by an embodiment of the present invention. This method can be applied to a terminal device. The terminal device can be a mobile phone, a tablet computer, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, etc.

[0028] Specifically, the above cross-platform file transfer method may include the following steps S101 to S104.

[0029] Step S101, according to a preset identifier, obtain the target service information of the target mDNS service in the detected mDNS service list. The target mDNS service is published by the receiving end within the local area network.

[0030] In an embodiment of the present invention, the sending end and the receiving end are reversible. The terminal device (taking the sending end as an example in this embodiment) actively scans all available mDNS services within the local area network, filters the detected service list through a preset registration type identifier (such as "Example._tcp" in the regtype field), and only retains the target mDNS service that meets the identifier. This identifier, as the unique mark of the service type, can ensure that the terminal device only interacts with the receiving end using the same protocol, avoiding interference from other irrelevant services in the network.

[0031] Step S102, extract the device information of the receiving end from the target service information. The device information includes the IP address and port number.

[0032] In an embodiment of the present invention, extract the service description information from the response packet of the target mDNS service.

[0033] Optionally, the device information of the receiving end is parsed from the txtRecord field in the target service information. Among them, the txtRecord field is parsed with emphasis. This field stores the key network parameters of the receiving end in binary format (such as "ip=x.x.x.x port=xxx"), and the IP address and port number of the receiving end are parsed through a predefined format, directly obtaining the complete target address required for establishing communication without relying on secondary protocols such as SSDP for querying.

[0034] Optionally, after discovering the target service through mDNS, the terminal device extracts the txtRecord field from the response packet of the target mDNS service. This field stores the device information of the receiving end in binary format (such as ip=x.x.x.x port=xxx), and the terminal device locates and reads the original binary data of the txtRecord field by parsing the service response packet structure.

[0035] According to the preset key-value pair format (such as the delimiter rule of key=value), the binary data of the txtRecord field is converted into readable text. The terminal device retrieves the corresponding parameter values according to the predefined keywords (such as ip, port), and directly extracts the IP address and port number of the receiving end. If there are multiple groups of information in the field (such as device brand, dedicated port for file transfer), only the core parameters related to establishing a connection are filtered.

[0036] The parsed IP address and port number are converted into the standard network parameter format (such as the dotted decimal representation of the IPv4 address, the integer type of the port) to ensure cross-platform compatibility. For example, the string "ip=192.168.1.100 port=8080" is converted into the IP address 192.168.1.100 and the port number 8080 for subsequent Socket connection use.

[0037] Step S103, establish a TCP connection with the receiving end according to the IP address and port number.

[0038] In the embodiment of the present invention, based on the parsed IP address and port number, the terminal device actively initiates a TCP three-way handshake request to establish a point-to-point connection with the receiving end. This stage realizes cross-platform compatibility through the system-level Socket interface to eliminate the dependence on the network stack of a specific operating system, enabling platforms such as Windows, macOS, and Linux to complete connection initialization through the standard TCP / IP protocol.

[0039] Step S104, perform a file transfer operation according to the TCP connection, and the file transfer operation includes a data sending operation or a data receiving operation.

[0040] In an embodiment of the present invention, after a TCP connection is successfully established, the terminal device or the receiving end starts a file transfer protocol according to its own role (triggered by user operation). If it is a terminal device, it starts to assemble file data packets and push them through a Socket channel; if it is a receiving end, it enters a listening state and prepares to receive data streams. The transmission mode is dynamically determined by the role, realizing the two-way transmission ability within a single connection, which can effectively avoid the overhead of repeatedly establishing connections.

[0041] The beneficial effects of the embodiments of the present invention compared with the prior art are as follows: By directly embedding the IP address and port number of the receiving end into the target service information of the mDNS service, the terminal device can directly resolve the complete network connection parameters from the service information after discovering the target mDNS service, eliminating the need for additional protocols such as SSDP for secondary interaction in the traditional solution. It effectively simplifies the process of establishing communication between devices, reduces the configuration complexity of cross-platform file transfer, and at the same time effectively avoids the redundant header overhead of traditional HTTP / FTP protocols through direct connection transmission based on the TCP protocol, enhancing the cross-platform compatibility in the local area network environment while improving the transmission efficiency.

[0042] Traditional file transfer protocols (such as FTP, HTTP) usually transfer files as a whole unit, lacking a data chunking mechanism, resulting in easy retransmission from the beginning due to network instability or interruption during the transfer of large files, causing waste of bandwidth and time. Moreover, the device discovery and transfer processes based on protocols such as SSDP are separated, and complex negotiation is still required to determine transfer parameters after device discovery, further increasing the transfer delay. Based on this, an alternative embodiment of the present invention is proposed.

[0043] Refer to Figure 2 , Figure 2 is a schematic diagram of a specific embodiment of step S104 of the cross-platform file transfer method in the embodiments of the present invention. Step S104 further includes the following specific embodiments: Step S1041, if there is file data to be sent, split the file data into multiple data packets.

[0044] In an embodiment of the present invention, when the terminal device detects file data to be transmitted, the complete file is split into multiple data packets according to a preset packet splitting rule (such as a fixed size or dynamically adjusted data blocks). Each data packet is independently encapsulated as a transmission unit carrying file content, packet sequence number, and check information, so that a single data packet has integrity and traceability during the transmission process. The split data packet queue is cached in the transmission buffer of the terminal device in sequence, waiting for a send instruction.

[0045] Step S1042, send the multiple data packets to the receiving end through the TCP connection in sequence.

[0046] In an embodiment of the present invention, the terminal device pushes data packets to the receiving end one by one in the generation order of the data packet queue through an established TCP connection. Before each data packet is sent, header information (such as packet sequence number, data length) is attached, and the receiving end reorganizes the file according to the header information. During the sending process, the reliable transmission mechanism of the TCP protocol (such as ACK confirmation, retransmission mechanism) can ensure the order and integrity of the data, and avoid data disorder or loss caused by network jitter.

[0047] In the embodiment of the present invention, by splitting the file data into multiple independent data packets and transmitting them in order, the efficiency and reliability of large-scale file transmission are significantly improved. The chunked transmission mechanism allows the terminal device to dynamically adjust the transmission rate when the network bandwidth fluctuates, and can effectively avoid the risk of network congestion caused by a single large file transmission; at the same time, the streaming transmission mode based on the TCP protocol combined with packet sequence number management enables the receiving end to accurately restore the original order of the file, effectively solving the low-efficiency problem that the traditional HTTP / FTP protocol needs to start over after a transmission interruption caused by missing data fragments, and is applicable to large file or high-latency network environments.

[0048] Traditional file transmission technologies (such as FTP or HTTP) usually directly transmit data immediately after establishing a connection, lacking a dynamic confirmation mechanism for the status of the receiving end. When the receiving end has insufficient storage space, permission restrictions, or is actively rejected by the user, the terminal device will still continue to transmit data, resulting in waste of network resources and redundant retransmissions after transmission failures. Based on this, an alternative embodiment of the present invention is proposed.

[0049] Refer to Figure 3 , Figure 3 which is a schematic diagram of a specific embodiment of step S1041 of the cross-platform file transmission method in the embodiment of the present invention. Step S1041 further includes the following specific embodiments: Step S10411, if there is file data to be sent, send an inquiry request to the receiving end.

[0050] In an embodiment of the present invention, when it is detected that there is file data to be sent, an inquiry request (such as a handshake packet containing metadata such as the number of files, total size, etc.) is sent to the receiving end. This request is transmitted through the established TCP connection and is used to actively confirm the receiving willingness of the receiving end, avoiding invalid transmissions caused by the receiving end not being ready or refusing to receive.

[0051] Step S10412, if it is detected that the response result of confirming receipt in response to the inquiry request is received, split the file data into multiple data packets.

[0052] In an embodiment of the present invention, after sending an inquiry request, continuously monitor the response result (such as a preset integer identifier) of the receiving end to confirm receipt. If no response is received within the preset time, trigger the timeout mechanism, terminate the current transmission process, and release resources; if a confirmation response is received, enter the data chunking stage.

[0053] Based on the confirmation response from the receiving end, divide the file data to be sent into multiple data packets according to the preset packet splitting rules (such as fixed-size chunking or dynamic optimization chunking). After chunking is completed, add the data packets to the transmission queue in order, and prepare to enter the actual transmission stage.

[0054] In an embodiment of the present invention, by introducing the interaction mechanism of inquiry request and confirmation response, the reliability of the transmission process and the resource utilization rate are significantly improved. The terminal device only starts to chunk and transmit the file data after the receiving end clearly confirms the willingness to receive, avoiding the waste of network bandwidth and the risk of transmission failure caused by blind transmission due to the unknown state of the receiving end in the traditional scheme. At the same time, the metadata exchange (such as the total file size) in the handshake stage provides the receiving end with the ability to pre-allocate storage space, further optimizing the transmission efficiency.

[0055] Traditional file transfer technologies (such as FTP, HTTP) usually rely on the built-in verification mechanisms of the protocols (such as the checksum of TCP), but they can only detect data errors during the transmission process and cannot verify the final integrity of the file at the receiving end. Moreover, traditional solutions rely on manual confirmation or additional tools for verification after the transmission ends, which is inefficient and error-prone. Based on this, the present invention proposes an alternative embodiment.

[0056] After step S1042, the following specific embodiments are further included: Step S1043, after the file data transmission is completed, detect the md5 verification result returned by the receiving end.

[0057] In an embodiment of the present invention, after all file data packets are transmitted through a TCP connection, actively monitor the MD5 verification result returned by the receiving end. After receiving the file data, the receiving end calculates and generates a 16-bit MD5 verification value based on the last 1MB data (or the complete file) of the file, and encapsulates this value into a verification result data packet and sends it back to the terminal device.

[0058] Continuously monitor through the TCP connection until timeout or the verification result is received.

[0059] Step S1044, if the md5 verification result is detected, determine whether the file data is successfully sent according to the md5 verification result.

[0060] In an embodiment of the present invention, the MD5 check result returned by the receiving end is parsed and compared with the file MD5 value calculated locally. If the two are the same, it is determined that the file data has been successfully sent; if they are different or no check result is received (such as a timeout), it is determined that the transmission has failed.

[0061] Step S1045, if it is determined that the file data has been successfully sent, then disconnect the TCP connection.

[0062] In an embodiment of the present invention, if the check result is determined to be successful, a disconnection request is actively sent to the receiving end, and both parties synchronously release the TCP connection resources; if it is determined to be a failure, subsequent processing procedures are triggered according to a preset policy (such as a retransmission mechanism). By disconnecting the connection immediately after successful verification, the problem of network resources occupied by invalid connections can be reduced.

[0063] In an embodiment of the present invention, by introducing a transmission result verification mechanism based on MD5 check, the data consistency between the terminal device and the receiving end is automatically compared after the file transmission is completed, effectively solving the problem of silent data corruption caused by the lack of reliable verification in traditional file transfer protocols. By releasing the connection immediately after successful verification, the resource waste caused by not disconnecting the connection in time in the traditional solution is avoided, and at the same time, the integrity of data transmission in a cross-platform environment can be ensured.

[0064] Traditional TCP transfer protocols rely on the default connection timeout mechanism of the operating system (usually up to several minutes). In a local area network or cross-platform environment, if the connection fails due to network interruption, device sleep, etc., the terminal device and the receiving end cannot perceive it in time and still need to wait for the system-level timeout to release resources. Such delays not only cause long-term occupation of port and memory resources, but may also cause blockage of subsequent transmission tasks. Based on this, an alternative embodiment of the present invention is proposed.

[0065] Refer to Figure 4 , Figure 4 FIG. is a schematic diagram of a specific embodiment after step S103 of the cross-platform file transfer method in an embodiment of the present invention. After step S103, the following specific embodiments are further included: Step S201, periodically receive heartbeat packets.

[0066] In an embodiment of the present invention, after the terminal device and the receiving end successfully establish a TCP connection, a heartbeat detection mechanism is started on both sides. The terminal device periodically (such as every 30 seconds) sends a heartbeat packet (such as an empty data packet carrying a time stamp) to the receiving end. At the same time, the receiving end updates the time stamp of the last valid communication each time it receives a data packet (including a heartbeat packet or a file data packet), as the basis for determining the connection survival.

[0067] The receiving end continuously monitors the difference between the current time and the timestamp of the last valid communication. If it exceeds the preset threshold (for example, no packets are received within 60 seconds), it is determined that the heartbeat has timed out. In this stage, cross-platform time synchronization is achieved through a system-level timer, which can effectively avoid misjudgment caused by differences in operating system clocks.

[0068] Step S202, if no heartbeat packet is received within the preset time, disconnect the TCP connection.

[0069] In an embodiment of the present invention, when heartbeat timeout is detected (that is, no heartbeat packet or any packet is received within the preset time), the receiving end actively triggers the TCP connection disconnection process, releases the Socket resources and notifies the terminal device (such as through an exception callback). The terminal device synchronously performs resource recovery, terminates the current transmission task and records the error log to ensure the efficient reuse of network resources.

[0070] In the embodiment of the present invention, by introducing a heartbeat detection mechanism to dynamically monitor the health status of the TCP connection, the problem of "zombie connections" caused by network fluctuations or device anomalies in traditional file transfer protocols is effectively solved. Through periodic heartbeat packet interaction, invalid connections can be quickly identified and released, avoiding the occupation of system resources (such as ports, memory) by long-term invalid connections, and significantly improving the stability and resource utilization rate of the cross-platform transmission system.

[0071] In mDNS technology, device discovery usually returns all available services (such as printers, media servers, file transfer services). The sending end needs to rely on manual selection or an additional protocol (such as SSDP) for secondary filtering, resulting in a cumbersome and inefficient device discovery process. Differences in the definition of service types on different platforms may cause compatibility problems (such as inconsistent regtype naming for the same service on Windows and macOS). This solution realizes automated target service matching with zero manual intervention through a strongly constrained screening mechanism with preset identifiers, filling the deficiencies of multi-service mixing and platform compatibility in traditional technologies. Based on this, an optional embodiment of the present invention is proposed.

[0072] Step S101 further includes the following specific embodiments: Step S1011, obtain the respective target service information corresponding to each mDNS service in the detected mDNS service list.

[0073] In an embodiment of the present invention, the sending end actively initiates an mDNS service discovery request within the local area network, broadcasting to query for available devices of a specific service type (such as _Example._tcp). Receiving ends in the network return their own service information through mDNS response messages, and the sending end collects all the response messages and generates a complete mDNS service list. This list contains metadata such as the name, type (regtype), port number, and txtRecord field of each service.

[0074] Step S1012, determine the target service information from each piece of target service information according to a preset identifier.

[0075] In an embodiment of the present invention, the sending end filters the mDNS service list according to a preset identifier (such as the service type _Example._tcp or a custom regtype field). By matching the regtype field in the service information item by item with the preset identifier, only the target mDNS services that exactly match are retained, and other irrelevant services (such as printers, smart home devices) are excluded. After the screening is completed, the detailed description information (such as IP, port number) of the target service is extracted for subsequent connection use.

[0076] In an embodiment of the present invention, the mDNS service list is accurately screened through a preset identifier, solving the problem of mis-matching caused by service mixing in traditional local area network device discovery. The filtering mechanism based on regtype can quickly locate the target file transfer service, effectively avoiding redundant responses for processing irrelevant devices, significantly reducing the latency and computational resource consumption of device discovery. At the same time, the standardized definition of the preset identifier (such as a unified service type) can ensure the compatibility of service discovery between cross-platform devices.

[0077] Traditional local area network file transfer tools usually rely on static IP configuration or a centralized server for device discovery and cannot achieve dynamic role switching (such as repeating configuration when the same device needs to send and receive files simultaneously). Based on this, an alternative embodiment of the present invention is proposed.

[0078] Before step S101, the following specific implementation manners are further included: Step S203, publish a preset mDNS service within the local area network. The preset mDNS service is used to provide the local device information of the local machine. The preset service information of the preset mDNS service carries a preset identifier, and the local device information includes the local IP address and the local port number.

[0079] In an embodiment of the present invention, when a terminal device (as a receiving end) starts up, it generates an mDNS service description based on a preset identifier (such as _Example._tcp) and local information (IP address, port number). In the service description, the preset identifier is used as the regtype field, and at the same time, the local IP address, port number, and other parameters (such as device name, protocol version) are encoded in the txtRecord field, so that the service information contains complete network connection parameters.

[0080] The terminal device continuously broadcasts this service within the local area network through the mDNS protocol supported by the operating system (such as Bonjour, Avahi). After the service is published, it periodically sends multicast packets to maintain the active state of the service, ensuring that other devices (such as the sending end) can dynamically discover the local service. If it detects a change in the local IP address or a network interruption, it automatically updates the IP and port information in the txtRecord field and republishes the service.

[0081] In the embodiment of the present invention, by dynamically publishing the mDNS service carrying complete network parameters, seamless two-way role switching of devices is achieved (the same device can act as both a sending end and a receiving end at the same time), and service registration and update can be completed without manual intervention. Through the strongly constrained service publishing with a preset identifier, only target device types can be discovered within the local area network, solving the problem of misconnections caused by mixed devices in the traditional solution. Moreover, the dynamic update mechanism of service information enhances the robustness of cross-platform transmission.

[0082] As Figure 5 shown, it is a schematic diagram of a terminal device provided by an embodiment of the present invention. The terminal device 5 may include: a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501, such as a cross-platform file transfer program. When the processor 501 executes the computer program 503, the steps in the above-mentioned various cross-platform file transfer embodiments are implemented.

[0083] The computer program can be divided into one or more modules / units. One or more modules / units are stored in the memory 502 and executed by the processor 501 to complete the present invention. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and these instruction segments are used to describe the execution process of the computer program in the terminal device.

[0084] The terminal device may include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art can understand that Figure 5The following are merely examples of terminal devices and do not constitute limitations thereto. They may include more or fewer components than those shown in the figures, or combine certain components, or have different components. For example, a terminal device may also include input / output devices, network access devices, buses, etc.

[0085] The so-called processor 501 may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0086] The memory 502 may be an internal storage unit of the terminal device, such as a hard disk or memory of the terminal device. The memory 502 may also be an external storage device of the terminal device, such as a plug-in hard disk equipped on the terminal device, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. Further, the memory 502 may also include both an internal storage unit and an external storage device of the terminal device. The memory 502 is used to store computer programs and other programs and data required by the terminal device. The memory 502 may also be used to temporarily store data that has been output or is to be output.

[0087] It should be noted that for the convenience and brevity of description, the structure of the above terminal device may also refer to the specific description of the structure in the method embodiments, which will not be elaborated herein.

[0088] The embodiments of the present invention also provide a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the steps in the above cross-platform file transfer method can be implemented.

[0089] The embodiments of the present invention provide a computer program product, and when the computer program product runs on a mobile terminal, the mobile terminal can be made to execute the steps in the above cross-platform file transfer method.

[0090] In the above embodiments, the descriptions of the various embodiments have their respective emphases. For parts not detailed or recorded in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0091] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present invention.

[0092] In the embodiments provided by the present invention, it should be understood that the disclosed terminal devices and methods can be implemented in other ways. For example, the terminal device embodiments described above are merely illustrative. Another point is that the couplings or direct couplings or communication connections shown or discussed among each other can be through some interfaces, and the indirect couplings or communication connections of devices or units can be in electrical, mechanical or other forms.

[0093] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they can be located in one place, or can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0094] In addition, the functional units in each embodiment of the present invention can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0095] When the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-mentioned embodiment methods of the present invention, it can also be completed by a computer program instructing relevant hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0096] The above-mentioned embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features. These modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A cross-platform file transfer method, characterized in that: include: According to the preset identifier, target service information of the target mDNS service is obtained in the detected mDNS service list, where the target mDNS service is published by the receiving end in the local area network; Extracting device information of the receiving end from the target service information, wherein the device information includes an IP address and a port number; Establishing a TCP connection with the receiving end according to the IP address and the port number; A file transfer operation is performed according to the TCP connection, where the file transfer operation includes a data sending operation or a data receiving operation.

2. The cross-platform file transfer method according to claim 1, characterized in that: The step of performing a file transfer operation according to the TCP connection comprises: If there is file data to be sent, dividing the file data into multiple data packets; The multiple data packets are sent to the receiving end in sequence through the TCP connection.

3. The cross-platform file transfer method according to claim 2, characterized in that: If there is file data to be sent, the step of dividing the file data into multiple data packets includes: If there is file data to be sent, sending a query request to the receiving end; If a response result of confirmation reception in response to the inquiry request is detected, the file data is divided into the plurality of data packets.

4. The cross-platform file transfer method according to claim 2, characterized in that: After the step of sending the plurality of data packets to the receiving end in sequence through the TCP connection, the method further comprises: After the file data transmission is completed, detecting the md5 verification result returned by the receiving end; If the md5 verification result is detected, judging whether the file data is sent successfully according to the md5 verification result; If it is determined that the file data is sent successfully, the TCP connection is disconnected.

5. The cross-platform file transfer method according to claim 1, characterized in that: After the step of establishing a TCP connection with the receiving end according to the receiving end IP address and the receiving end port number, the method further comprises: Periodically receive heartbeat packets; If the heartbeat packet is not received within a preset time, the TCP connection is disconnected.

6. The cross-platform file transmission method according to claim 1, characterized in that: The step of extracting the device information of the receiving end from the target service information comprises: The device information of the receiving end is parsed from the txtRecord field in the target service information.

7. The cross-platform file transmission method according to claim 1, characterized in that: The step of acquiring target service information of the target mDNS service in the detected mDNS service list according to the preset identifier includes: Get the target service information corresponding to each mDNS service in the detected mDNS service list; According to a preset identifier, the target service information is determined in each of the target service information.

8. The cross-platform file transmission method according to claim 1, characterized in that: Before the step of acquiring target service information of the target mDNS service in the detected mDNS service list according to the preset identifier, the method further includes: A preset mDNS service is published in the local area network, where the preset mDNS service is used to provide local device information of the local device, where the preset service information of the preset mDNS service carries the preset identifier, and the local device information includes the local IP address and the local port number.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the cross-platform file transmission method according to any one of claims 1 to 8 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the cross-platform file transmission method according to any one of claims 1 to 8 are implemented.

Images