CN114173314B - 数据传输方法及装置 - Google Patents

数据传输方法及装置 Download PDF

Info

Publication number
CN114173314B
CN114173314B CN202210126234.5A CN202210126234A CN114173314B CN 114173314 B CN114173314 B CN 114173314B CN 202210126234 A CN202210126234 A CN 202210126234A CN 114173314 B CN114173314 B CN 114173314B
Authority
CN
China
Prior art keywords
data
transmission rate
link
transmission
near field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210126234.5A
Other languages
English (en)
Other versions
CN114173314A (zh
Inventor
张梦龙
朱浩冰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202210126234.5A priority Critical patent/CN114173314B/zh
Publication of CN114173314A publication Critical patent/CN114173314A/zh
Application granted granted Critical
Publication of CN114173314B publication Critical patent/CN114173314B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H04W28/22—Negotiating communication rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/082—Load balancing or load distribution among bearers or channels
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请实施例提供一种数据传输方法及装置，应用于第一电子设备，方法包括：与第二电子设备建立多条基于近场通信的链路，检测多条基于近场通信的链路的实际传输速率，依据实际传输速率，将数据分配至多条基于近场通信的链路中的至少一条链路，使用至少一条链路传输数据。因为依据链路的实际传输速率，将数据分配至链路传输，所以，为提高数据传输的速率（即吞吐量）提供了可能性。

Description

数据传输方法及装置
技术领域
本申请涉及通信技术领域，尤其涉及一种数据传输方法及装置。
背景技术
电子设备之间进行基于近场通信的数据传输，是一种常见的通信场景。近场通信的方式包括但不限于：蓝牙、无线保真（Wireless Fidelity，WIFI）、无线局域网（WirelessLocal Area Networks，WLAN）以及近距离通信(Near Field Communication，NFC)。
发明内容
本申请提供了一种数据传输方法，目的在于解决如何提高基于近场通信的数据传输的吞吐量的问题。
为了实现上述目的，本申请提供了以下技术方案：
本申请的第一方面提供一种数据传输方法，应用于第一电子设备，方法包括：与第二电子设备建立多条基于近场通信的链路，检测多条基于近场通信的链路的实际传输速率，依据实际传输速率，将数据分配至多条基于近场通信的链路中的至少一条链路，使用至少一条链路传输数据。因为依据链路的实际传输速率，将数据分配至链路传输，其中，目标链路的实际传输速率依据所述目标链路的QDISC的剩余空间以及协商速率确定，所述目标链路为所述多条基于近场通信的链路中的任意一条链路，所以，为提高数据传输的速率提供了可能性。
在一些实现方式中，目标链路为用于传输数据的链路中任意一条链路，检测多条基于近场通信的链路的实际传输速率的实现方式包括：至少依据目标链路的QDISC的剩余空间，获取第一传输速率，依据目标链路的协商速率，确定第二传输速率，将第一传输速率与第二传输速率中的最小值，作为实际传输速率，能够使得在数据传输的初始阶段获得较高的传输速率，并降低因QDISC剩余长度不足而导致丢弃数据的可能性。
在一些实现方式中，至少依据目标链路的QDISC的剩余空间，获取第一传输速率，包括：至少依据目标链路的QDISC的剩余空间，确定数据包的个数，至少依据个数、每个数据包的数据量以及每个发送周期的长度，确定第一传输速率，以降低因QDISC剩余长度不足而导致丢弃数据的可能性。
在一些实现方式中，至少依据个数、每个数据包的数据量以及每个发送周期的长度，确定第一传输速率，包括：依据个数、每个数据包的数据量、每个发送周期的长度以及预设的第一系数，确定第一传输速率。
在一些实现方式中，至少依据目标链路的QDISC的剩余空间，确定数据包的个数，包括：依据目标链路的QDISC的剩余空间以及预设的队列阈值的差值，确定数据包的个数。队列阈值能够防止抖动而导致的队列溢出。
在一些实现方式中，依据目标链路的协商速率，确定第二传输速率，包括：依据协商速率与预设的第二系数的乘积，确定第二传输速率。第二系数能够防止网络抖动而导致的传输的数据超过链路的最大传输速率。
在一些实现方式中，第二系数为目标链路中有效数据的传输时间与全部数据的传输时间的比值。
在一些实现方式中，在至少依据目标链路的QDISC的剩余空间，获取第一传输速率之前，还包括：确定目标链路的QDISC的剩余空间小于预设的队列阈值，以实现不计算QDISC的剩余空间不小于队列阈值的链路的实际传输速率的目标，从而可以节省资源并防止QDISC溢出。
在一些实现方式中，依据实际传输速率，将数据分配至多条基于近场通信的链路中的至少一条链路，包括：将数据分配至实际传输速率最高的链路，或者，依据实际传输速率的比值，将数据分配至多条基于近场通信的链路中的至少两条链路，其中，分配至至少两条链路的数据量的比例为比值。按照实际传输速率分配数据至链路，有利于获得较高的数据传输速率。
本申请的第二方面提供一种数据传输系统，包括：第一电子设备与第二电子设备，第一电子设备与第二电子设备之间建立多条基于近场通信的链路，第一电子设备用于执行本申请的第一方面提供的数据传输方法，第二电子设备至少用于请求数据重传以及进行去重处理。
本申请的第三方面提供一种电子设备，包括：一个或多个处理器，以及一个或多个存储器，存储器存储有一个或多个程序，当一个或者多个程序被处理器执行时，使得电子设备执行本申请的第一方面提供的数据传输方法。
本申请的第四方面提供一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得处理器执行本申请的第一方面提供的数据传输方法。
本申请的第五方面提供一种计算机程序产品，计算机程序产品包括：计算机程序代码，当计算机程序代码在电子设备上运行时，使得电子设备执行本申请的第一方面提供的数据传输方法。
附图说明
图1a为本申请实施例所述的数据传输方法应用的近场通信的场景的示例图；
图1b为电子设备之间建立多屏协同模式的一种方式的示例图；
图1c为电子设备之间建立多屏协同模式的另一种方式的示例图；
图1d为电子设备之间处于多屏协同模式的示例图；
图1e为电子设备之间建立的近场通信的链路的示例图；
图1f为电子设备之间建立的基于中继的近场通信的链路的示例图；
图2为本申请实施例提供的数据传输方法的流程图；
图3为本申请实施例提供的电子设备的结构的示例图；
图4为本申请实施例提供的进行数据传输的电子设备的软件框架示例图；
图5a和图5b为本申请实施例提供的数据传输方法的流程图；
图6a为本申请实施例提供的数据传输方法在一条实际传输速率最高的链路上传输数据的示例图；
图6b为本申请实施例提供的数据传输方法在多条链路上按照链路的实际传输速率传输数据的示例图；
图7a为本申请实施例提供的数据传输方法中丢包的示例图；
图7b为本申请实施例提供的数据传输方法中数据接收方建立的数据重传链表的示例图；
图7c为本申请实施例提供的数据传输方法中数据接收方建立的重传二叉树表的示例图；
图8为本申请实施例提供的进行数据传输的电子设备的内核层和硬件层的结构示例图；
图9为本申请实施例提供的获取目标链路的实际传输速率的流程图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式，除非其上下文中明确地有相反指示。还应当理解，在本申请实施例中，“一个或多个”是指一个、两个或两个以上；“和/或”，描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。
在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
本申请实施例涉及的多个，是指大于或等于两个。需要说明的是，在本申请实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。
图1a为近场通信场景的一种示例，图1a中，手机1与笔记本电脑2、平板电脑（Tablet Personal Computer，简称TabletPC、FlatPc、Tablet、Slates）3以及大屏4（也可以是智慧屏）之间，分别可以进入多屏协同模式、投屏模式、或者同享模式等，在这些模式下的电子设备之间建立近场通信，各个设备之间可以建立的近场通信如图1a所示，以蓝牙、WLAN以及WIFI为例。
以多屏协同模式为例，如图1b所示，手机1靠近笔记本电脑2的触控板后，手机1显示与笔记本电脑2的连接界面，用户在连接界面上点击“连接”控件后，手机1与笔记本电脑2进入多屏协同模式，如图1d所示。
或者，如图1c所示，笔记本电脑2的电脑管家的界面上显示“立即连接”控件，在用户点击“立即连接”控件后，电脑管家的界面上显示正在查找手机的提示信息，并且，在笔记本电脑2找到手机1后，在手机1显示连接界面，用户在连接界面上点击“连接”控件后，手机1与笔记本电脑2进入多屏协同模式。
如图1d所示，在多屏协同模式下，在笔记本电脑2上，显示手机1的协同窗口A，协同窗口A的显示内容与手机1当前显示的内容相同，以图1d为例，手机1当前显示一个桌面，笔记本电脑2的协同窗口A也显示相同的桌面。用户可以在手机1的界面或笔记本电脑2的协同窗口A中选择文件，并选择打开方式为“使用电脑打开”，在此场景下，需要将文件从手机1传输至笔记本电脑2。在目前的一些实现方式中，手机1通过WIFI、蓝牙或基于USB的有线连接等这些近场通信的方式，将文件传输至笔记本电脑2。
发明人在研究的过程中发现，在近场通信的场景下，特别是传输较大数据量的业务，较高的传输速率（较大的网络吞吐量）能够获得较优的用户体验，因此如何提高传输速率（即网络吞吐量），是需要解决的问题。
本申请实施例公开的数据传输方法，目的在于提高基于近场通信的数据传输的速率。
本申请的以下实施例应用在基于近场通信的数据传输场景，如前所述，近场通信的数据传输场景的一种示例为多屏协同模式。可以理解的是，以上建立多屏协同模式的方式仅为示例，还可以使用蓝牙或有线方式建立多屏协同模式。并且，多屏协同模式下的文件传输也仅为本申请的以下实施例的应用场景的示例，还可能，在无线投屏模式或者共享模式下传输文件，即应用场景还可以为无线投屏模式或者共享模式。文件也仅为传输的数据的一种示例，传输的数据还可能是指令、消息等。
在本申请的实施例中，处于近场通信的电子设备支持多链路的数据传输（即多种近场通信方式一并传输数据）。如图1e所示，多种链路包括：第5代移动通信点对点（5GPoint to point）链路、第二代移动通信（2G）点对点链路、第5代移动通信无线局域网（5GWireless Local Area Networks，WLAN）链路、2G WLAN链路、以太网（Ethernet，ETH）链路、蓝牙低功耗（Bluetooth Low Energy，BLE）链路、无线保真（Wireless Fidelity，WIFI）链路以及基于通用串行总线（Universal Serial Bus，USB）的有线连接链路。可以理解的是，图1e仅为示例，近场通信的方式并不限于图1e示出的方式。
可以理解的是，至少两个电子设备的近场通信可以为直连（即直接相连）模式，例如5G点对点为直连模式，还可以是中继模式。中继模式是指第一电子设备通过第二电子设备，与第三电子设备相连，例如，如图1f所示，手机1通过路由器3与笔记本电脑2相连，即手机1与笔记本电脑2之间建立WIFI链路。
为了更好实现降低数据的传输时延的效果，在本申请实施例适用的场景中，在中继模式下，相连的电子设备之间的间距小于或等于2跳。并且，在本申请实施例适用的场景中，假设近场环境下的传输路径的丢包近似可控（即近场通信链路的性能不再是瓶颈），并且，传输的数据包为轻量级数据包（如数据量小于1M的数据包）。但可以理解的是，这些限定条件仅为可选，并不作为对本申请的实施例的使用场景的限定。
本申请实施例所述的数据传输，可以是相连的电子设备在多种业务场景下的数据传输，业务场景的示例包括但不限于：
1、近距离大文件传输：如图1d所示的多屏协同、或者共享场景下的大文件的传输。
2、流媒体投屏：例如，可以将手机1上显示的屏幕的内容投屏到大屏4上显示，可以提升传输带宽，提升清晰度。
3、手机克隆业务：例如，将手机1里面的应用和账号信息、缓存等直接复制到其它电子设备中。
为了实现提高数据传输速率（即吞吐量）的目的，本申请实施例提供的数据传输方法的主要包括如图2所示的两方面：
A、多径高吞吐传输策略。
多径高吞吐传输策略包括：（1）通过WIFI协商速率以及一个通过WIFI协议特性计算得来的经验值系数，可以计算得到每条单径当前的最大允许的传输速率，将该速率设为初始传输速率，在刚开始发送时即保持高速状态。（2）队列规程（queue discipline，QDISC）拥塞控制方法（减少降速事件的发生次数）。
B、多径可靠性重传设计与收包拼装。
还以手机1与笔记本电脑2之间的数据传输为例，假设手机1的文件在笔记本电脑2上打开，手机1向笔记本电脑2传输文件，以上A主要由手机1实现，B由笔记本电脑2执行。
下面将针对电子设备的硬件结构以及软件框架，对图2所示的两方面进行详细说明。
本申请实施例公开的数据传输方法应用在电子设备。电子设备可以为平板电脑、PC、超级移动个人计算机（ultra-mobile personal computer，UMPC）、车载设备、上网本、个人数字助理（personal digital assistant，PDA）等具有多种近场通信功能的电子设备上，本申请实施例对电子设备的具体类型不作任何限制。
示例性的，图3是本申请实施例提供的一例电子设备100的结构示意图。以电子设备100是手机1为例，电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。
其中，传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processingunit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。
移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器（low noise amplifier，LNA）等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。
调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备（不限于扬声器170A，受话器170B等）输出声音信号，或通过显示屏194显示图像或视频。
无线通信模块160可以提供应用在电子设备100上的包括无线局域网（wirelesslocal area networks，WLAN）（如无线保真（wireless fidelity，Wi-Fi）网络），蓝牙（Bluetooth，BT），全球导航卫星系统（global navigation satellite system，GNSS），调频（frequency modulation，FM），近场无线通信技术（near field communication，NFC），红外技术（infrared，IR）等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。
在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统（global system for mobile communications，GSM），通用分组无线服务（general packet radio service，GPRS），码分多址接入（codedivision multiple access，CDMA），宽带码分多址（wideband code division multipleaccess，WCDMA），时分码分多址（time-division code division multiple access，TD-SCDMA），长期演进（long term evolution，LTE），BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统（global positioning system，GPS），全球导航卫星系统（global navigation satellite system，GLONASS），北斗卫星导航系统（beidounavigation satellite system，BDS），准天顶卫星系统（quasi-zenith satellitesystem，QZSS）和/或星基增强系统（satellite based augmentation systems，SBAS）。
应理解，除了图3中列举的各种部件或者模块之外，本申请实施例对电子设备100的结构不做具体限定。在本申请另一些实施例中，电子设备100还可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
在图3所示的电子设备上运行操作系统，操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请的实施例中，以手机1与笔记本电脑2进行近场通信，并且手机1运行分层架构的安卓操作系统为例。可以理解的是，进行近场通信的电子设备的操作系统可能相同也可能不同，例如笔记本电脑运行Windows操作系统。
下面以多屏协同场景为例对数据传输方法进行详细说明。
图4为进行近场数据传输的手机1和笔记本电脑2的软硬件模块的连接示例，其中，硬件层中以5G点对点网卡和WALN网卡示例，但可以理解的是，网卡还可以包括蓝牙网卡和NFC网卡等，并且，硬件层中参与数据传输的模块并不限于网卡，可以参见图8所示。
基于图4，手机1与笔记本电脑2基于近场通信进行数据传输的流程如图5a和图5b所示。其中，图5a中包括以下步骤：
S501、手机1的协同服务模块11检测到近场通信网络连接后，向发现连接模块12发送建立服务端的指令。
近场通信网络发生变化包括但不限于：近场通信的断开或连接。例如结合图1b所示，手机1放置在笔记本电脑2的触控板后，手机1的协同服务模块11检测到NFC网络连接。
S502、发现连接模块12向传输模块13发送建立服务端的指令。
也就是说，发现连接模块12调用传输模块13建立服务端。
S503、传输模块13建立服务端。
服务端的功能将在以下步骤中结合服务端对应的客户端进行说明。
S504、传输模块13向发送/接收引擎模块14发送初始化的指令。
也就是说，传输模块13触发发送/接收引擎模块14初始化。
可以理解的是，S503和S504的执行顺序不做限定。
S505、发送/接收引擎模块14初始化。
在某些实现方式中，初始化包括但不限于启动发送线程、接收线程等模块初始化工作，同时让固定端口处在监听状态，等待客户端的连接。
S506、发送/接收引擎模块14广播消息。
S507、电脑管家25向发送/接收引擎模块14发送消息的反馈消息。
结合图1b所示，在手机1接收到反馈消息后，手机1上显示取消控件以及连接控件，假设用户点击连接控件，则触发手机1与笔记本电脑2建立近场通信，即执行S508：
S508、发送/接收引擎模块14向笔记本电脑2的电脑管家25发送多屏协同触发指令。
可以理解的是，结合图4所示，发送/接收引擎模块14通过调用硬件层的某个网卡，以WLAN网卡和5G点对点网卡中的WLAN网卡为例，将多屏协同指令向笔记本电脑2中的WLAN网卡传输，笔记本电脑2的WLAN网卡接收到多屏协同触发指令后，逐层向上传输至电脑管家25。
S509、电脑管家25向协同服务模块21发送第一调用指令。
第一调用指令用于调用协同服务模块21实现多屏协同。
S510、协同服务模块21响应于第一调用指令，向发现连接模块22发送第二调用指令。
第二调用指令用于调用发现连接模块22实现连接。
S511、发现连接模块22响应于第二调用指令，向传输模块23发送建立客户端的指令。
即发现连接模块22触发传输模块23建立与服务端对应的客户端。
S512、传输模块23建立客户端。
可以理解的是，本实施例中，将手机1的传输模块13建立的模块称为服务端，将笔记本电脑的传输模块23建立的模块称为客户端，除此之外，笔记本电脑的传输模块23建立的模块称为服务端，传输模块13建立的模块称为客户端，这里不做限定。
S513、传输模块23向发送/接收引擎模块24发送初始化的指令。
即传输模块23触发发送/接收引擎模块24初始化。
S514、发送/接收引擎模块24初始化。
在某些实现方式中，本步骤的初始化包括但不限于：启动发送线程以及接收线程，全局服务的注册等。
S515、发送/接收引擎模块24将客户端的用户数据报协议（User DatagramProtocol，UDP）单播链路建立请求向发送/接收引擎模块14传输。
S516、发送/接收引擎模块14将UDP链路建立请求向服务端发送。
S517、发送/接收引擎模块14响应于服务端对UDP链路建立请求的响应，与发送/接收引擎模块24建立多条UDP单播链路。
UDP单播链路是指，基于UDP协议建立的一端对一端的链路。UDP链路与TCP链路相比，具有更低的时延。
在某些实现方式中，建立手机1和笔记本电脑2支持的所有的近场通信方式的传输链路，建立的UDP单播传输链路的类型的示例可以参见图1e所示。
可以理解的是，在手机1执行S517的过程中，有可能手机1或者笔记本电脑2的某种近场通信功能没有被开启，则可以在建立链路时开启该近场通信功能，并建立基于该近场通信功能的链路。例如手机1的蓝牙功能没有开启，则开启手机1的蓝牙功能，以便充分利用可用的近场通信方式。
在某些实现方式中，在被开启近场通信功能的电子设备显示开启提示，例如，在手机1上显示开启蓝牙功能的提示。在另一些实现方式中，在待开启近场通信功能的电子设备显示开启询问，并依据用户的操作，开启或不开启近场通信功能。例如，在手机1上显示开启蓝牙功能的问询信息，用户选择开启，则开启该功能，用户选择不开启，则不开启该功能。在不开启该功能的情况下，手机1与笔记本电脑2无法建立基于该近场功能的链路。
可以理解的是，建立UDP链路仅为一种实现方式，也可以建立TCP链路，还可以，建立一部分UDP链路，一部分TCP链路。
S518、发送/接收引擎模块14检测多条UDP单播链路的实际传输速率。
将任意一条UDP单播链路简称为目标链路，检测目标链路的实际传输速率的具体方式，将结合图8以及图9进行说明。
S519、发送/接收引擎模块14判断是否接收到发送接口调用指令，如果否，执行S518，如果是，执行S524。
接收到发送接口调用指令说明要进行数据传输，如果没有接收到发送接口调用指令，则说明目前没有数据传输的需求。
可以理解的是，可以周期性执行S519。
在本实施例中，结合图1d所示，假设用户在手机1的界面或者笔记本电脑2的协同界面，选中文件，并选择使用电脑应用打开，则触发S520。
S520以及后续步骤参见图5b所示：
S520、文件管理器15获取在电脑打开手机上的文件的指令。
可以理解的是，在笔记本电脑2的协同窗口A中选择打开方式为“使用电脑打开”的情况下，笔记本电脑2向手机1发送使用电脑打开文件的指令，发送该指令使用的链路可以为上述建立的至少一条链路。
S521、文件管理器15向发现连接模块12发送接口调用指令。
接口调用指令用于调用发现连接模块12的接口，向传输模块13建立的服务端下发文件传输指令。
S522、发现连接模块12向传输模块13发送接口调用指令，以调用传输模块13建立的服务端。
S523、传输模块13建立的服务端向发送/接收引擎模块14传输发送接口调用指令，以调用发送/接收引擎模块14。
可以理解的是，在S523之后，发送/接收引擎模块14接收到发送接口调用指令，因此，执行以下流程，还可能，在S523之后以及S524之前，恰好因为触发了S519的执行周期，所以，执行S519，因为发送/接收引擎模块14接收到发送接口调用指令，所以S519的判断结果为是，执行S524。
S524、发送/接收引擎模块14依据链路的实际传输速率，将文件的数据包分配至至少一条链路进行传输。
在某些实现方式中，在一个发送周期中，将数据包优先分配至实际传输速率最高的链路进行传输。以图6a为例，假设5G点对点链路的实际传输速率最高，则在当前发送周期中，将数据包分配至5G点对点链路进行传输。
可以理解的是，在因为在当前发送周期中将数据包分配至实际传输速率最高的链路（简称为第一链路）进行传输，所以，在下一个发送周期，可能检测到第一链路的实际传输速率不是最高。那么在下一个发送周期，传输数据包的链路不再是当前周期选择的链路。
在另一些实现方式中，在一个发送周期中，将数据包分配至多条链路进行传输。多条链路为实际传输速率较高的N条链路或者建立的全部链路。可以理解的是，从检测到实际传输速率的多条链路中选择实际传输速率较高的N条链路，作为传输数据的链路。例如，将检测到实际传输速率的多条链路按照实际传输速率从高到低排序，将排序在前N个的链路，作为传输数据的链路。
按照N条链路的实际传输速率或者QDISC（将结合图8进行说明）剩余长度的比例，为N条链路分配数据包。
需要说明的是，在选择N条链路的情况下，将待传输的数据包分配至N条链路，对于每个数据包，在一个发送周期内，仅分配至一条链路。以图6b为例，假设按照实际传输速率从图1e中选择的用于传输数据的若干链路为5G点对点链路、2G点对点链路、5G WLAN链路以及2G WLAN链路，则按照这些链路的实际传输速率的比例（假设为5:4:3:2），如下分配数据包：5G点对点链路传输数据包pkt1-pkt50（即50个数据包），2G点对点链路传输pkt51-pkt90（即40个数据包），5G WLAN链路传输pkt91-pkt120（即30个数据包），2G WLAN链路传输pkt121-pkt140（即20个数据包）。
综上所述，将数据分配至链路的方式包括纵向分配（自动切换）和横向分配（自适应分发）两种：
纵向分配（自动切换）：将当前多条链路中各链路按实际发送速率排序，将数据包优先分配给实际发送速率最高的链路，直至该链路中QDISC的剩余长度关联的发送速率低于一定阈值，则认为该链路进入准拥塞状态，停止向该链路对应的QDISC发送数据。此时数据包会重新被分配至当前实际传输速率最高的链路进行发送。对于已经被认为是拥塞的链路，当其QDISC的剩余长度关联的发送速率在阈值之上，则将其重新纳入排序的资格范围，恢复对其的数据包分发。
横向分配（自适应分发）：发送端检测多条链路中每条链路的实际传输速率，按照当前实际传输速率或者QDISC剩余长度的比例，对每一条链路进行一定量数据包的分配。若某链路当前实际发送速率高（QDISC剩余长度充足且物理层协商速率高），则会在单位时间内按比例被优先分配较多的数据包，若某链路当前实际传输速率低或者QDISC剩余长度小，则会按比例被分配较少甚至不分配数据包，直至实际传输速率或者QDISC剩余长度重新恢复一定数目后重新恢复发送。
可以理解的是，除了实际传输速率之外，配置信息也可以作为路径的选择依据。
配置信息包括但不限于：1、用户指定的近场通信方式。2、业务以及业务与近场通信方式的对应关系。
用户指定的近场通信方式是指，由用户预先指定的至少一种优先使用的近场通信方式，例如，用户指定蓝牙、WLAN以及NFC，则选择链路时，处理考虑实际传输速率之外，还要优先选择用户指定的近场通信方式。例如，从用户指定的近场通信方式中，选择实际传输速率较高的N条链路作为传输数据的链路。又例如，只要用户指定的近场通信方式的链路的实际传输速率满足条件（例如小于预设的阈值），则至少选择用户指定的近场通信方式的链路。
业务与近场通信方式的对应关系是指预设的某些业务对应的近场通信方式。例如，文件传输业务对应的近场通信方式为蓝牙和WLAN。例如，因为视频的数据量较大，所以配置视频数据传输对应5G WLAN和2G WLAN，只要5G WLAN和2G WLAN的时延满足条件（例如大于预设的速率阈值），选择5G WLAN链路和2G WLAN链路。
可见，除了考虑实际传输速率，还考虑配置信息选择传输数据的链路，在提高数据传输速率的前提下，还有利于实现更为灵活的传输方式的选择，从而进一步提升用户体验。
在某些实现方式中，配置信息可以由用户基于手机1显示的用户交互界面进行配置。
可以理解的是，依据时延和配置信息选择传输数据的若干链路的上述方式仅为示例，而不作为限定。
在一些实现方式中，选择的链路的数量（即上述N）依据以下规则确定：待传输的数据量越大，N越大，待传输的数据量越小，N越小。在另一些实现方式中，除了依据待传输的数据量确定N之外，为了满足近场通信场景下数据传输高速率的需求，N为大于1的整数。
S525、发送/接收引擎模块24向传输模块23传输接收到的数据包。
S526、传输模块23定期向发送/接收引擎模块14发送数据包的ACK数据包。
ACK数据为确认（Acknowledgement）数据，在笔记本电脑2接收到数据后，向笔记本1发送ACK数据。可以理解的是，每接收到一个数据包，发送该数据包的ACK数据包。
可以理解的是，在数据包的传输过程中如S524-S526，仍然检测链路的实际传输速率即执行S518，并在各个发送周期，使用最新检测到的实际传输速率选择链路传输数据包。
S527、传输模块23判断是否有丢包，如果是，执行S528，如果否，执行S529。
传输模块23可以依据数据传输协议确定是否有丢包，以传输文件的数据包为例，丢包是指没有接收到文件的全部数据包。
S528、传输模块23请求数据包重传并进行去重处理。
可以理解的是，传输模块23可以依据数据传输协议建立重传数据表，并依据重传数据表请求数据包重传，重传机制能够在获得UDP链路的低时延优点的情况下，提高数据传输的可靠性。具体的请求重传的流程不再赘述。
以图7a为例，假设发送/接收引擎模块14发送了编号分别为1-8的数据包，传输模块23没有接收到编号为2、5和7的数据包。
在一些实现方式中，笔记本电脑2建立如图7b所示的重传链表，重传链表中包括没有接收到的数据包的编号2、5和7。
在另一些实现方式中，笔记本电脑2建立如图7c所示的重传二叉树表，重传二叉树表的生成过程包括：多次执行划分流程，直到所有没有接收到的数据包的编号均被分配重传二叉树表上的节点位置。
划分流程包括：编号中居中的编号作为父节点，大于父节点的编号作为第一分支，小于父节点的编号作为第二分支。其中，居中的编号是指将待重传的数据包的编号按照大小进行排序得到的序列中，中间位置的编号（序列中编号的数量为偶数的情况下从两个中间位置任选一个）。可以理解的是，第一次执行划分流程时，编号是指没有接收到的数据包的编号，得到的父节点为二叉树的根节点。
对于第一分支和第二分支，分别执行上述划分流程，直到分支中仅包括一个编号。
重传数据表的建立能够确保接收到完整的文件，以使得基于UDP协议的数据传输具有更高的可靠性。需要说明的是，本实施例中，虽然使用若干链路传输数据包，即笔记本电脑2使用多条链路接收数据包，但不针对多条链路分别建立重传数据表，而是建立一个统一的重传数据表，以获得更低的时延。
在数据重传过程中有可能接收到多个相同的数据包，因此，需要进行去重处理。
可以理解的是，接收到数据包后，在重传数据表中查找接收到的数据包的编号，如果找到，则表示为重传的数据包，如果没有找到，表示为重复的数据包，释放重复的数据包。
基于图7b和图7c可知，假设待传输的数据包的数量为n，需要依次对比重传链表中的编号，则基于重传链表的查找复杂度为o(n)，其中，o(n)表示时间复杂度的计算函数。而重传二叉树表可以确定查找范围，例如，假设接收到的数据包的编号为3，则仅查找根节点5的第一分支节点即可，因此，能够降低查找复杂度。假设待传输的数据包的数量为n，则基于重传二叉树表的查找复杂度为o(log(n))。可见，二叉树结构能够降低去重的查找复杂度。
S529、发送/接收引擎模块24将文件的全部数据包向应用26发送。
可以理解的是，发送/接收引擎模块24可以按照数据包的编号拼装数据包，并将拼装后的数据包向应用发送。
S530、应用26打开文件。
从图5a和图5b所示的流程可以看出，从传输路径中选择实际传输速率最高的链路或者实际传输速率较高的多条链路发送数据包，所以，能够提高文件的传输速率。并且，作为接收端的笔记本电脑2进行基于二叉树表的去重处理，能够降低数据传输至应用的时延。
可以理解的是，以上S501-S517为图1b所示的手机1靠近笔记本电脑2的触控板触发的手机1与笔记本电脑2进入多屏协同模式的流程。如果是图1c所示的用户操作笔记本电脑2上的电脑管家触发手机1与笔记本电脑2进入多屏协同模式，则图4所示的各模块之间的流程为：
用户打开笔记本电脑2中的电脑管家应用程序25，并点击电脑管家应用程序25显示界面中的立即连接控件，触发执行电脑管家25向协同服务模块21发送多屏协同触发指令，协同服务模块21调用发现连接模块22，发现连接模块22调用传输模块23，传输模块23调用发送/接收引擎模块24，发送/接收引擎模块24通过硬件层向手机1的协同服务模块11发送多屏协同统触发指令。手机1的协同服务模块11调用发现连接模块12，发现连接模块12调用传输模块13，传输模块13调用发送/接收引擎模块14，发送/接收引擎模块14与发送/接收引擎模块24通过调用硬件层，建立多条近场通信的UDP单播链路。
下面将详细介绍检测目标链路的实际传输速率的具体实现方式。
可以理解的是，图4中所示的系统库和硬件层之间，通过内核层交互数据，对于任意一条传输数据的链路（以下简称为目标链路），内核层中与本申请的实施例相关的模块如图8所示。
基于图8所示的结构，在手机1向笔记本电脑2传输数据时，手机1的发送算法引擎14将待发送的数据包放入发送套接字缓冲区（Send socket buffer）16。
UDP/IP协议栈17（以及27）中定义了一些传输数据的协议和端口号，以及在位于不同地理位置的网络中的主机系统之间提供连接和路径选择。数据包的发送和接收的过程是在UDP/IP协议栈实现的。UDP/IP协议栈中定义了UDP协议。
可以理解的是，图5a和图5b所示的流程中，手机1和笔记本电脑2之间建立的是UDP链路，所以，传输的数据包由UDP/IP协议栈中的UDP协议处理：经过上层（如应用层）封装的数据包，由发送/接收引擎模块14放入Send socket buffer 16中，再由UDP/IP协议栈17中的UDP协议传输至队列规程（queue discipline，QDISC）18。QDISC 18是设备发送队列的一种，设备发送队列是发送节点UDP/IP协议栈CPU侧到驱动侧的数据发送队列。
QDISC 18中的数据由网卡控制器（network interface controller，NIC）的驱动19传输至发送环形缓冲区（TX Ring Buffy）110。在通信程序中，经常使用环形缓冲区作为数据结构来存放通信中发送和接收的数据。环形缓冲区是一个先进先出的循环缓冲区，可以向通信程序提供对缓冲区的互斥访问。
TX Ring Buffy110把数据包以直接内存存取（Direct Memory Access，DMA）方式复制到NIC队列（queue）111，NIC queue 111将数据包发送至对端的NIC queue 211。
在笔记本电脑2的一次数据接收过程中，NIC queue 211将接收到的数据包向接收环形缓冲区（RX Ring Buffy）210发送，NIC驱动29将RX Ring Buffy 210中的数据包向接收队列28发送，接收队列28中的数据经由UDP/IP协议栈所在的传输层处理后，缓存在接收套字缓冲区（Receive socket buffer）26。发送/接收引擎模块24将Receive socket buffer26中的数据包向上层应用传输。
结合本申请实施例的前述应用场景，在高速率数据传输时，一方面，发送端发送端的Send socket buffer在被数据包占满的情况下，可以通知上层，上层停止向Send socketbuffer发送数据包。所以，Send socket buffer基本不会发送拥塞而导致丢包。另一方面，如前述场景假设：近场环境下的传输链路的丢包近似可控，收发双方之间的近场通信的网络性能不再是瓶颈（丢包近似可控），并且，收发双方还有ACK机制所以，链路也可以保证不丢包。又一方面，接收端对接收到的数据包的处理速度较快。综上，结合图8所示，所以丢包主要发生在发送端由于QDISC的数据量大（例如队列已满）而导致的QDISC的主动丢包。
为了降低目标链路丢包的可能性，本实施例中采用的实际传输速率的获取策略为：在初始阶段，因为QDISC的剩余空间通常较大，所以实际的传输速率主要取决于网络的性能，因此，依据发送端和接收端协商的速率确定实际传输速率，以获得较高的初始传输速率。在发送的中期和后期，由于消息高速发送，因此网络可能发生拥塞，会有较多的数据包缓存在内核QDISC，所以，实际的传输速率将取决于QDISC的剩余长度（即剩余空间），所以依据QDISC的剩余长度确定实际传输速率，从而实现主动预防QDISC拥塞的目的。
依据上述策略，S510的实现流程包括如图9所示的以下步骤：
S901、判断目标链路的QDISC的剩余空间是否小于预设的队列阈值，如果是，执行S902，如果否，在当前发送周期不使用目标链路，或者，在当前发送周期更换目标链路。
队列阈值是为了在QDISC接近填满即准拥塞的情况下，不再执行以下检测实际传输速率的步骤，目的在于，停止向该链路发送数据，防止网络状态的抖动造成QDISC溢出。
可以理解的是，本次发送周期不使用目标链路或者更换目标链路，则导致目标链路（更换前的目标链路）的实际传输速率不被检测，在此情况下，目标链路（更换前的目标链路）不参与数据的传输。
S902、依据目标链路对应的QDISC队列的剩余空间确定第一传输速率。
第一传输速率可以理解为QDISC的剩余空间确定传输速率的上限值，即不超过该传输速率，就可以避免QDISC的主动丢包。
在某些实现方式中，第一传输速率按照式（1）获得：
（QdiscRemainLength-Threshold）* X /T（1）。QdiscRemainLength为QDISC的剩余长度，Threshold为预设的队列阈值，目的在于降低因抖动而导致的队列溢出。X为每个数据包的大小（即数据量如1472kB），T发送周期（如5ms）。
在另一些实现方式中，第一传输速率按照式（2）获得：
AmendSendRate=(QdiscRemainLength-Threshold）*X /T*P qdisc （2）
式（2）中，AmendSendRate为第一传输速率，QdiscRemainLength为QDISC的剩余长度，Threshold为队列阈值。P qdisc 为预设的系数（又可称为第一系数），可以为预先配置的经验值，目的在于防止抖动而导致的队列溢出，X为每个数据包的大小（即数据量如1472kB），T发送周期（如5ms）。
S903、以第二传输速率与第一传输速率中的最小值作为实际传输速率，发送数据包。
在建立近场链路时，双方设备协商确定的链路的传输速率。结合图5a和图5b所示，在S509中建立多条UDP单播链路时，手机1的发送/接收引擎模块14与笔记本电脑2的发送/接收引擎模块24之间协商确定协商速率。
在某些实现方式中，近场通信的设备之间为直连模式，例如图1e所示的手机1与笔记本电脑2的5G点对点方式，两端设备之间协商物理层速率，作为协商速率。在另一些实现方式中，近场通信的设备之间为中继模式，例如图1f所示通过路由器通信，两端设备之间通过中继设备，如路由器，交换传输速率，从而协商确定协商速率。
第二传输速率依据协商速率确定，第二传输速率可以理解为基于链路的传输速率的上限。
可以理解的是，协商速率为设备之间的最大传输速率，因此，为了保护两端设备，即能够防止网络抖动而导致的传输的数据超过链路的最大传输速率，在某些实现方式中，将协商速率与小于1的系数的乘积（又可称为第二系数），作为第二传输速率。
在另一些实现方式中，第二传输速率按照式（3）获得：
ValidSendRate=NegoSendRate* P msr （3）
其中，ValidSendRate为第二传输速率，NegoSendRate为协商速率，P msr （又可称为第二系数）为物理层协商传输速率和有效数据传输速率之间的系数，即为链路中有效数据的传输时间与全部数据的传输时间的比值。其中，全部数据是指按照协议传输的数据，全部数据由有效数据与按照协议添加的数据构成，例如，在笔记本电脑2中打开的文件包括的数据包为有效数据，而为了按照协议传输，在文件包括的数据包中需要添加某些数据。更利于理解的举例为：文件的一个数据包为“123”，有效数据即为“123”，全部数据为“00112300”。
实际传输速率可以表示为：RealSendRate=min(VSR，ASR)（4）。其中，VSR为第二传输速率，ASR为第一传输速率。
图9所示的流程，在发送初始化阶段，各条传输链路提前探测本链路内核QDISC缓冲区剩余长度。当本链路未被其他应用占用时，socket内核QDISC的缓冲区剩余长度较大时，则此时实际的传输速率取决于依据协商速率计算的最大的传输速率（如300Mbit/s），与基于TCP协议传输数据包过程相比，省去了慢启动阶段（慢启动阶段使用的初始速率较低），初始传输速率可达较高水平，从而能够提高数据传输初始阶段的近场链路资源的利用率，实现较高的吞吐量。
在发送中后期阶段，由于消息高速发送，而网络传输处理速率可能降低，因此会有较多的数据包缓存在内核QDISC，假设此时队列余量长度较小，则此时实际的传输速率将取决于socket内核QDISC余量长度。
通过主动探测socket内核QDISC余量在每个发送周期实时调整实际传输速率，既可以做到传输过程起步阶段以高速率发送数据包，同时可以做到预防式的拥塞控制，避免了在高速发送阶段QDISC主动发生丢包问题。
结合图5a和图5b所示，针对多条传输数据的链路，在数据传输的初始阶段，多条链路的总体的有效数据传输速率如式（5）：
VSR total = VSR 1 + VSR 2 +…+ VSR n （5）其中，n为多条链路的数量。可见，在初始阶段，能够保持一个较高的传输速率。
针对多条传输数据的链路，在中期和后期，多条链路的总体的有效数据传输速率如式（6）：
RSR total = RSR 1 + RSR 2 +…+ RSR n （6），RSR为实际传输速率。
可见，无论是数据传输的初始阶段还是中期和后期，多条路径可以保证较高的传输速率总和，因此，综上所述，能够提高吞吐量。
可以理解的是，对于S524中传输文件的每条链路，均作为目标链路执行图9所示的流程。
本申请的实施例还公开一种计算机可读存储介质，所述计算机可读存储介质中存储了计算机程序，当所述计算机程序被处理器执行时，使得所述处理器执行上述实施例所述的数据传输方法。
本申请的实施例还公开一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在电子设备上运行时，使得所述电子设备执行本申请的实施例还公开的数据传输方法。

Claims (12)

1.一种数据传输方法，其特征在于，应用于第一电子设备，所述方法包括：
与第二电子设备建立多条基于近场通信的用户数据报协议UDP单播链路，所述UDP单播链路用于所述第二电子设备显示所述第一电子设备的协同窗口，所述协同窗口显示的内容与所述第一电子设备当前显示的内容相同；多条UDP单播链路的类型不同；
检测多条基于近场通信的UDP单播链路的实际传输速率，其中，目标链路的实际传输速率依据所述目标链路的QDISC的剩余空间以及协商速率确定，所述目标链路为所述多条基于近场通信的UDP单播链路中的任意一条链路；
响应于在所述第一电子设备的显示界面中或者所述协同窗口中指示在所述第二电子设备打开所述第一电子设备中的文件的操作，依据所述实际传输速率以及预设的用于链路选择的配置信息，将所述文件的数据包分配至所述多条基于近场通信的UDP单播链路中的至少一条链路；
使用所述至少一条链路传输所述文件的数据包。
2.根据权利要求1所述的方法，其特征在于，所述检测多条基于近场通信的UDP单播链路的实际传输速率，包括：
至少依据所述目标链路的QDISC的剩余空间，获取第一传输速率；
依据所述目标链路的协商速率，确定第二传输速率；
将所述第一传输速率与所述第二传输速率中的最小值，作为所述实际传输速率。
3.根据权利要求2所述的方法，其特征在于，所述至少依据目标链路的QDISC的剩余空间，获取第一传输速率，包括：
至少依据所述目标链路的QDISC的剩余空间，确定数据包的个数；
至少依据所述个数、每个数据包的数据量以及每个发送周期的长度，确定所述第一传输速率。
4.根据权利要求3所述的方法，其特征在于，所述至少依据所述个数、每个数据包的数据量以及每个发送周期的长度，确定所述第一传输速率，包括：
依据所述个数、每个数据包的数据量、每个发送周期的长度以及预设的第一系数，确定所述第一传输速率。
5.根据权利要求3所述的方法，其特征在于，所述至少依据所述目标链路的QDISC的剩余空间，确定数据包的个数，包括：
依据所述目标链路的QDISC的剩余空间以及预设的队列阈值的差值，确定所述数据包的个数。
6.根据权利要求2-5任一项所述的方法，其特征在于，所述依据所述目标链路的协商速率，确定第二传输速率，包括：
依据所述协商速率与预设的第二系数的乘积，确定所述第二传输速率。
7.根据权利要求6所述的方法，其特征在于，所述第二系数为所述目标链路中有效数据的传输时间与全部数据的传输时间的比值。
8.根据权利要求2-5任一项所述的方法，其特征在于，在所述至少依据目标链路的QDISC的剩余空间，获取第一传输速率之前，还包括：
确定所述目标链路的QDISC的剩余空间小于预设的队列阈值。
9.根据权利要求1或2所述的方法，其特征在于，所述依据所述实际传输速率以及预设的用于链路选择的配置信息，将所述文件的数据包分配至所述多条基于近场通信的UDP单播链路中的至少一条链路，包括：
将所述数据包分配至实际传输速率最高的链路；或者，
依据所述实际传输速率的比值，将所述数据包分配至所述多条基于近场通信的UDP单播链路中的至少两条链路，其中，分配至所述至少两条链路的数据量的比例为所述比值。
10.一种数据传输系统，其特征在于，包括：
第一电子设备与第二电子设备；所述第一电子设备与所述第二电子设备之间建立多条基于近场通信的链路；
所述第一电子设备用于执行权利要求1-9任一项所述的数据传输方法；
所述第二电子设备至少用于请求数据重传以及进行去重处理。
11.一种电子设备，其特征在于，包括：
一个或多个处理器；
一个或多个存储器；
所述存储器存储有一个或多个程序，当所述一个或者多个程序被所述处理器执行时，使得所述电子设备执行如权利要求1-9任一项所述的数据传输方法。
12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储了计算机程序，当所述计算机程序被处理器执行时，使得所述处理器执行权利要求1-9任一项所述的数据传输方法。
CN202210126234.5A 2022-02-10 2022-02-10 数据传输方法及装置 Active CN114173314B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210126234.5A CN114173314B (zh) 2022-02-10 2022-02-10 数据传输方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210126234.5A CN114173314B (zh) 2022-02-10 2022-02-10 数据传输方法及装置

Publications (2)

Publication Number Publication Date
CN114173314A CN114173314A (zh) 2022-03-11
CN114173314B true CN114173314B (zh) 2022-07-12

Family

ID=80489785

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210126234.5A Active CN114173314B (zh) 2022-02-10 2022-02-10 数据传输方法及装置

Country Status (1)

Country Link
CN (1) CN114173314B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117135682B (zh) * 2023-02-09 2024-05-14 荣耀终端有限公司 获取发送速率的方法、第一电子设备及存储介质
CN117851789B (zh) * 2024-03-05 2024-05-31 北京珞安科技有限责任公司 一种基于人工智能的工控设备运行质量评估系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106851683B (zh) * 2017-01-10 2020-06-16 青岛海信移动通信技术股份有限公司 多频载波聚合wifi数据传输方法、装置及终端设备
US10594613B2 (en) * 2017-07-18 2020-03-17 Level 3 Communications, Llc Systems and methods for enhanced autonegotiation
KR20200122845A (ko) * 2019-04-19 2020-10-28 삼성전자주식회사 전자 장치 및 그 데이터 전송 제어 방법
CN113938945B (zh) * 2020-06-29 2023-11-28 华为技术有限公司 数据包发送的方法、装置

Also Published As

Publication number Publication date
CN114173314A (zh) 2022-03-11

Similar Documents

Publication Publication Date Title
US10499217B2 (en) Wireless sensor base station with coexistence of multiple homogeneous radios
CN114173314B (zh) 数据传输方法及装置
US11496576B2 (en) Quick relay traffic management for cloud messaging
WO2021121308A1 (zh) 一种多路径传输的方法及设备
US11082805B2 (en) Terminal and method for transmitting data
WO2021098533A1 (zh) 一种连接建立方法及终端设备
EP4258710A1 (en) Method for transmitting data in near field, device and system
CN105450676A (zh) 网络共享的方法、装置及网络共享系统
CN114268936B (zh) 数据传输方法及装置
JP2013168792A (ja) アクセスポイント装置及び無線通信方法
GB2497394A (en) Determining jitter buffer size in a wireless communication system
KR101663687B1 (ko) 다중전송계층을 이용한 ip-ptt 시스템 및 그의 제어방법
WO2022068666A1 (zh) 基于业务的中继选择方法及相关产品
CN116095019B (zh) 路由处理方法、装置、设备及存储介质
WO2023020465A1 (zh) 地址转换控制方法、装置、终端及网元
WO2024093430A1 (en) Data handling based on pdu set configuration

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant