CN110719294A - 网络技术 - Google Patents

网络技术 Download PDF

Info

Publication number
CN110719294A
CN110719294A CN201910999930.5A CN201910999930A CN110719294A CN 110719294 A CN110719294 A CN 110719294A CN 201910999930 A CN201910999930 A CN 201910999930A CN 110719294 A CN110719294 A CN 110719294A
Authority
CN
China
Prior art keywords
network
packet
data packets
packets
context
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.)
Granted
Application number
CN201910999930.5A
Other languages
English (en)
Other versions
CN110719294B (zh
Inventor
L·夏勒夫
B·W·贝瑞特
N·布沙拉
G·马丘利斯基
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.)
Amazon Technologies Inc
Original Assignee
Amazon Technologies Inc
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
Priority claimed from US14/983,436 external-priority patent/US9985904B2/en
Priority claimed from US14/983,434 external-priority patent/US9985903B2/en
Priority claimed from US14/983,431 external-priority patent/US10148570B2/en
Application filed by Amazon Technologies Inc filed Critical Amazon Technologies Inc
Publication of CN110719294A publication Critical patent/CN110719294A/zh
Application granted granted Critical
Publication of CN110719294B publication Critical patent/CN110719294B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/621—Individual queue per connection or flow, e.g. per VC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9057—Arrangements for supporting packet reassembly or resequencing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Acyclic And Carbocyclic Compounds In Medicinal Compositions (AREA)

Abstract

本申请涉及网络技术。提供了用于通过网络建立连接的系统和方法，这种连接的建立不需要用户应用与目标应用建立明确的连接。在一些实现方式中，提供了一种被配置为与网络和主机设备进行通信的装置。所述装置可以从所述主机设备接收消息和与所述消息相关联的目的地信息。所述装置还可以使用所述目的地信息来确定来自多个传输上下文的传输上下文。所述传输上下文可以包括与所述网络上的目的地的连接的状态。所述网络上的所述目的地可以与所述目的地信息相关联。

Description

网络技术
本申请是PCT国际申请号为PCT/US2016/068954、国际申请日为2016年12月28日、进入中国国家阶段的申请号为201680076964.1，题为“网络技术”的申请的分案申请。
背景技术
高性能计算可以由计算机集群来提供，计算机集群是作为一个高功率计算系统来运转的由相对低成本的计算机组成的网络。高性能计算通常需要集群中网络连接系统的高带宽和低延时。可以通过减少处理器在发送数据包的系统和接收数据包的系统两者中的参与来缩短事务延时。减少处理器在数据包传输中的参与的服务器消息传递协议可以被称为远程直接存储器访问(RDMA)协议，或者更一般地被称为具有内核旁路框架的协议。带有内核旁路框架的协议通常使用传输堆栈来在传送系统和接收系统之间进行通信。传输堆栈可以包括队列对，用于将数据包传输到网络并接收来自网络的数据包。传输堆栈还可以包括一个或多个传输服务，用于管理传送系统和接收系统之间的连接以及管理数据包的传送和接收。
附图说明
将参照附图描述根据本公开的各个实施方案，在附图中：
图1示出了计算资源集群的示例；
图2示出了可用于实现内核旁路框架的通信堆栈的示例；
图3示出了传输服务类型的示例；
图4示出了可以被配置为提供宽松可靠数据报传输的系统的示例；
图5A-5B示出了用户应用可以获得用户应用随后可以用于将消息传送到另一应用的地址句柄的过程的示例；
图6A-6B示出了用户应用可以使用地址句柄来传送消息的过程的示例；
图7A-7B示出了可以为包括宽松可靠数据报传输服务的系统实现的通信堆栈的示例；
图8示出了宽松可靠数据报传输可如何管理网络中的多条路径以实现可用路径的更高利用率的示例；
图9A-9B示出了宽松可靠数据报传输如何可以保证数据包的可靠递送的示例；
图10A-10B示出了已经被分成细流(flowlet)的单个数据包流的示例以及接收用户应用接收数据包的顺序；
图11示出了为将要通过网络发送消息的用户应用确定传送上下文的过程的示例；
图12示出了用于获取地址句柄的过程的示例；
图13示出了用于通过网络传送数据包以及监测每个数据包的状态以确保每个数据包被递送的过程的示例；
图14示出了用于通过网络接收数据包并且为每个数据包生成响应以指示数据包已被接收的过程的示例；
图15示出了可用于实现本文所描述的系统和方法的网络适配器设备的示例；
图16示出了根据一些实施方案的本文所描述的特征和系统的示例体系结构，其包括经由一个或多个网络连接的一个或多个服务提供商计算机和/或用户设备；以及
图17示出了根据一些实施方案的用于实现各方面的计算系统的示例环境的各方面。
具体实施方式
在以下描述中，将描述各个实施方案。出于解释的目的，将阐述具体的配置和细节，以便提供对实施方案的透彻理解。然而，对本领域技术人员将明显的是，也可以在没有具体细节的情况下实行实施方案。此外，为了不使所描述的实施方案变得模糊，可能会省略或简化众所周知的特征。
高性能计算可以由计算机集群来提供，计算机集群是作为一个高功率计算系统来运转的由相对低成本的计算机组成的网络。为了提供高性能，集群中的网络连接系统应支持高带宽，并且在计算机集群中的系统之间传送的消息应具有尽可能最低的延时。诸如传输控制协议/互联网协议(TCP/IP)之类的常见网络协议通常面向跨许多不同类型的网络的互操作性，而不是最大化带宽和最小化延时。因此，高性能计算集群通常使用能提供内核旁路框架的服务器消息协议。绕过操作系统内核操作可能会大大提高网络带宽并缩短传输延时。提供内核旁路框架的网络协议通常被称为远程直接存储器访问(RDMA)协议，但在大多数情况下，RDMA只是这些协议提供的一种特征。
提供内核旁路框架的网络协议通常使用传输堆栈来传送和接收网络数据包。传输堆栈通常提供一个或多个传输服务。这些传输服务通常分为连接型或无连接型，以及可靠型或不可靠型。连接传输服务类型通常会对计算集群的可扩展性产生负面影响。对于连接型传输服务，随着连接到集群的系统数量的增大，连接数量也可能会急剧增大。可靠未连接传输服务类型可能更具可扩展性，但通常对网络中丢弃的数据包的容忍度较低。因此，高性能计算系统可以通过在可能具有大于可忽略不计的数据包丢弃率的网络上是可扩展且可靠的传输服务类型来改进。
可靠性-即确保数据包递送-可以在网络适配器设备上得到最好的处理。网络适配器可能能够快速确定数据包何时被丢弃，并且可以快速生成重发那些数据包的请求。让主机设备上运行的软件来处理可靠性可能会对延时产生负面影响。为使软件确保可靠的数据包递送，数据包必须递送到传输堆栈、到操作系统内核或到用户应用，并且可能由于各种原因(例如操作系统繁忙)而延迟。因此，可以通过避免必须穿越传输堆栈而导致的潜在延迟来比较有效地处理数据包可靠性操作。
然而，数据包丢弃和数据包重传可能会导致数据包无序到达目的地系统。在可能会出现数据包丢弃的系统中，重新排序不按顺序到达的数据包通常与保证数据包递送一起处理，例如在网络适配器设备处。但是，数据包重新排序可能需要大量的计算，而网络适配器设备的处理器通常是低功耗、低成本的。另一方面，主机设备的处理器通常是高性能的，并且可以轻松地管理数据包重新排序。但是，正如已经指出的那样，让主机设备软件处理数据包重新排序和可靠数据包递送可能效率不高。
本文公开了用于提供可靠的数据包递送和数据包重新排序的系统和方法，其中在网络适配器设备处处理可靠性，而由主机设备上的软件处理数据包重新排序。还提供了宽松可靠数据报传输服务。宽松可靠数据报传输提供了保证可能会偶尔丢弃数据包的网络上的数据包递送的机制。被配置为使用宽松可靠数据报传输的网络适配器设备可以避免缓存数据包，而是尽可能快地将它们递送到主机设备。然后，主机设备可以根据需要重新排序数据包。本文所描述的这些系统和方法可以通过在集群上提供高带宽和低延时的传递，来在低成本计算集群上实现高性能计算。
集群计算资源可以以较低的成本提供较好的性能和可扩展性。图1示出了计算资源的集群100的示例。集群是与交换机连接，并被配置为并行运行的一组计算资源。在许多实现方式中，各种计算资源形成单个逻辑计算资源。图1中所示的示例性集群100包括多个节点102a-h和交换机104a-c。在一些实现方式中，集群100还可以包括路由器106。
图1中所示的节点102a-h可以表示各种计算资源。例如，一个或多个节点102a-h可以是计算机，例如服务器计算机。集群应用中所使用的计算机可以包括一个或多个处理器，并且这些处理器可以包括一个或多个处理核心。这些计算机还可以包括存储器和外围设备。在一些实现方式中，这些计算机可以使用适配器设备来连接到集群100中的交换机104a-c。计算资源的其他示例包括存储设备(例如，硬盘驱动器)、存储子系统(例如，存储设备阵列)、输入/输出(I/O)模块以及用于管理对集群100的访问的控制台。
交换机104a-c可以在各个节点102a-h之间提供连接。每个节点102a-h都可以通过与交换机104a-c的连接而连接到集群100。在一些情况下，节点102a-h可连接到一个以上的交换机104a-c。交换机也可以连接到其他交换机。在大多数情况下，交换机104a-c上的任何端口都可以用于连接到节点102a-h或另一交换机。在大多数实现方式中，通过连接更多的交换机和节点，可以快速且容易地扩展集群100的大小。
交换机104a-c的网络可以提供从任何节点102a-h到任何另一节点102a-h的多条路径。交换机104a-c可以具有与另一交换机104a-c的多个连接，这提供了交换机104a-c之间的附加路径。在一些情况下，节点102a-h可以连接到一个以上的交换机104a-c，这也会产生更多路径。来自一个节点102a-h的数据包可以同时使用多条路径来到达另一节点102a-h。另选地或另外地，从一个节点102a-h到另一个节点102a-h的数据包可以仅沿一条路径传输。在一些情况下，在每个交换机104a-c处都可以作出关于数据包将沿哪条路径传输的决定。在其他情况下，可以预先通常在源节点处确定数据包的路径。从一个节点102a-h到另一个节点102a-h的数据包流可以被称为数据包流，或者简称为“流”。在一些情况下，流中的数据包是相关的，例如当数据包一起形成一条消息时。
在一些实现方式中，交换机104a-c中的一个或多个可以包括负载平衡功能。在这些实现方式中，交换机104a-c可以被配置为尝试有效地分布网络流量。目标通常是确保节点和交换机之间的链路不会发生拥塞，并且确保数据包流量尽可能快地流过集群100。然而，在许多情况下，交换机104a-c仅知道它们自己的流量负载，而不能看到其他交换机104a-c上的负载。
在一些实现方式中，集群100可以连接到路由器106。路由器106可以提供到诸如其他集群或子网(子网)、局域网(LAN)、广域网(WAN)或互联网等其他网络108的连接。
互连的交换机104a-c(以及路由器106，如果存在的话)可以被称为交换结构、结构或更简单地称为“网络”。这里，术语“结构”和“网络”可以互换使用。
诸如所示出的集群100的计算集群可以提供更强的计算能力和更好的可靠性。各个计算资源可以协同工作来解决一台计算机可能无法单独解决或者可能需要很长时间才能单独解决的大问题。在某些情况下，计算集群可能会提供类似于超级计算机的性能，但成本更低和复杂性更低。计算集群所使用的交换结构体系结构也可能具有容错和可扩展的优点。在交换结构体系结构中，通常每条链路在链路的每一端都附接有一个设备。因此，每条链路仅取决于至多两个设备的行为。交换结构也可以通过添加更多交换机来轻松扩展，从而提供更多端口来连接更多节点。在某些情况下，添加更多交换机可能会增大集群的总带宽。节点之间的多条路径也可能会使总带宽保持较高，并且提供冗余连接，以防链路发生故障。
计算集群可用于各种应用中。例如，计算集群可以用于高性能计算。高性能计算涉及使用并行处理来运行计算密集型应用。科学研究人员、工程师和学术机构可能会将高性能计算用于复杂的建模或模拟，例如汽车碰撞模拟、天气建模、原子模拟等等。计算集群的其他示例用途包括机器学习、金融应用、分布式存储和数据库。机器学习涉及检查大量数据，以及执行可以从数据中学习并做出预测的算法。诸如高频交易之类的金融应用也可以检查大量数据，并且人们通常依赖于金融应用来对数据变化作出快速反应(例如，比人快得多)。分布式存储允许从多个位置访问非常大量的数据。存储区域网络是分布式存储的一种形式。数据库也存储大量数据，并且必须提供非常快速的查找存储在数据库中的特定信息的方法。
为了从集群计算资源中获得最大收益，用于节点间通信的协议应该提供高带宽和低延时。高带宽意味着大量的流量应该能够穿越集群，而低延时意味着流量应该能够尽可能快地从源传输到达目的地。一些操作可能是延时的主要原因。这些包括由于在操作系统中执行网络协议代码、移入和移出内核模式以及发送数据所需的上下文切换和/或在网络适配器上用户级缓冲区和存储器之间的数据的过度复制而导致的开销。例如，假设一个非拥塞的延迟几乎为零的网络，典型的网络协议堆栈可能会导致大约100微秒的往返延时。然而，这种延迟可能更典型地与由于调度延迟导致的毫秒长的尖峰、当应用不是为了避免网络堆栈问题而设计时的数十毫秒长的尖峰和/或当数据包在拥塞的链路上被丢弃时的长达数秒的延迟混合在一起。计算集群可能会采用高带宽硬件来设计，而高带宽硬件通常对处理器和存储器复制开销更为敏感。
诸如(TCP/IP)之类的网络协议倾向于关注于跨许多不同类型的网络的良好性能，和/或具有成本效益。因此，诸如TCP/IP之类的协议往往具有较高的延时并且往往很复杂。虽然网络协议(如TCP)可能适合于通过不同类型的网络进行通用通信，但高带宽、低延时环境可能会受益于比较专门化的协议。
虚拟接口(VI)体系结构(VIA)服务器消息传递协议的开发是为了在计算集群中节点之间提供高带宽、低延时链路。类似于VIA的协议的示例包括InfiniBand、互联网广域RDMA协议(iWARP)和融合以太网的RDMA(RoCE)。这些协议中的每一个都包括内核旁路框架，通常称为RDMA，下面将对其进行更详细的描述。iWARP通过TCP/IP协议提供内核旁路框架。RoCE通过以太网类型网络来提供内核旁路框架。InfiniBand通过InfiniBand特定的网络来提供内核旁路框架。有时术语“InfiniBand”和“RDMA”可以互换使用，但其他协议(如iWARP和RoCE)也提供RDMA样式的内核旁路框架。
VIA型协议通常提供低延时、高带宽和内核旁路网络。VIA类型的协议旨在提供至少以下优点：减少多个用户应用之间的资源共享所带来的开销、从处理器中移除传输协议处理的工作、更快的批量数据传递、以及减少等待远程应用所花费的时间。
VIA类型的协议旨在减少多个用户应用之间的资源共享所造成的开销。典型的网络协议堆栈在内核级别运行，并且有助于在多个应用之间共享网络接口。但是，这种资源共享可能会导致网络延迟，原因至少有下面几个：多个处理器核心之间的协调可能会增大延时；用于唤醒应用的处理器间中断可能会增大延时；可能需要中间队列或缓冲来保护应用不受彼此影响，以及队列或缓冲区之间的复制可能会增大延时；并且在内核缓冲区与应用缓冲区之间可能需要来回进行复制，因为可能没有为这些应用配置直接存储器访问(DMA)。
避免多个用户应用试图共享单个网络接口所引起的延迟的一种方法是使网络接口一次只由一个应用使用。数据平面开发工具包(DPDK)提供了一个使这成为可能的框架的示例。DPDK框架可以以用户空间轮询模式设备驱动器的形式来提供简单的网络接口。DPDK框架还可以替代其他操作系统服务，从而为用户应用提供应用编程接口(API)，并提供为单用户协作多任务设计的执行模型。该框架对于网络基础设施(例如，网关设备)可能是有效的，但对于常规用户应用和中间件可能不实用，常规用户应用和中间件可能需要重写以适应DPDK特定的API。DPDK框架也可能需要root特权才能运行，这可能会给内核带来负担，并可能会带来安全风险。此外，DPDK框架在多用户环境中可能不实用，因为DPDK环境可能要求应用使用物理存储器地址，这限制了虚拟机的使用。即使对于单个用户来说，DPDK框架也可能不切实际。DPDK和类似的模型可以被扩展为承担传输堆栈的责任，且从而能够为多个应用提供服务。但是，这些应用与DPDK过程之间的通信可能会导致严重的延时。
另一种有效地共享硬件资源的方法是内核旁路框架，如上所述，其通常称为RDMA框架。基于RDMA的设备可以被非特权用户应用使用。基于RDMA的设备还可以允许多个应用直接访问硬件而不会相互干扰。RDMA设备可能仅依靠内核来进行控制操作，执行初始化以及中断处理可能需要的一些协调，但是除此之外，RDMA设备可以独立于内核运行。这意味着处理器不需要参与RDMA操作。RDMA框架还可以提供诸如轮询模式完成处理的优化，这对于提供超低延时可能是有益的。
如上所述，VIA型协议旨在减少处理器在管理传输协议方面的参与。如前所述，处理器参与管理网络协议是潜在的延时来源。当应用向远程目的地发送长消息时，本地和远程计算机上的处理器都可能参与。例如，处理器可能需要将消息分成数据包、将数据包单独提交给硬件队列进行传输、接收数据包、生成确认数据包以及确定将数据放置在主机存储器中的什么位置。具体而言，当数据包到达时，简单的网络接口卡可能会通过外围总线将数据包传递到主机设备的主存储器，然后，向处理器发出中断，而中断可能需要一些时间才能实际提醒处理器。一旦被中断，处理器就可能会运行协议处理操作，例如生成确认，通常是在操作系统引起附加的延迟之后。
网络适配器被配置为处理协议操作，为处理器移除这些操作，可以更快地处理每个数据包。网络适配器设备可能能够处理传入消息和远程读取和写入命令。网络适配器也可能能够执行到主机存储器的DMA事务，并生成确认数据包。网络适配器可能能够在不中断处理器的情况下执行这些操作。
如前所述，VIA型协议的另一个目标是为数据提供更快的批量传递。数据的批量传递，即大块数据传递，可以通过简单地增大网络链路的带宽来更快地执行。但是，高速网络互连可能会给源和/或目的地计算机的存储器子系统带来负担。存储器子系统通常不会过度配置，并且在会导致将中间副本放入存储器中的高带宽网络传递过程中多次访问时，可能成为瓶颈。当批量传递需要多个副本时，此复制可能会限制传递的吞吐量，这可能会增大事务延时。包含大型3级(L3)高速缓存的处理器提供了一种缓解此延迟的可能方法。这些处理器可能会让网络接口卡将数据直接写入L3高速缓存。但是，由于高速缓存的特性(需要获取不在高速缓存中的数据，因此会导致延时)，这些处理器可能会不一致地执行。此外，当数据未被快速复制时，L3高速缓存可能没有帮助，因为数据可能会占用L3高速缓存中的可用于更有用的数据的空间。
内核旁路框架通过一个通常称为“零复制”数据传递的过程来提供更好的解决方案。零复制是RDMA所提供的操作之一。RDMA描述了直接存储器访问(DMA)的扩展。DMA通常允许某些硬件子系统在不使用处理器的情况下访问主系统存储器。同样，RDMA允许一台计算机通过网络来访问另一台计算机上的存储器，而不涉及任何一台计算机中的处理器。因此，本地计算机可能能够在远程计算机的存储器上执行读取、写入或原子操作，而无需本地或远程计算机上的处理器进行中间复制。在很多实现方式中，通过本地计算机和远程计算机各自都具有RDMA适配器，来使得RDMA成为可能。
如前所述，VIA型协议还试图减少等待远程应用所花费的时间。应用本身可能会导致网络延时。网络事务可能会涉及本地计算机和远程计算机上的应用。远程应用可能需要一些时间来响应事务，例如由于调度延迟。只涉及本地应用的“单边”RDMA通信可以减少等待远程应用所造成的延时。通过允许访问其存储器，远程应用可能不需要参与数据传递。相反，远程计算机上的RDMA适配器可以能够直接访问远程存储器，而不涉及远程应用。除了读取和写入操作之外，RDMA还可以提供远程原子操作，这可以减少由锁定操作引起的延时。
总之，VIA型的协议可以减少由多个用户应用之间的资源共享引起的开销。VIA协议也可能会从处理器中移除传输协议处理的工作。这些协议还可以提供更快的数据批量传递，并减少等待远程应用作出响应所花费的时间。这些操作通常被描述为RDMA操作，虽然它们可以被更一般地描述为内核旁路操作。这些特征也可以被称为远程存储器访问(RMA)或单边通信。
图2示出了可用于实现内核旁路框架的通信堆栈200的示例。通过使用通信堆栈200，例如如图2所示，客户端进程202可能能够与远程系统232上的远程进程204直接进行通信，而无需来自本地系统230或远程系统232上的处理器的帮助。图2的示例作为示例示出了在两个不同系统上执行的两个进程之间的通信堆栈200。如下面将要解释的，可以在通过网络结构220进行通信的任何两个进程之间配置类似的通信堆栈。而且，尽管一个系统230被称为“本地”，而另一个系统232被称为“远程”，但应理解的是，在一些实现方式中，通信堆栈200也可以反向操作，使得远程系统232可以发起发往本地系统230的消息。
在一些实现方式中，图2中所示出的通信堆栈200在最少使用本地230或远程232系统处的处理器的情况下运行。从处理器去除或减少网络流量控制职责可以通过“工作队列”来完成，工作队列也被称为“工作队列对”或简单地称为“队列对”210a-b。对于本地系统230和远程系统232之间的每个通信信道，可以在两个系统230、232处分配队列对210a-b。队列对210a-b包括流向网络结构220的流量的发送队列212a-b，以及从网络结构220发出的流量的接收队列214a-b。在一些实现方式中，客户端进程202在与远程进程204建立通信信道时启动队列对210a-b。在这些实现方式中，客户端进程202可以启动用于与同一远程进程204、在相同的远程系统232上运行的不同进程或在其他远程系统上运行的进程进行通信的附加工作队列。客户端进程和远程进程包括非内核或操作系统进程，如用户应用和/或驱动器程序。
在一些实现方式中，本地系统230上的队列对210a驻留在源信道适配器208a上。源信道适配器208a可以被配置为与网络结构220进行通信。源信道适配器208a可以包括已分配给其他进程、分配给同一客户端进程202或当前可能未使用的附加队列对。在一些实现方式中，可以清楚地理解队列对210a的使用和结构，并且因此队列对210a可以用硬件来实现。在其他实现方式中，队列对210a可以用软件(例如以驱动器)或硬件和软件的组合来实现。除了队列对210a之外，源信道适配器还可以包括传输层216a，其管理与网络结构220和远程进程204的通信。源信道适配器208a还可以包括将源信道适配器208a连接到结构220的物理端口218a。源信道适配器208a也可以被称为主机信道适配器，或者更一般地被称为网络适配器。
客户端进程202可以通过将“工作队列元素”222(通常缩写为WQE)放入本地发送队列212a来向远程进程204发起事务。工作队列元素222可以包括诸如读取、写入或原子事务之类的事务。在一些实现方式中，工作队列元素222还可以包括将远程进程204标识为事务的目标的信息。源信道适配器208a可直接从发送队列212a处理工作队列元素222。源信道适配器208a可以使用工作队列元素222中的信息来生成一个或多个数据包。传输层216a可以通过端口218a将这些一个或多个数据包传输到网络结构220。
远程系统232可以在其自己的目的地信道适配器208b(也称为目标信道适配器或更一般地称为网络适配器)上接收来自网络结构220的一个或多个数据包。像源信道适配器208a那样，目的地信道适配器208b包括将目的地信道适配器连接到网络结构220的端口218b。目的地信道适配器208ab还可以包括传输层216b，其管理与网络结构220和客户端进程202的通信。目的地信道适配器208b还可以包括分配给远程进程204的队列对210b。
在远程系统232上从网络结构220接收到的一个或多个数据包可以由传输层216b引导到接收队列214b。在一些实现方式中，目的地信道适配器208b可以重新汇编由客户端进程202生成的消息222，并且将重新汇编的消息放入接收队列214b中。当元素到达其接收队列214b时，可以自动通知远程进程204。远程进程204可以从接收队列214b中弹出元素224，可以对元素224进行操作，且然后，在一些情况下，可以生成要返回给客户端进程202的响应。远程进程204可以将包含响应的工作队列元素226放置在其自己的发送队列210b中。然后，响应可以遍历结构220，回到本地系统230，在那里它作为“完成队列条目”228(通常缩写为CQE)被递送到客户端进程202。
在这种信息交换中，本地系统230和远程系统232上的操作系统内核都可能不是必需的。例如，可能不需要客户端进程202和远程进程204来仲裁其各自的网络适配器卡的使用，对于没有实现内核旁路的系统可能是这种情况。相反，每个进程202、204都可以假设它具有排除另一进程202、204而独占的通信信道。实际上，多个进程可以使用网络适配器卡208a-b通过网络结构220进行通信，但是，网络适配器卡208a-b管理多个进程与它们各自的队列对之间的仲裁。另外，传输层216a-b可以管理客户端进程202和远程进程204之间的连接，诸如例如跟踪由网络结构220发送和接收以及可能会丢弃的数据包。
在许多实现方式中，传输层216a-b可以支持发送队列212a-b的多个操作。例如，传输层216a-b可以支持典型的发送和接收操作，其中一个进程提交消息，而网络上另一系统上的另一进程接收该消息。作为另一示例，传输层216a-b也可以支持RDMA写入，其中一个进程直接写入远程系统的存储器缓冲区。在本示例中，远程进程会提前给予发送系统适当的访问特权，并且会为远程访问注册存储器缓冲区。作为另一示例，传输层216a-b可以支持RDMA读取，其中一个进程直接从远程系统的存储器缓冲区中读取。在本示例中，远程系统也会提前给予发送系统适当的访问特权。作为另一示例，传输层216a-b也可以支持RDMA型原子操作。一种这样的原子操作是“compare and swap”，其中进程读取远程存储器位置，并且如果读取的数据是指定值，则在相同的远程存储器位置写入新值。另一个原子操作是“fetch add”，其中进程从远程存储器位置读取数据，将读取的数据返回给调用方，且然后将指定值与数据相加，并将修改后的值写回到同一远程存储器位置。
在一些实现方式中，传输层216a-b还可以支持接收队列214a-b的操作。例如，传输层216a-b可支持称为“接收后缓冲区”的操作，其中识别出可用作由另一系统发起的发送、RDMA写入和RDMA读取的目标的缓冲区。
在一些实现方式中，当启动队列对时，发起过程可以将队列对与传输服务类型相关联。然后，传输服务类型可以确定如何将数据包从源系统传输到目的地系统。图3示出了传输服务类型300的示例。由VIA型协议使用的传输服务类型300可以被分类为连接型302或未连接型304，以及可靠型306或不可靠型308。连接型302和未连接型304描述了在发送进程和接收进程之间是否建立了明确的连接。对于连接型302传输服务类型300，在大多数实现方式中，连接对于发送和接收进程是排他的。对于未连接型304传输服务类型300，数据包或“数据报”被发送到网络中，并且它们通常沿着可用的任何路径传输到其目的地。可靠型306和不可靠型308描述了传输服务类型300是否保证数据包的递送。可靠型306传输服务类型300通常保证递送，而不可靠型308传输服务类型300通常不能保证递送。
连接型302、可靠型306传输服务类型300的示例被称为可靠连接310(RC)。可靠连接310保证数据包的按序递送。按顺序表示消息以与源应用发送它们的顺序相同的顺序递送到目的地应用。可靠连接310还需要在每一对通信进程之间明确建立连接。建立明确连接的步骤示例如下：客户端进程可以首先使用通信堆栈(例如，图2的通信堆栈200)来查找目的地系统的网络地址。接下来，客户端进程可以请求传输层创建连接上下文。然后，客户端进程可以请求传输层(或传输管理)将连接上下文与远程目的地地址相关联。最后，传输层(或传输管理)可以执行与目的地系统的消息交换(例如，“握手”)以建立连接。
返回到图3，建立明确的连接可能会使得可靠连接310型传输服务难以扩展。如上所述，为使两个进程通过网络进行通信，必须建立明确的连接。因此，随着进程被添加到连接到网络的节点，连接数量会急剧增大。例如，如果本地系统上的100个进程要与远程系统上运行的所有100个进程进行通信，则必须建立100x 100或10,000个连接。此外，计算集群可能有数百个节点，并且每个网络节点都可能正在执行数百个或更多的处理器，从而导致集群需要、潜在地需要成千上万的连接。
可能潜在地更具可扩展性的传输服务类型300是不可靠数据报316(UD)。不可靠数据报316不需要建立明确的连接，并且不保证递送。不保证递送意味着发送方将数据包传送到网络结构中，并且不会努力确定数据包是否到达其目的地。不可靠数据报316可以用于传递用于管理目的的消息，诸如例如被交换以建立可靠连接310的消息。由于不可靠数据报316不能保证数据包递送，因此它可能在数据包丢失不频繁的网络(诸如例如InfiniBand网络)中有效。然而，在可能发生数据包丢弃的网络中，不可靠数据报316并未被广泛使用。
不可靠连接312也可以用于可能会发生数据包丢弃的网络中。像可靠连接310那样，不可靠连接312需要建立明确的连接，但确保递送。不可靠连接312可以用于可以容忍数据包丢弃的应用(诸如例如用于视频流式传输的应用)，但是对于较不耐数据包丢弃的应用来说是有问题的。
可靠数据报314(RD)不需要建立明确的连接，并保证所有数据包的递送。可靠数据报314最初是为缓解可靠连接310的可扩展性问题而开发的，但是以单连接性能为代价。结果，可靠数据报314未被广泛使用。
已经开发了多种传输服务类型300，其尝试将主要传输服务类型300的理想方面结合起来。开发了扩展可靠连接318(XRC)，以解决可靠连接310的可扩展性问题。扩展可靠连接318允许一个进程针对该进程正在与之进行通信的目的地系统上的所有进程，对于每个目的地系统仅使用一个连接。然而，已知扩展可靠连接318具有复杂的应用接口。动态连接320(DC)试图将可靠连接310的数据包递送保证与不可靠数据报316的缺乏明确连接要求组合。对于动态连接320，连接不像可靠连接310那样是固定的，而是根据需要进行建立，并在不再需要时将其移除。然而，动态连接320是为数据包丢弃非常罕见的InfiniBand型网络开发的。因此，动态连接320可能在更频繁发生数据包丢弃的网络中遭遇效率低下。
宽松可靠数据报322(RRD)(在下面的章节中进一步详细描述)可以在数据包丢弃并不罕见的网络中提供可扩展性和有保证的数据包递送。宽松可靠数据报322可以向用户应用提供与不可靠数据报316类似的简单无连接接口。宽松可靠数据报322还保证数据包递送，类似于可靠连接310。宽松可靠数据报322不按顺序递送数据包，从而简化了传输设计并潜在地提高了数据包递送的效率。
图4示出了可以被配置为除了上述传输服务的一个或多个之外还提供宽松可靠数据报传输的系统400的示例。尽管根据硬件和软件部件来描述，但示例系统400主要是功能描述，而所示的各种部件可以以硬件、软件、硬件和软件的组合以及以除了由本特定示例所描述的配置之外的逻辑和/或物理配置来实现。
示例系统400包括主机设备410和网络适配器设备420。主机设备410和网络适配器设备420可以通过诸如电缆、插头、插座、插槽、印刷电路板或这些物理部件的组合之类的物理连接来进行通信。主机设备410可以是通用计算系统，包括诸如一个或多个处理器、存储器子系统、外围设备等这里未示出的部件。在一些实现方式中，下面描述的网络适配器设备420的操作可以以集成电路器件和/或集成电路器件集合来实现。例如，在各种实现方式中，网络适配器设备的操作可以以片上系统(SoC)、现场可编程门阵列(FPGA)或专用集成电路(ASIC)或者这些器件的组合来实现。
主机设备410可以被配置为执行一个或多个虚拟机402。虚拟机是代表真实或假想计算系统的模拟计算环境。虚拟机可以类似于物理计算机，执行程序，包括操作系统。虚拟机通常彼此隔离操作，虚拟机中的进程无法影响在不同虚拟机中运行的进程。虚拟机可能涉及专门的硬件、软件、硬件和软件的组合。
示例系统400的虚拟机402可以正在执行一个或多个用户应用404a-b。用户应用404a-b包括例如高性能计算应用、其他计算密集型程序和普通用户应用，诸如例如文档编辑工具和网页浏览器。在大多数实现方式中，用户应用404a-b在“用户空间”中运行，即在它们彼此隔离、与操作系统(通常在“内核空间”中运行)隔离以及与底层硬件隔离的环境中运行。操作系统内核412可以具有更多访问特权，包括对用户应用404a-b的每个和底层硬件的访问。
用户应用404a-b可以通过标准库406和/或用户空间驱动器程序408与系统400硬件进行通信。标准库406提供用于执行常见操作的良好理解和商定的应用编程接口(API)。这些常见操作可以包括例如频繁执行的软件操作和对系统400硬件的访问。一类标准库是为内核旁路框架定义的。这些库包括例如OpenFabrics Alliance(OFA)开放式结构分布(OFED)动词库和LibFabric OpenFabrics接口(OFI)，这是实现OpenFabrics接口的开源Linux库。OFED最初是为了向InfiniBand动词提供API而开发的。InfiniBand动词是InfiniBand适配器的与任何硬件或操作系统无关的功能的抽象描述。OFED后来演变为支持非InfiniBand适配器。然而，OFED API的语义通常与许多应用的要求不兼容，并且已知难以使用，特别是在较大规模的情况下。相比之下，OFI提供了多种类型的语义，并且已知除了公开底层硬件功能外，还着重关注应用需求。
在一些实现方式中，标准库406可以与用户空间驱动器程序408进行通信，其中用户空间驱动器程序408被配置为提供对特定硬件设备的访问。在一些情况下，用户应用404b可能能够与用户空间驱动器程序408直接进行通信。在本示例中，用户空间驱动器程序408可以提供对网络适配器设备420的访问。用户空间驱动器程序408可以提供由标准库406提供的抽象与网络适配器设备420的特定硬件之间的接口。例如，用户空间驱动器程序408可以提供对包括发送队列和接收队列的通信堆栈的访问，在一些实现方式中，通信堆栈可以位于网络适配器设备420上。
在一些实现方式中，用户应用404a-b可以与操作系统内核412进行通信以进行配置操作。例如，用户应用404a-b可以向内核412注册虚拟地址和存储器区域。在一些实现方式中，内核412可以包括内核空间传输驱动器416。内核空间传输驱动器416可以被配置为执行控制操作，包括将队列对映射到用户应用404a-b、存储器注册和网络地址管理。
网络适配器设备420可以被配置为与网络430进行通信。网络适配器设备420可以具有可以被配置为执行发送和接收操作的管理模块422。管理模块422可以是例如固件或集成电路，诸如FPGA或ASIC。为了通过网络430发送消息，管理模块422可以被配置为使用用户应用的消息来生成数据包并且生成数据包报头。为了从网络430接收消息，管理模块422可以被配置为去除数据包报头并且向接收用户应用404a-b传送所接收到的消息。在一些情况下，接收到的消息可以包括发送方的地址或标识发送方的一些其他信息。
网络适配器设备420可以提供一个或多个传输服务，诸如例如不可靠数据报传输424和宽松可靠数据报传输426。网络适配器设备420可以提供这里未示出的其他传输服务。在一些实现方式中，宽松可靠数据报传输426可以被配置为提供可靠连接类型行为。在这些实现方式中，宽松可靠数据报上下文可以被分配给单个队列对，使得传输上下文专用于一个本地用户应用和一个远程用户应用之间的一个通信信道。
如上所述，使用宽松可靠数据报传输426的消息传递可以是“无连接的”，也就是说，可以不要求用户应用与目标应用建立明确连接。相反，连接管理可以由宽松可靠数据报传输426来处理。
另外，宽松可靠数据报传输426可以保证数据包的递送，数据包可能无序地到达它们的目的地。这可能意味着数据包可能需要重新排序，以便它们的顺序与源系统始发它们时的顺序相同。传统上，数据包排序和可靠性操作都是在网络适配器中或主机设备软件中一起处理的。例如，保证数据包递送的最可靠的传输服务类型通常依赖于网络不丢弃数据包。丢弃的数据包可能会导致数据包不按顺序到达(因为一个或多个数据包尚未到达)，在这种情况下，网络适配器设备可能会拒绝乱序数据包，或者可能需要重新发送整个数据包流。
另一种选择方案是网络适配器设备重新排序无序到达的数据包。然而，数据包重新排序通常是处理密集型操作。网络适配器设备的处理器通常便宜且功能较弱。因此，试图处理无序数据包的实现方式通常在主机设备软件中对数据包进行重新排序，以利用通常由主机设备提供的动力更强劲的处理器。在这些实现方式中，软件还试图确保可靠的数据包递送，包括诸如跟踪和重新请求丢失数据包之类的操作。然而，如上所述，处理器参与可能会对延时产生负面影响。因此，寻求可靠数据包递送的实现方式在网络适配器设备中已经实现了可靠性方面，且因此需要数据包的按序递送。
诸如图4的示例系统400之类的系统，使用宽松可靠数据报传输，可以将数据包重新排序和可靠性操作分开，在系统中的可以最有效处理这些操作的点来执行它们。例如，系统400可以被配置为使得网络适配器设备420处理数据包的可靠递送，这可能更适合于最小化在通过网络430传递数据包时固有的延时。此外，数据包重新排序可以由用户应用404a-b和/或驱动器程序408、416来处理，其中的每一个程序都可以在主机设备410的处理器上执行。
在描述如何可完成可靠的乱序数据包递送之前，首先描述连接建立。在使用宽松可靠数据报传输的系统中，传输服务可以促进通过计算集群提供的网络彼此进行通信的用户应用的“无连接”消息传递。
I.“无连接”消息传递
图5A-5B示出了用户应用504a可以获得地址句柄的过程500的示例，用户应用504a随后可以将该地址句柄用于将消息传送到另一应用。过程500可以类似于由可靠数据报和不可靠数据报传输使用的过程，因为用户应用504a没有建立明确的连接。过程500可以不同于可靠数据报和不可靠数据报使用的过程，因为传输服务(这里是宽松可靠数据报传输)可以负责建立和维护与其他系统的连接。此外，该连接维护对用户应用隐藏，给用户应用提供了地址句柄而不是明确的连接。用户应用504a可以使用相同的过程500来获得用户应用要与其进行通信的每个目的地的地址句柄。图5A示出了过程500的当目的地尚未被在主机设备502上执行的任何过程预先注册时的一部分。图5B示出了目的地已被预先注册的情况。
在一些实现方式中，用户应用504a可以不使用地址句柄来通过网络发送消息。例如，用户应用504a可以使用目的地地址或一些其他目的地信息来传送消息。在这些情况下，用户应用504a可以直接向网络适配器设备提供目的地信息，而不是提供地址句柄。在这些实现方式中，图5A-5B中所示出的过程500可能不由用户应用504a使用，至少对于一些目的地。参照图6A-6B对用户应用使用除地址句柄以外的目的地信息来传送消息的实例进行了进一步的描述。
如图5A所示，过程500可以涉及与网络适配器设备520进行通信的主机设备502。主机设备502可以是通用计算系统，包括诸如一个或多个处理器、存储器子系统、外围设备等这里未示出的部件。主机设备502可以正在执行一个或多个用户应用，包括所示的用户应用504a。这些用户应用可能在这里未示出的一个或多个虚拟机中运行。主机设备502也可以执行一个或多个驱动器程序，包括所示的驱动器程序508。驱动器程序508可以在操作系统内核内执行。在内核内运行可以为驱动器程序提供更多的访问特权，包括对物理存储器和主机设备的硬件的访问。另选地或另外地，驱动器程序508可以在用户空间中执行，在用户空间，它可以具有更少的访问特权，并且可以更不安全。
网络适配器设备520可以是用于与网络进行通信的通用网络接口卡。另选地或另外地，网络适配器设备520可以是用于与特定类型的网络(例如，InfiniBand网络)进行通信的专用卡。网络适配器设备520可以包括管理模块522。管理模块522可以是例如固件或集成电路，诸如FPGA或ASIC。网络适配器设备520还可以包括用于存储与网络适配器设备520的操作有关的数据的存储器。另选地或另外地，存储器可以被集成到管理模块522中。在一些实现方式中，网络适配器设备520可以包括RDMA型功能(即，内核旁路功能)。在一些实现方式中，网络适配器设备520是外围部件互连(PCI)类型设备，并且通过PCI总线与主机设备520进行通信。在一些实现方式中，下面所描述的网络适配器设备420的操作可以以集成电路器件或集成电路器件集合来实现。例如，在各种实现方式中，网络适配器设备的操作可以以SoC、FPGA或ASIC或这些器件的组合来实现。
为了获得与目的地节点进行通信的地址句柄，用户应用504a首先确定目的地的地址。在大多数情况下，目的地是在连接到网络的另一个系统上执行的应用。目的地的地址可以是通用地址，例如网络上的系统的互联网协议(IP)或媒体访问控制(MAC)地址。另选地或另外地，目的地地址可以是特定的，诸如标识特定目标应用的地址。另选地或另外地，目的地地址可以介于一般和特定之间。
用户应用504a可以使用标准机制来获得目的地地址。例如，在一些实现方式中，用户应用504a可以从用户提供的输入和/或通过标准地址解析机制(诸如由域名系统(DNS)服务器所提供的)获得目的地地址。在一些实现方式中，用户应用504a可以通过与目标应用交换消息来获得目的地地址。例如，用户应用504a可以使用在网络上运行的标准套接字系统，并将其自己的地址与目标应用的地址进行交换。作为另一示例，用户应用504a可以使用指定的或专用的边带网络来交换此信息。在一些实现方式中，用户应用504a解析目的地地址的方式对于特定应用是特定的。
在确定目的地地址后，用户应用504a可以向驱动器程序508提交对地址句柄的请求550。该请求550可以至少包括目的地地址。在一些实现方式中，驱动器程序508是内核驱动器程序，其可以被配置为集中管理在主机设备502上执行的所有进程的地址句柄。在其他实现方式中，驱动器程序508是用户空间设备驱动器，具有通常可用于设备驱动器的标准访问特权。在一些实现方式中，请求550可以首先转到设备驱动器，且然后转到内核驱动器。在其他实现方式中，请求550可以直接从用户应用504a进入内核驱动器。
在步骤552，驱动器程序508可以确定地址句柄请求550中的目的地地址是否是“新的”；即，驱动器程序508是否先前已经注册了该目的地地址。驱动器程序508可以维护当前由在主机设备502上执行的进程使用的目的地地址的列表或目录(通常称为“地址映射”514)。在一些实现方式中，地址映射514可以由网络适配器设备520维护。一旦接收到地址句柄请求550，驱动器程序508就可以检查地址映射514以查看它是否包含目的地地址。在图5A的示例中，驱动器程序508没有在地址映射514中找到目的地地址，且因此确定目的地地址是新的。
在确定目的地地址是新的之后，驱动器程序508可以向在网络适配器设备520上执行的管理模块522发出请求554以获得新的地址句柄。此新的地址句柄请求554可以包括目的地地址。管理模块522可以运行对目的地地址的检查，诸如例如验证用户应用504a(或者用户应用504a正在其中执行的虚拟机)被允许与可以在其中找到目标应用的系统进行通信。然后，管理模块522可以将目的地地址存储在网络适配器设备520上的存储器528中。
在一些实现方式中，管理模块522可以将网络地址映射对象556存储在存储器528中。网络地址映射对象是可以存储与目的地地址有关的信息的数据结构的实例。例如，网络地址映射对象556可以包括目的地地址。在一些实现方式中，网络地址映射对象556可以包括由管理模块522生成的预先生成的数据包报头。预先生成的数据包报头可以包括源地址和目的地地址，和/或数据包穿过网络到目的地系统可所需的其他路由信息，和/或其他报头信息。预先生成的数据包报头可以被存储以便稍后用于快速形成数据包。在一些实现方式中，网络地址映射对象可以包括预先生成的内部和外部报头。当将根据一个协议生成的数据包封装在用于另一协议的报头中时，可以使用内部和外部报头。封装可以发生在网络隧道中，即，在为一种网络协议配置的网络上，传送根据不同协议配置的数据包。通过封装数据包并提供外部报头，不需要修改内部报头以适应外部网络协议。预先生成的内部和外部标头可以与网络地址映射对象一起存储。
因为目的地地址是新的，所以管理模块可以另外地或另选地配置传输上下文524。传输上下文524跟与目的地地址相关联的系统建立连接并维护该连接。可以为连接到网络的每个可能的目的地系统配置传输上下文，但是一般而言，传输上下文直到需要时才配置。在大多数实现方式中，传输上下文描述了两个系统之间的连接，而不是两个应用之间或应用与系统之间的连接。配置传输上下文524可以包括与目的地系统建立连接。例如，可以通过网络适配器设备520与目的地系统之间的消息交换来建立该连接。一旦被配置，传输上下文524可以监测并维护连接的状态。连接的维护可以尤其包括存储或以其他方式跟踪与目的地系统相关联的网络地址映射对象。如上所述，目的地地址可以比目的地系统的地址更具体，且因此，对于给定的传输上下文，可以存在一个以上的网络地址映射对象。可以给传输上下文524指派传输服务类型，诸如不可靠数据报或宽松可靠数据报。下面进一步详细描述传输上下文。
已经存储了目的地地址或网络地址映射对象556和/或已经配置了传输上下文524之后，管理模块522可接着将地址句柄558返回给驱动器程序508。地址句柄558可以是引用存储在网络适配器设备520的存储器528中的目的地地址或网络地址映射对象556的引用、指针和/或索引。驱动器程序508可以将地址句柄558存储在其地址映射514中，其中可以通过目的地地址找到它。在一些实现方式中，网络适配器设备520可以管理地址映射514，在这种情况下，管理模块522可以将地址句柄存储在地址映射514中。目的地地址现在可以被认为是“已注册的”，因为驱动器程序508已经知道它。驱动器程序508可接着将地址句柄558发送到用户应用504a。在大多数情况下，用户应用504a可以存储或以其他方式维护地址句柄558以供以后使用。
如前所述，图5A示出了用户应用504a已经请求了尚未向驱动器程序508注册的目的地的地址句柄的情况。图5B示出了用户应用504b请求已经向驱动器程序508注册的目的地地址的地址句柄的示例。如图5A所示，在图5B中，用户应用504b可首先确定用户应用504b将与其进行通信的目的地的目的地地址。用户应用504b可以是与图5A所示的相同的用户应用504a，或者可以是在同一主机设备502上执行的不同用户应用。
返回到图5B，在确定目的地地址后，用户应用504b可以向驱动器程序508提交对地址句柄的请求550。在该示例中，驱动器程序508在步骤552可以检查与请求550一起发送的目的地地址，并且可以确定可以在地址映射514中找到目的地地址。这意味着目的地地址已经向驱动器程序508注册。这也可能意味着不需要访问网络适配器设备520以提供地址句柄，如图5A所示的情况那样。在一些实现方式中，地址映射514由网络适配器设备520维护，在这种情况下，驱动器程序508可以请求网络地址映射520查找目的地地址。在这些实现方式中，网络适配器设备520可以确定目的地地址已被预先注册，并向驱动器程序508提供地址句柄558。
在图5B中，在确定目的地地址被预先注册后，驱动器程序508可以使用存储在地址映射514中的信息来提供地址句柄558。例如，地址映射514可以存储引用、指针和/或索引，并且驱动器程序508可以生成引用所存储的引用、指针或索引的新的地址句柄558。地址句柄558可被返回给用户应用504b，该用户应用可存储地址句柄558供以后使用。
图6A-6B示出了过程600的示例，通过该过程，用户应用604可以使用根据图5A-5B获得的地址句柄658来传送消息。在一些实现方式中，用户应用604可以不使用地址句柄658，而是可以使用其他目的地信息来传送消息。下面将对这些实现方式进一步进行详细讨论。
在图6A-6B中，过程600可以涉及主机设备602和网络适配器设备620。主机设备602可以是通用计算系统，包括诸如一个或多个处理器、存储器子系统、外围设备等这里未示出的部件。主机设备602可以正在执行一个或多个用户应用，包括所示的用户应用604。网络适配器设备620可以是用于与网络630进行通信的通用网络接口卡，和/或用于与特定类型的网络进行通信的专用卡。在一些实现方式中，网络适配器设备的操作可以以集成电路器件和/或集成电路器件的组合来实现。网络适配器设备620还可以包括存储器628，但是在一些实现方式中，存储器628被并入安装在网络适配器设备620上的固件(未示出)中。在一些实现方式中，网络适配器设备620不具有存储器，或者仅具有小的存储器，并且可以使用主机设备602上的存储器来存储信息。
在图6A中，用户应用604可以具有它打算发送到在网络上的不同系统上运行的另一应用的消息660。在此示例中，用户应用604先前已经获取了与目标应用相关联的地址句柄658。为了将消息660传送到目标应用，用户应用604可以将消息660连同地址句柄658一起发送到网络适配器设备620。在一些实现方式中，消息660可以在被传送到网络适配器设备620之前首先被传送到设备驱动器。
一旦接收到消息660，网络适配器设备620可以使用地址句柄来确定消息660的传输上下文624。传输上下文624通常维护与要接收消息660的系统的连接。维护连接可以包括例如传送数据包、跟踪未完成数据包的状态以及如下面将更详细解释的那样，建立和取消跨越网络到达目标系统的路径。
传输上下文624还可以跟踪存储在存储器628中的与目的地相关的信息，例如与当前地址句柄相关联的网络地址映射对象656。网络地址映射对象656可以提供用于为消息660生成数据包的信息。例如，网络地址映射对象656可以包括目的地地址(例如，目标系统的IP地址或MAC地址或者目标应用的地址)。另选地或另外地，网络地址映射对象656可以包括预先生成的报头，其包括数据包到达目标系统所需的寻址和/或路由信息。在一些实现方式中，网络适配器设备620可以不具有存储器，或者可以使用主机设备602上的存储器来存储诸如与目的地相关的信息之类的数据。在这些实现方式中，当传输上下文624查找网络地址映射对象656时，它可以向主机设备602发出从主机设备602的存储器读取网络地址映射对象656的请求。
通过使用存储在存储器656中的与目的地相关的信息，例如网络地址映射对象656，网络适配器设备可以生成一个或多个数据包662，其中包含消息660的全部或一部分。在网络地址映射对象656提供预先生成的数据包报头的实现方式中，数据包662可以通过将预先生成的数据包报头前置到有效载荷来生成，其中有效载荷包括消息660的数据。在生成了一个或多个数据包662之后，网络适配器620可以随后通过网络630传送一个或多个数据包。
在某些情况下，预期目标应用将对消息660作出响应。例如，当消息660是请求目标应用具有的一些信息的读取事务时，可以预期目标应用以被读取的数据作出响应。作为另一示例，消息660可能是指示目标应用执行一个或多个操作并返回这些操作的结果的命令。
图6B示出了在对根据图6A传送的消息660的回复中发送的响应664的接收示例。在图6B中，响应664可以由网络适配器设备620在网络630上以数据包的形式接收。网络适配器设备620可以接收许多响应，所述响应是对由主机设备602上执行的用户应用传送的消息的回复而发送的。因此，网络适配器设备620和/或主机设备602可以标识哪个用户应用应该接收给定响应664。数据包报头可以包括标识响应664的源(例如，远程服务器和/或远程应用的地址)和响应的目的地(例如，本地服务器和/或用户应用604)的信息。数据包有效载荷可以包括响应664数据。
传输上下文624可以接收响应664，可以为发送响应664的系统配置该传输上下文。通过使用传输上下文624，网络适配器设备可以从通过网络630接收到的数据包中解压缩响应664的数据。在一些情况下，网络适配器设备620可以汇编来自通过网络630接收到的多个响应数据包的响应消息。网络适配器设备620还可以从响应664中提取源地址，即，发送响应664的系统和/或进程的地址。在此示例中，源地址与用于传送图6A中的消息660的目的地地址相同。在一些实现方式中，响应664可以包括标识响应的源和/或响应664对应的消息660的一些其他信息。
返回到图6B，网络适配器设备620可以使用源地址(或标识响应664的其他信息)来在存储器628中定位对应于发送方地址的网络地址映射对象656。网络地址映射对象656可以提供用于发送消息660的地址句柄。该地址句柄可以标识发送消息660的用户应用604。地址句柄可以与响应664一起提供给主机设备，并且主机设备602可以将响应消息666引导(例如，使用驱动器程序)到用户应用604。另选地，在一些实现方式中，响应消息666可以与来自网络的响应664附带的源地址而不是地址句柄一起被提供给主机设备602。然后，主机设备可以使用源地址来将响应消息666引导到用户应用604。
用户应用604可以使用地址句柄来确定响应消息666来自何处，和/或响应消息666正在响应于哪个消息。如前所述，地址句柄可以与当传送原始消息660时使用的地址句柄相同，在这种情况下，用户应用604可能能够使用简单的查找机制来确定响应消息666是响应于哪个消息。在一些情况下，用户应用604可以对响应消息666作出反应，诸如例如重新传送消息660的全部或一部分，或发起与目的地的新的通信。
如上所述，在一些实现方式中，用户应用604可以使用除地址句柄之外的地址信息来传送消息。在这些实现方式中，用户应用604可以使用与图6A-6B所示的过程600类似的过程。例如，在图6A中，用户应用604可以具有用于发送到在网络上的不同系统上运行的另一应用的消息。在此示例中，用户应用604没有目的地应用的地址句柄，但可以具有它将用来获得地址句柄的目的地信息。例如，用户应用604可以具有(例如)IP地址和/或MAC地址的形式的目的地系统的网络地址。作为另一示例，用户应用可以具有流标识符。流描述了在一个系统和另一个系统之间传输的通常彼此相关的数据包的流。流标识符可以标识属于同一流的数据包。流标识符可以呈现可以包括在数据包报头中的值的形式。另选地或另外地，可以通过诸如源系统的地址、目的地系统的地址、发送数据包的源系统处的端口和/或接收数据包的目的地系统处的端口之类的网络地址来标识流。在某些情况下，流标识符是使用源和目的地和/或端口号作为输入的数学运算的结果。
因此，用户应用604可以使用目的地信息来发送消息660。用户应用604可以将消息660连同目的地信息一起发送到网络适配器设备620。网络适配器设备620可以使用目的地信息来确定适当的传输上下文624。例如，网络适配器设备620可以被配置为使用网络地址或流标识符来查找传输上下文624。一旦网络适配器设备620确定了传输上下文624，网络适配器设备620就可以使用传输上下文624来生成数据包，并将数据包传送到网络630。
被配置为使用如图5A-5B和图6A-6B所示的无连接消息传送过程500、600的计算集群可以更有效地管理网络地址，可以具有较低的存储器需求，并可以更具可扩展性。
与无连接消息传送一起提供的地址句柄可以简化主机设备中的地址管理。在不使用无连接消息传送方法的实现方式中，地址管理负担的大部分可能放在主机设备上执行的软件上。例如，用户应用或驱动器程序可能需要生成数据包报头，因此需要跟踪源和目的地信息。作为另一示例，当接收到响应时，可能需要驱动器程序或用户应用读取整个数据包报头以标识响应的源和目的地。相反，在使用无连接消息传送方法的实现方式中，一旦目的地地址已被注册，用户应用和驱动器程序只需使用地址句柄来引用目的地。此外，当主机设备602接收到响应时，其可以通过其地址句柄来快速标识。
当在一个系统上执行的许多进程正与在不同系统上执行的许多进程进行通信时，地址句柄还可以减少所需的存储器量。对于用户应用想要与其进行通信的每个目的地，用户应用可以获得并维护单独的地址句柄。但是，对于每个目的地，对于可能正在与目的地进行通信的所有用户应用，只需要创建并存储一个网络地址映射对象。因此，可最小化网络适配器上的存储器使用。驱动器程序的存储器需求也可以最小化，因为在一些实现方式中，驱动器程序可以维护地址映射，地址映射可以由在主机设备上执行的所有进程用来获得地址句柄。另外，一旦目的地地址已向驱动器程序注册，为其他用户应用提供地址句柄以便与相同目的地进行通信可以快速完成，而不需要与网络适配器设备进行通信。
无连接消息传送还可以提供具有更大可扩展性的计算集群。如上所述，连接型传输服务类型可能出现的问题之一是，随着尝试在网络中进行通信的进程数量增大，连接数量也随之增大。相比之下，在使用无连接消息传送方法的实现方式中，用户应用不需要建立连接，而是获得地址句柄。尽管网络适配器设备确实与其他系统建立连接，但在大多数情况下，在网络上的任何两个系统之间只建立一个连接。然后，来自一个系统的所有流量都可以使用单个连接到达另一个系统。因此，连接的数量不太可能随着进程数量的增加而增加，而仅会由于向集群添加更多节点而增加。
II.可靠的无序数据包递送
如上所述，宽松可靠数据报传输服务可以促进“无连接”消息传送。本节详细讨论使用宽松可靠数据报传输来对消息传送进行管理，包括消息可如何被寻址、如何管理与网络的通信以及提供可靠递送的机制。还提供了有关数据包如何以及为什么可能无序到达的讨论。
图7A-7B示出了可以为包括宽松可靠数据报传输服务的系统实现的通信堆栈700的示例。图7A示出了通信堆栈的传送侧的示例，而图7B示出了通信堆栈的接收侧的示例。在这些示例中，可能使用例如参考图5A-5B描述的过程500预先建立了连接。例如，在图7A-7B中，可能已经配置了一个或多个传送侧传输上下文716a-b和接收侧传输上下文768a-b，其中(根据该示例)每个传送侧传输上下文716a-b都管理与对应的接收侧传输上下文768a-b的连接。尽管图7A-7B的示例示出了一个系统作为传送系统，而另一个系统作为接收系统，但是标签“传送”和“接收”仅仅是为了方便而指派的。还应该理解的是，这里被称为接收侧系统的系统也可以用作传送系统，其中这里被称为传送系统的系统充当接收系统。
在图7A的示例中，示出了示例通信堆栈700的传送侧。在该示例中，通信堆栈的传送侧包括通过网络730与一个或多个目的地系统718a-b进行通信的两个用户应用704a-b、多个队列对710a-d以及一个或多个传送侧传输上下文716a-b。为了简单起见，图7A所示的示例描述了两个用户应用704a-b，并且应该理解，所示的虚拟机702和/或托管虚拟机702的系统可以有更多或更少的用户应用，每个用户应用都被配置为使用类似的通信堆栈。
在此示例中，用户应用704a-b可以在为主机设备配置的虚拟机702内执行。每个用户应用704a-b都可以使用诸如OFED型动词库之类的标准库706a-b来与网络730进行通信。在一些实现方式中，每个用户应用704a-b都可能在使用不同的标准库706a-b。标准库706a-b可以提供一组公共的网络命令，诸如“post send”用于发送消息，“post receive”用于接收消息，以及“poll”用于检查完成队列的内容。标准库706a-b还可以提供到驱动器程序708a-b的接口。驱动器程序708a-b可以提供用于与虚拟机702操作系统内核和/或系统的硬件(包括网络适配器设备)进行交互的命令。驱动器程序708a-b可以是内核驱动器，在这种情况下，驱动器程序708a-b可以具有较高的访问特权。另选地，驱动器程序708a可以是用户空间驱动器，并具有较低的访问特权。在一些实现方式中，每个用户应用704a-b都可能在使用不同的驱动器程序708a-b。在其他实现方式中，两个用户应用704a-b都可能在使用相同的驱动器程序708a-b。在一些实现方式中，用户应用704a-b可以直接与驱动器程序708a-b进行通信，而不是通过标准库706a-b。
为了与网络730进行通信，可以给每个用户应用704a-b分配一个或多个“通信端点”。通信端点描述与用户应用704a-b的逻辑关联，并且可以用于在由用户应用704a-b发送的消息中标识用户应用704a-b。也就是说，通信端点的标识符可以至少部分地用作消息的发送方地址。通信端点可以用不同的方式来实现。例如，在一些实现方式中，在示例通信堆栈700中，通信端点每个被映射到队列对710a-d。在这些实现方式中，通信端点可以由队列对标识符来标识，队列对标识符通常是数字。此外，在这些实现方式中，队列对标识符可以至少部分地用作由用户应用704a-b发送的消息的发送方地址。分配给用户应用704a-b的通信端点可以由驱动器程序708a-b维护。在大多数情况下，通信端点不会在用户应用之间共享。
可以给虚拟机702本身分配一个或多个虚拟接口709a-b，用于与网络730进行通信。例如，这些虚拟接口709a-b可以通过虚拟机702的操作系统或通过主机设备的操作系统分配给虚拟机702。可以给每个虚拟接口709a-b分配IP地址。为了与网络730进行通信，用户应用704a-b可以使用虚拟接口709a-b中的一个或多个。因此，由用户应用704a-b使用例如两个可用虚拟接口709a之一发送的消息可以以该虚拟接口的IP地址作为该消息的发送方地址。因此，在一些实现方式中，用户应用704a-b可以由该虚拟接口709a的IP地址来标识。
当用户应用704a-b已经向虚拟机702操作系统内核注册了它们自己时，和/或当用户应用704a-b请求对队列对710a-d的分配时，和/或当用户应用704a-b首次注册以与目的地系统718a-b进行通信时，可能已经将虚拟接口709a-b分配给用户应用704a-b。在一些实现方式中，一个以上用户应用704a-b可以使用给定虚拟接口709a-b。例如，在图7A的示例中，第一用户应用704a和第二用户应用704b两者都已被分配给第二虚拟接口709b。
在这些和其他实现方式中，用户应用704a-b可能在使用通信端点和一个或多个虚拟接口709a-b两者来与网络730进行通信。在这些实现方式中，可以通过通信端点的标识符(例如，队列对编号)和虚拟接口709a-b IP地址的组合来标识用户应用704a-b。此外，虚拟接口709a-b的IP地址和通信端点标识符的组合可以用作由用户应用704a-b发送的消息的发送方地址。
如上所述，在一些实现方式中(包括使用宽松可靠数据报传输的那些)，每个通信端点可以被映射到单个队列对710a-d。队列对通常包括发送队列712，用于传送到网络的消息，和接收队列714，用于接收从网络730进入的消息。在一些实现方式中，分配给用户应用704a-b的每个通信端点都可以被分配给不同的队列对710a-d。在其他实现方式中，队列对可以在通信端点之间共享，但是在这些实现方式中，可能需要将限制和/或附加参数添加到配置中，以确保每个通信端点可以被唯一地寻址和标识。
在许多情况下，队列对710a-d可以在网络适配器设备上以硬件实现，但是在一些情况下，队列对710a-d可以在网络适配器设备上以软件实现，和/或可以在主机设备上以软件实现和/或可以存在于主机设备的操作系统和/或管理程序中、创建和管理虚拟机的硬件和/或软件层中。在一些实现方式中，当用户应用704a-b、驱动器程序708a-b请求队列对710a-d时，或者用户应用704a-b通过驱动器程序708a-b发出请求时，网络适配器设备(或操作系统或管理程序)可以分配队列对710a-d。在一些实现方式中，可以为通信管理消息诸如用于建立或取消连接的消息以及在用户应用之间传递以交换它们各自的地址的消息预留一个队列对(例如，队列对编号0或1)。
如上所述，在一些实现方式中，队列对710a-d(例如，第一队列对710a)可以被分配给与特定用户应用704a-b(例如，第一用户应用704a)相关联的通信端点。然而，队列对710a不需要与特定目的地相关联，且因此，可以从用户应用704a接收发往网络上的不同目的地的消息。
在一些实现方式中，可以针对每个虚拟接口709a-b跟踪队列对710a-d分配。例如，这样做可以促进虚拟机702的迁移。迁移是将虚拟机702移动到不同的物理系统的过程，无论是首先关闭还是不关闭虚拟机702。在虚拟机702迁移之后，可以将通信端点分配给新的队列对，但是，仍然在传播中的数据包仍然可以到达这些通信端点，因为旧的队列对标识符已经被维护。
如上所述，用户应用704a-b可以由分配给用户应用704a-b的通信端点的身份、由用户应用704a-b使用的虚拟接口709a-b的IP、或者由通信端点的身份和虚拟接口709a-b的IP地址两者来标识。目标用户应用(例如，图7B中所示的用户应用754)可以以类似的方式来标识。
现在转到图7A中所示的具体示例，在该示例中，第一用户应用704a已经被配置有至少三个通信端点，如由三个图示的队列对710a-c所指示。此外，第一用户应用704a将一个通信端点与一个可用虚拟接口709a相关联(如由指出与第一队列对710a的通信的实线箭头720a所指出的)，并且还进一步将两个通信端点与第二可用虚拟接口709b相关联(如指出与第二710b和第三710c队列对的通信的折线箭头720b所指出的)。作为另一示例，第二用户应用704b已经被配置有一个通信端点，如到第四队列对710d的虚线箭头726所指出的。此外，第二用户应用704b已将该通信端点与第二虚拟接口709b相关联。
在该示例中，第一用户应用704a可以具有要传送到网络730上的目的地系统718a的消息。通过使用其第一通信端点，第一用户应用704a可以将消息连同标识该消息的目的地系统718a的信息(例如，地址句柄)一起放置在与通信端点相关联的第一队列对710a的发送队列712中。将消息放置在发送队列712中通常不需要主机设备处理器的帮助。另外，将消息放置在发送队列712中通常也不需要用户应用704a来仲裁对队列对710a的访问，因为在大多数情况下，用户应用704a独占使用队列对710a。
在一些实现方式中，网络适配器设备管理队列对710a-d。网络适配器设备可以确保以及时的方式来为队列对710a-d提供服务。另选地或另外地，网络适配器设备可以根据分配给每个队列对710a-d的优先级、流量类型和/或服务级别协议来为队列对710a-d提供服务。
继续图7A的示例，当为第一发送队列712提供服务时，网络适配器设备可以移除并处理(例如，使用固件或集成电路)由用户应用704a放置在发送队列712中的消息。网络适配器可以检查与消息一起被推送到发送队列712中的目的地信息，并且标识适当的传输上下文716a-b。如前所述，传输上下文716a-b中的每个都管理与网络上的目的地系统718a-b的连接。在大多数实现方式中，传输上下文716a描述了一个源系统和一个目的地系统之间的连接，并且不与特定的用户应用或队列对相关联。因此，来自不同用户应用的和/或通过不同通信端点发送的消息可以映射到同一传输上下文716a。相反，可以将来自一个用户应用704a的消息引导到不同的传输上下文716a-b。例如，在所示示例中，来自映射到第一用户应用740a的第一队列对710a的消息可以被引导到第一传输上下文716a(如实线箭头722a所指示)和第二传输上下文716b(如虚线箭头722b所指示)。类似地，来自映射到第二用户应用704b的第四队列对710d的消息也可以被引导到两个传输上下文716a-b(如虚线箭头728所指示)。队列对710a-d中的每一个还可以将消息引导至在此未示出的附加传输上下文。特定消息的传输上下文716a-b可以由随消息提供的目的地信息来标识。
在一些实现方式中，传输上下文716a-b(例如，第二传输上下文716b)可以被配置为提供类似于可靠连接传输的传输服务。在这些实现方式中，可以将传输上下文716b分配给单个队列对(例如，第二队列对710b)。在接收侧，对应的接收侧传输上下文768b也将被分配给单个队列对(例如第二队列对760b)。将传输上下文716b、768b中的每一个分配给单个队列对可以导致发送用户应用704a和接收用户应用754具有彼此排斥的通信信道，如同传输上下文716b、768b正提供可靠连接传输的情况。事实上，传输上下文716b、768b可以提供宽松可靠数据报传输，其可以像可靠连接一样保证数据包递送。
继续图7A的示例，在该示例中，第一传输上下文716a已被标识为从第一发送队列712弹出的消息的传输上下文。在一些实现方式中，传输上下文716a可以提供预先生成的数据包报头。预先生成的数据包报头可以包括预定的源地址和目的地地址，和/或将数据包从传送侧路由到接收侧所需的其他信息。在一些实现方式中，对于数据包将通过隧道传输的情况，传输上下文716a可以提供预先生成的内部和外部报头。
如前所述，传输上下文716a-b可以管理与网络730上的对应目的地系统718a-b的连接。通常，例如在计算集群中，可能存在从传送侧系统到接收侧系统可用的多条路径724a-b。在这种情况下，传输上下文716a-b可以管理网络730上的多条可用路径724a-b。对路径724a-b的管理可以包括建立和取消路径724a-b，其中当路径724a-b过于拥塞时或者如果沿该路径存在链路故障时，这些路径可能被取消。另外，传输上下文716a-b还将尝试沿所有可用路径724a-b传送数据包。这样做可能会改善整个网络的负载平衡和/或协助维护有关拥塞或故障路径的最新信息。例如，当数据包未到达目的地系统718a或需要很长时间才能到达目的地系统718a时，可能检测到发生拥塞和故障的路径。参考图8更详细地描述了对网络上多条路径724a-b的管理。
继续图7A所示的示例，在该示例中，第一传输上下文716a可以将来自第一用户应用704a的消息通过网络730上的多条路径724a传送到目的地系统718a。在一些实现方式中，网络适配器设备可以使用传输上下文716a来生成并发送包括该消息的一个数据包。在一些实现方式中，网络适配器设备可以生成多个数据包，每个数据包都包含消息的一部分。这些多个数据包可以各自都采用相同的路径或不同的路径来到达目的地系统718a。在一些实现方式中，并且如下面更详细讨论的，传输上下文716a可以监测每个数据包的状态，以确保每个数据包都被递送到目的地系统718a。
图7B示出了通信堆栈700的接收侧。如在传送侧，接收侧包括与网络730上的对应源系统766a-b进行通信的用户应用754、一个或多个队列对760a-b以及一个或多个接收侧传输上下文772a-b。在图7B所示的示例中，所示的用户应用754已经被配置为至少(并且不一定排他地)与图7A的示例传送侧中所示的第一用户应用704a进行通信。因此，在图7B所示的示例中，第一源系统766a对应于图7A所示的传送侧系统。而且，在图7B中，传输上下文766a已经被配置为与源系统766a进行通信，并且可以管理与源系统766a处的传输上下文716a的连接。类似地，第二源系统766b也对应于图7A所示的传送侧系统，但被配置为连接到不同的传送侧传输上下文716b。
图7B还示出了用户应用754如何可以配置用于发送和接收消息的缓冲区782。虽然没有示出，但是图7A的传送侧用户应用704a还可以配置缓冲区，如果需要的话。在图7B中，用户应用754通常可以但不总是在虚拟机752内执行。在一些实现方式中，虚拟机752可以提供虚拟存储器780，其中用户应用754可以为缓冲区782分配空间。在这些实现方式中，缓冲区782的地址可以是虚拟的，并驻留在虚拟机752的虚拟地址空间中。在许多情况下，虚拟地址可以向操作系统内核(虚拟机操作系统或主机设备操作系统)以及提供对网络730的访问的网络适配器进行注册。向内核注册可以固定虚拟地址到客体物理地址的映射，这可以防止包括缓冲区782的虚拟页面被换出，并导致某种效率低下状况。可以通过在虚拟机752内或在主机系统上执行的内核驱动器来完成向内核的注册。内核驱动器可能会将注册信息传递给网络适配器设备，该设备可能会返回存储器注册密钥。存储器注册密钥随后可以由用户应用754连同缓冲区782地址以及由用户应用发送的消息一起传递给网络适配器设备。这一获得注册密钥的过程可以向网络适配器设备提供直接读写缓冲区782的访问特权，而不需要来自主机设备处理器的帮助。
在一些实现方式中，用户应用754可以在主机设备的物理存储器中分配缓冲区782，代替在虚拟存储器中分配，或作为在虚拟存储器中分配的补充。在这些实现方式中，用户应用754可具有特殊的可信状态，因为给用户应用提供对物理存储器的访问比将用户应用754限制为仅能访问虚拟存储器的安全性稍低。
在一些实现方式中，用户应用754可以使用诸如OFED型动词库之类的标准库756来与网络730进行通信。标准库756可以提供到驱动器程序708a的接口。驱动器程序708a可以提供用于与虚拟机752操作系统内核和/或系统的硬件(包括网络适配器设备)进行交互的命令。在一些实现方式中，用户应用754可以直接与驱动器程序758进行通信，而不是通过标准库756。
为了与网络730进行通信，在此示例中，可以给用户应用754分配一个或多个通信端点。在一些实现方式中，可以将每个通信端点映射到队列对760a-c。在这些实现方式中，通信端点可以由队列对编号来标识。在这些实现方式中，队列对编号可以至少部分地用作用户应用754的地址。
可以给虚拟机752进一步分配一个或多个虚拟接口759a-b，用于与网络730进行通信。可以给每个虚拟接口759a-b分配IP地址。在一些实现方式中，用户应用754可以使用虚拟接口759a-b中的一个或多个来与网络730进行通信。在这些实现方式中，用户应用754可以使用虚拟接口759a的IP地址来向网络730上的其他系统和进程标识自己。在一些实现方式中，用户应用754可以使用分配给虚拟接口759a的IP地址和通信端点标识符(例如，队列对编号)来标识自身。
继续参考图7A讨论的示例，在该示例中，传送侧用户应用704a通过将消息连同标识消息的目的地系统718a的信息一起放置在队列对710a的发送队列712中来传送消息。网络适配器设备随后可以为发送队列712提供服务，并使用目的地信息来确定用于发送消息的传输上下文716a。然后，网络适配器设备可以使用传输上下文716a生成用于传送消息的一个或多个数据包。然后，在传输上下文716a的帮助下，网络适配器设备可以通过网络上的多个连接724a传送一个或多个数据包并传送到目的地系统718a。
此示例在图7B中继续，传送系统被表示为网络上的第一源系统766a。来自源系统766a的一个或多个数据包由接收侧系统通过网络730上的多条路径724a接收。在一些实现方式中，数据包由网络适配器设备接收。在这些实现方式中，网络适配器设备可以确定哪个传输上下文768a-b对应于数据包的源系统766a。网络适配器设备可以使用与数据包一起提供的源地址和/或目的地地址来定位适当的传输上下文(其在本示例中是第一传输上下文768a)。在一些实现方式中，网络适配器设备可以具有包含源地址的网络地址映射，并且网络适配器设备可以使用源地址对网络地址映射进行索引，以找到传输上下文768a。
在一些实现方式中，传输上下文768a可以被配置为提供类似于可靠连接传输的传输服务。在这些实现方式中，网络适配器设备可以具有被配置为可靠连接传输的传输上下文768a-b的表。网络适配器设备可以进一步使用目的地队列对编号来索引该表，并且该表可以指示适当的传输上下文768a。在一些情况下，网络适配器还可以使用包括在输入数据包中的上下文标识符来定位正确的传输上下文768a。
如下面将更详细讨论的，传输上下文768a可以监测每个数据包的状态，以确保接收到由源系统766a系统传送的每个数据包。传输上下文768a(特别是宽松可靠数据报传输服务)可能不会跟踪在接收系统处是否按顺序接收到数据包，并且通常只关心确保所有数据包到达。在一些实现方式中，传输上下文768a可以处理传入数据包，并且例如移除网络报头。传输上下文768a还可以检测何时接收到重复数据包776。当数据包在网络730内丢弃或似乎丢弃时，可以接收重复数据包776。当数据包在网络730中似乎已经被丢弃时，传输上下文768a可以请求源系统766a重新发送数据包。在某些情况下，所请求的数据包可能会被接收系统多次接收，例如当数据包没有被实际丢弃，而只是花了特别长的时间才到达，且因此只是似乎被丢弃时。当发生这种情况时，传输上下文768a可以丢弃在接收到第一副本之后接收到的任何附加副本776。
网络适配器设备可以从传输上下文768a接收(例如，使用固件或集成电路)数据包，并且确定将接收数据包的队列对760a-c。网络适配器可以使用目的地信息(例如传入数据包所包括的目的地地址)来确定适当的队列对760a。例如，目的地地址可以至少部分包括队列对编号。如实线箭头772a所指示，网络适配器设备可以将一个或多个数据包放入所确定的队列对760a的接收队列764中。队列对760a-c可以与特定通信端点相关联，而不一定与特定传输上下文768a-c相关联。因此，特定队列对760a可以从不同传输上下文接收数据包，如折线箭头772b所指示。
网络适配器可以从接收队列764将数据包传递到主机存储器780中的缓冲区782。例如，网络适配器可以执行通常不需要主机设备处理器的DMA操作来向主机存储器780写入。在一些实现方式中，虚拟接口759a的IP地址和/或通信端点的身份(其中任何一个或两个可作为数据包的目的地地址来提供)可协助将数据包传递到正确的虚拟机752。在一些实现方式中，驱动器程序758可以协助将数据包传递到缓冲区782。在一些实现方式中，标准库可以提供这种协助。
用户应用754可以被配置为使用多个通信端点，并且因此可以接收多个队列对760a-c中的数据包。网络适配器设备可以确保队列对760a-c被公平地服务，和/或可以根据分配给每个队列对760a-c的优先级和/或服务级别协议来为队列对760a-c提供服务。
在一些实现方式中，以任何顺序填充单独的缓冲区782，并且在任何时候，它们都可用。数据包也可以以任何顺序放置在缓冲区782中。在大多数情况下，网络适配器可以被配置为尽可能快地将来自队列对760a-c的数据包移动到主机存储器780，以试图实现可能的最短延时。由于此原因和其他原因，网络适配器通常也不会缓冲队列对760a-c之外的数据包。有时，没有足够的缓冲区782可用。这可能会发生，因为用户应用754没有分配足够的缓冲区，或者没有足够快地释放缓冲区。如将在下面进一步解释的那样，当发生这种情况时，网络适配器可能开始丢弃发往用户应用754的数据包，并且通知用户应用754，正在丢弃数据包。也可以将响应消息发送回源系统以通知源系统，正在丢弃数据包。在一些情况下，源系统可以通过降低其向特定用户应用754递送数据包的速率来作出响应。在一些实现方式中，由用户应用754确定应该对缓冲区空间不足和/或数据包丢弃采取什么操作，如果发生这种情况的话。
如前所述，数据包可以以任何顺序放入缓冲区782中。在一些实现方式中，驱动器程序758可以负责对数据包进行重新排序，以恢复其计划的顺序。在这些实现方式中，驱动器程序758可以按顺序向用户应用754呈现数据包，而用户应用754可能不知道数据包已经无序地到达。在一些实现方式中，用户程序754可以自己对数据包进行重新排序。在任一情况下，用户应用754和/或驱动器程序758都可以利用主机设备上可用的较高处理能力。
与保证数据包排序的传输服务(如可靠连接和可靠数据报)相比，使用宽松可靠数据报传输的系统可以提供更好的可扩展性和更好的延时，且从而可能为高性能计算应用提供更好的性能。例如，保证数据包顺序的传输服务可能需要网络适配器设备缓冲一定数量的数据包，且然后，在将它们提供给主机设备之前对其进行重新排序。在某些情况下，当数据包不按顺序到达时，网络适配器设备可能需要丢弃流中的所有数据包，并请求从头开始重新发送流。尽管让网络适配器设备对数据包进行重新排序可能会简化主机设备软件，但对网络适配器的要求可能会变得更加复杂，并且可能会增大数据包传递延时和带宽消耗。
相比之下，使用宽松可靠数据报传输，网络适配器设备可能会只将数据包缓冲最短的时间量，因此可能会缩短整体延时。然后，可以由主机设备上的软件执行重新排序操作，其中软件可以以最小的延时成本使用强大的主机设备处理器。可以使宽松可靠数据报传输保证排序，但是这样做需要跟踪从传送侧队列对到接收侧队列对的所有流的数据包顺序状态，或者将属于不同逻辑流的数据包序列化为一个数据包序列。跟踪传送侧队列对和接收侧队列对的所有组合之间的数据包顺序状态可能会使系统难以扩展。对来自不同逻辑流的数据包进行序列化可能会在不相关的流之间产生假的依赖关系，并且可能会增大平均和最大数据包传递延时。在大多数情况下，实际上，用户应用会跟踪它们自己的消息流，并且可以快速被重新配置为管理无序到达的数据包。因此，宽松可靠数据报传输可以将数据包排序交给主机设备软件来处理，并且专注于确保所有数据包都被递送。
如前所述，在典型的计算集群系统中，数据包可能有多条路径可以通过网络从源系统传输到目的地系统。从一个源到一个目的地的数据包流可以被称为数据包流，或者更简单地称为“流”。流中的数据包可能彼此相关(例如，它们属于同一个连续的数据流，诸如视频或对话)，并且流可能会结束并重新开始(例如，视频或对话可能会结束，并可能开始一个新的视频或对话)。同样如前所述，当从给定源到特定目的地的数据包遍布所有可用路径时，可以实现跨集群的更高效率。然而，现有的传输服务通常设计用于有序数据包递送，并且可以被配置为仅通过一条路径发送一个流，以确保有序数据包到达的可能性，并降低性能下降。此外，这些传输服务通常只有在一个流结束而另一个流开始时才能改变路径。
图8示出了宽松可靠数据报传输可如何管理网络830中的多条路径840以实现可用路径840的更高利用率的示例。在图8的示例中，从源系统802到目的地系统852的数据包的流810可以被分成数据包的组，其可以被称为“细流”800。源传输上下文816和对应的目的地传输上下文868可以管理细流800的传送和接收，包括建立和取消网络830上的路径。源上下文816和目的地上下文868还可以基于每个细流800监测数据包的状态。每个细流800都可以通过不同的路径840进行传送，其中一个细流800中的所有数据包都使用相同的路径。在一些实现方式中，全部数据包都通过一个端口822从源系统802传送，并且在一个端口862处在目的地系统852处接收。在其他实现方式中，源系统802和/或目的地系统852可以具有连接到网络830的多个端口。
如前所述，在宽松可靠数据报传输实现方式中，源上下文816通常与一个特定目的地上下文868相关联。在大多数情况下，源上下文816由与目的地系统852相关联的地址来标识。该目的地地址将被分配给目的地上下文868。类似地，目的地上下文868可以由源系统802处的已被分配给源上下文816的地址来标识。源上下文816可以管理数据包流810的传送，该数据包流可以包括来自在源系统802上运行的多个用户应用的数据包。流810中的数据包都将发往在目的地系统852上运行的用户应用。目的地上下文868可以管理在目的地系统852处对流810中的数据包的接收。
在一些实现方式中，当与目的地上下文868相关联的地址被首次映射时(例如根据图5A-5B的示例)，源系统802可以初始化新的细流800。一旦图8的示例中的第一细流800被初始化，就可以建立另外的细流800。连接建立消息可以附加到正常网络流量，并且通常涉及源系统802向目的地系统852发送连接请求，而目的地系统852通过向源系统802发回确认消息来作出响应。在一些实现方式中，细流800是单向的，如在该示例中，其中细流800始于源系统802并终止于目的地系统852。可以使用相同的源上下文816和目的地上下文868来建立始发于目的地系统852并终止于源系统802的细流，但是在一些实现方式中，这些细流将是与图8的示例中所示的不同的细流集，并将分开管理。
图8的示例举例说明了四个细流800。在各种实现方式中，传输上下文816、868可以使用更多或更少的细流800。在一些实现方式中，且源系统802和目的地系统852之间的细流800的数量可以是可配置的，和/或可以仅由两个系统802、852之间的可用路径840的数量限制。
通常，细流800只被传输上下文816、868知道，并且独立于队列对、虚拟机或用户应用。换句话说，在源系统802和目的地系统852上运行的用户应用不知道细流800在大多数实现方式中仅与标准库和/或驱动器程序进行交互。当数据包发往相同的目的地系统852时，来自各种源的数据包可以被放置在同一流810中。可以将来自流810的数据包分配给细流800，使得数据包均匀地分布到细流800中。另选地或另外地，可以分配数据包，以便首先给缺乏数据包的细流800分配数据包。数据包快速减少的细流800可能在使用较快的路径，且因此，将数据包分配给这些细流800可以提高总体利用率和吞吐量。
源上下文816可以基于每个细流800跟踪数据包。每个细流800都可以维护数据包序列号，并且当将来自流810的数据包分配给细流800时，也可以给每个数据包分配该细流800的下一数据包序列号。还可以给数据包分配细流标识符，细流标识符可以由目的地上下文868用来标识每个数据包的细流800。
对于每个细流800，源系统802可以维护分配给细流800的每个数据包的状态信息820。状态信息820可以包括每个数据包的数据包序列号和重传数据包可能需要的任何信息。在大多数情况下，可以维护数据包的状态信息820，从传送数据包的时刻起，直到源系统802接收到数据包被接收到的确认为止。源上下文816可以仅为每个细流800的有限数量的未完成数据包维护状态信息820。例如，源上下文802可以被配置为每个细流800仅允许32个未完成的数据包。每个细流800的未完成数据包的数量可以是固定的或者可以是可配置的。当细流800非常慢时-即，确认到达缓慢或者根本不会到达-源上下文802可以将细流800移动到另一条路径840。
目的地上下文868还可以基于每个细流800利用其自己的状态信息860来跟踪数据包。由目的地上下文868维护的状态信息860还可以包括每个细流800的数据包序列号。如将在下面进一步详细解释的，目的地上下文868可以使用状态信息860来生成传送给源系统802的确认。确认可以通知源上下文802，特定流的数据包已经到达目的地系统852，并且通常指出哪些数据包已经到达。
细流800可以是活动的或空闲的。活动细流800具有未完成的数据包，即，已经发送但尚未被确认的数据包。空闲细流800没有未完成的数据包，且也没有等待发送的数据包。当细流800空闲时，源上下文816可以决定将细流800移动到不同的路径840。通常，源上下文816将随机地而不是系统性地(例如，在固定时间或每当细流800变为空闲时)决定将空闲细流800移动到另一路径。将空闲细流800移动到其他路径可以允许源上下文816尝试在网络830上找到不太繁忙的路径840。
来自每个细流800的数据包可以由源系统802按照它们的数据包序列号的顺序传送。从细流800发送的第一数据包还可以包括“序列开始”指示符以通知目的地上下文868，特定细流800正在启动。然后，目的地上下文868可以使用具有序列开始指示符的数据包中的数据包序列号来确定该细流800的状态。随后，目的地上下文868期待该细流800的数据包按照它们的数据包序列号的顺序到达。因此，例如，来自一个细流800的数据包可以由源系统802传送，它们具有序列号“1、2、3、4、5...”，其中第一数据包包括序列开始指示符。目的地系统852可以接收第一数据包，注意序列开始指示符，并且随后期待该细流800的具有序列号“2、3、4、5...”的数据包按照该顺序到达。
然而，数据包可能会在网络830中丢弃，并且可能永远不会到达目的地系统852。例如，并且继续上面提供的示例，目的地系统可能会接收到具有数据包序列号“1、3”的数据包，这表明具有数据包序列号“2”的数据包可能已经被丢弃。如下面将更详细解释的，由源上下文816和目的地上下文868两者维护的数据包状态可以使得上下文816、868能够标识数据包何时在网络830中已经被丢弃，并且重传丢失的任何数据包。
网络830中的丢弃以及网络830中链路的过度使用导致的缓慢可能会影响性能，且因此通常希望避免或最小化两者。源上下文816可以以多种方式检测沿一条路径840的过多丢弃或拥塞。例如，细流800的状态信息820可以包括定时器，源上下文816可以使用该定时器来确定传送数据包的时间与接收到该数据包的确认的时间之间的时间。长时间段可以表明沿着由细流800使用的路径发生了拥塞。另选地或另外地，源上下文816可以跟踪它可以多快地将数据包添加到每个细流800。不能与其他细流800一样快地接受数据包的细流800可能沿网络上的其路径840遇到了拥塞，和/或可能遇到了过多的丢弃。另选地或另外地，源上下文816可能正在接收针对特定细流800的大量重传请求，这可能表明沿着细流800正在使用的路径发生了过多的丢弃。
当源上下文816确定细流800可能遇到拥塞或过多的丢弃时，源上下文816可将细流800移动到另一路径840。在一些实现方式中，一旦细流800已被移动，即使路径标识符现在可能已经改变，目的地上下文852将继续接收并接受来自细流800的数据包。在一些实现方式中，源上下文816可以使得重定位的细流800发送新的序列开始指示符以及具有最旧未确认的数据包序列号的数据包。在这些实现方式中，在接收到新序列开始指示符时，目的地上下文868可以假定源系统802已经放弃了它在具有新序列开始指示符的数据包之前发送的任何数据包，并丢弃它具有的关于重新启动的细流800的任何信息(例如，数据包序列号)。
在一些情况下，目的地上下文868可以接收到无序到达的数据包中的序列开始指示符。例如，目的地上下文868可以接收具有序列号“1、2、3、1”的数据包，其中序列号“1”的两个数据包都是同一数据包的副本，并且具有序列开始指示符。例如，当细流800的路径840特别慢，并且对于具有序列号“1”的第一数据包的确认到达源系统802的速度非常慢时，这可能发生。由于这种缓慢，源系统802可能在接收到确认之前已经切换路径并且重启细流800。在这种情况下，目的地上下文868可以识别出在接收到具有数据包序列号“1”的第二数据包时它不需要重置细流800的状态。相反，目的地上下文868可以认为具有数据包序列号“1”的第一数据包是序列的开始，并且可以忽略到达的带有数据包序列号“1”和序列开始指示符设定两者的任何附加数据包。在一些实现方式中，目的地上下文868可以发送指出附加数据包未被接受的确认，这可以辅助源上下文816理解情况。
当源系统802或目的地系统852断开连接时，细流800也可能需要重启。目的地系统852可以完全或只部分地断开连接。当目的地系统852被重置时可能发生完全断开连接。一旦目的地系统852在重置之后运行，目的地上下文868可以接收数据包，但是因为其状态信息860已被重置，所以目的地上下文868可能不具有任何细流800的状态信息(例如，已到达的数据包的序列号)。因此，针对所有接收到的数据包，目的地上下文868可以发送指出数据包未被接受的响应。在一些情况下，响应可以包括指示符，该指示符告知源上下文816，目的地上下文868已经接收到它不期望的数据包序列号。一旦接收到这些响应，源上下文816可以通知尝试发送这些数据包的用户应用，目的地上下文852已经丢失了对连接状态的跟踪。这可能会导致用户应用启动恢复操作。
在目的地系统852上也可能会发生部分断开。例如，当目的地系统852上的正在接收流810的虚拟机已经离线时，无论是因为它已经停止或者因为它被关闭，可能会发生部分断开。在一些实现方式中，可以例如通过在控制平面上接收的命令，明确地通知源上下文816，其目标虚拟机处于离线状态。在其他实现方式中，当未完成的数据包在达预定时间段内(例如，在定时器到期时)未被确认时，源上下文816可确定目标虚拟机处于离线状态。在确定或被通知目标虚拟机离线后，源上下文816可丢弃任何未完成的数据包，并关闭其与目的地系统852的连接。在一些实现方式中，源上下文816还可以向源侧的用户应用报告，它所丢弃的数据包未被发送。由于目标虚拟机处于离线状态，所以源上下文816也可以拒绝任何后续的从流810传送数据包的请求。目标虚拟机最终可能被恢复，且此时，可以通知源上下文816，目标虚拟机已恢复。然后，源上下文816可以重新初始化其与目的地系统852的连接，并且再次开始接受来自流810的数据包。
例如，当目的地系统852上的正在从流810接收数据包的用户应用离线时，也可能会发生部分断开。目的地侧的用户应用可能已崩溃或已关闭。在这种情况下，目的地上下文868可能会像往常一样确认传入数据包，并将它们递送到分配给现在已离线的目的地侧的用户应用的接收队列。然后，数据包可能会被丢弃在接收队列中。在大多数情况下，目的地上下文868不会导致任何细流800被重置，因为在许多情况下，细流可能包括发往包括离线用户应用的多个目的地侧用户应用的数据包。相反，在一些实现方式中，目的地上下文868将把发往离线用户应用的数据包视为已接收到，并交由源系统802和目的地系统852上的用户应用弄清要做什么。在其他实现方式中，数据包将被丢弃，并将通知发送用户应用，丢弃了数据包。
源系统802也可能完全断开(例如，通过重置)或部分断开。源侧的用户应用重启时引起的部分断开可能对源上下文816没有影响。由源侧的虚拟机重新启动或整个源系统802的重置导致的部分断开可能会导致源上下文816被重新启动。在这些情况下，源上下文816可以以与源系统802首次启动时相同的方式重新初始化其细流800。在源系统802处，新启动的细流800通常没有历史(例如，没有已经被确认的数据包序列号)。因此，在一些实现方式中，源上下文816可以在发送具有序列开始指示符的数据包之后延迟发送数据包，直到具有序列开始指示符的数据包已经被目的地系统852确认为止。这样做可以确定细流800的“最近确认的”数据包序列号。在一些情况下，源上下文816可以接收指出具有序列开始指示符的初始数据包未被目的地系统852接受的确认。例如，当目的地上下文868拒绝包括在初始数据包中的数据包序列号时，这可能发生。当发生这种情况时，源上下文816可以再次发送带有序列开始指示符的数据包，而在一些实现方式中，可以提供带有不同的开始数据包序列号的数据包。
在网络830中、路径840切换、断开和细流重启中每一种情况下发生的数据包丢弃都可能会导致需要重新发送数据包。当在目的地系统852处被接收到时，这些重新发送的数据包将与以前接收到的数据包顺序不对。例如，目的地上下文868可能已经接收到序列号为“1、3”的数据包，且因此，可能已经指出需要重新发送序列号为“2”的数据包。一旦重新发送序列号为“2”的数据包，目的地上下文868将具有该特定细流800的序列号“1、3、2”。
如将在下面进一步详细解释的，目的地上下文868可以被配置为期望数据包按照这种方式不按顺序到达。在大多数实现方式中，目的地上下文868与源上下文816协作，确保接收到所有数据包，并且通常不关心接收这些数据包的顺序。目的地上下文868一旦接收到数据包，或者尽可能事实上快地，通常将数据包转发到目的地侧主机设备，并且将对数据包的任何所需的重新排序留给主机设备来处理。应该注意的是，在流810的目的地端处，数据包的顺序可能与它们在流810的源端处的顺序不同。然而，一旦数据包被递送到它们的目标队列对，发往特定目的地侧的用户应用的数据包实际上可能是有序的。然而，队列对中的排序不由目的地上下文868来保证。
如上所述，源上下文816和目的地上下文868可以分别维护每个单独细流800的状态信息820、860。使用状态信息820、860，源上下文816和目的地上下文868可以确保流810中的每个数据包都到达目的地系统852。
图9A-9B示出了宽松可靠数据报传输如何可以保证数据包的可靠递送的示例。宽松可靠数据报传输服务可以通过使传送侧900上下文维护每个传送的数据包的状态信息并通过使接收侧950上下文向传送侧900返回对接收侧接收到的每个数据包的响应来提供数据包的有保证的递送。图9A示出了传送侧900上下文可如何维护每个传送的数据包的状态信息的示例。图9B示出了接收侧950上下文可如何维护状态信息并使用状态信息来生成响应的示例。
通常，用户应用通常不涉及确保数据包到达它们的目的地。为使接收侧用户应用确定一个或多个数据包已在网络中被丢弃，接收到的数据包将必须朝着接收侧传输堆栈一路向上传输到用户应用。一路上，数据包可能会延迟，例如，如果用户应用太忙而无法接收数据包。然后，用户应用将不得不沿着传输堆栈向下通过网络重新传送请求，然后沿着传送侧传输堆栈向上传输到传送用户应用。相比之下，接收侧传输上下文可能是数据包在接收侧的最早接触点，且因此，可能能够更快地确定何时数据包未到达。类似地，传送侧传输上下文可能是第一个接收到重新传送请求的，且因此，可以比用户应用更快地响应重新传送请求。
在一些实现方式中，宽松可靠数据报传输服务可以使用数据包序列号来提供数据包的有保证的且可靠递送。传送侧900传输上下文可以针对它已经传送的每个数据包基于每个细流跟踪数据包序列号。接收侧950传输上下文可以跟踪其接收到的数据包的数据包序列号，并且将响应发送回传送侧900传输上下文。响应可以通知传送侧900传输上下文，已经接收到哪些数据包。具体而言，当接收侧950传输上下文接收到具有相对于其数据包序列号顺序正确的数据包序列号的数据包时，接收侧950传输上下文可以发送“ACK”响应。当接收侧950传输上下文接收到相对于其数据包序列号而失序的数据包时，接收侧950传输上下文可以发送“选择性ACK”或“SACK”响应。有时，数据包可能到达接收侧950传输上下文，但是接收侧950传输上下文可能不能接受数据包。在这种情况下，接收侧950传输上下文可以发送“NACK”以向传送侧900传输上下文指出数据包未被接受。
图9A示出了传送侧900对未完成数据包和接收到响应的管理的示例。图9A的示例举例说明了三个细流904a-c。如前所述，一组细流通常包括来自一个数据包流的数据包，但是该流可以包括正在向同一目的地系统传送的来自多个用户应用902的数据包。数据包流可以被分成多个组(在大多数实现方式中，不需要考虑数据包与彼此的关系)，并且这些数据包组可以被称为子流或细流。特定细流中的数据包通常在网络930上使用相同的路径，除非或直到路径被传送侧900传输上下文改变。图9A的简化示例仅示出了每个细流904a-c的四个数据包，而应该理解，每个细流904a-c都可以维护超过四个未完成数据包的状态信息。在一些实现方式中，细流可维护其状态的数据包的数量是有限的(例如，8、16、13或更多数据包)。在这些实现方式中，一旦未完成的数据包的数目等于该限制，则不再能使用该细流发送更多的数据包，直到至少一个未完成的数据包被确认为已被接收为止。
对于第一示例细流904a，前三个数据包908a、908b、908c已经被发送到网络930，而第四数据包908d正在等待被传送。第一细流904a的状态信息906a指出第一数据包908a的ACK状态910a，以及第二数据包908b的ACK状态910b。这两个ACK状态910a、910b都指出第一908a和第二908b数据包在接收侧950传输上下文中被接收，并且它们是按顺序接收的(例如，接收到第一数据包908a，接着是第二数据包908b)。在一些实现方式中，传送侧900传输上下文仅需记住最早的未确认数据包，因为重传任何较旧数据包的请求不大可能到达。在这些实现方式中，传送侧900传输上下文因此可以忘记第一数据包908a以及可能还有第二数据包908b的状态信息906a。在细流中的数据包数量受限的实现方式中，删除一个或两个数据包的状态信息906a也会释放时隙，用于发送更多数据包。
从第一示例细流904a得出结论，第三数据包908c具有已发送状态910c，这意味着尚未接收到对于该数据包908c的响应。第四数据包908d具有未决状态910d，这意味着数据包已被添加到细流904a中，但尚未被发送到网络930中。
对于第二示例细流904b，全部四个数据包912a-d都已经被发送到网络930中。第二细流904b的状态信息906b指出第三数据包912c的SACK状态914c。SACK状态914c指出第三数据包912c由接收侧950传输上下文接收到。SACK状态914c还可以指出还接收到第一数据包912a，这意味着第一数据包912a的ACK状态914a状态。同时，第二数据包912b和第四数据包912c具有已发送状态914b、914c，表示尚未接收到对于这些数据包912b、912c的响应。
在传送侧950传输上下文已经不按顺序接收到数据包时，SACK消息可以由传送侧950传输上下文使用。对于第二示例细流904b，接收到第一数据包912a，且然后，接收到第三数据包912c。这意味着，尽管第二912b数据包具有已发送状态914b，但第二数据包912b没有在第三数据包912c之前到达接收侧950。实际上，第二数据包912b可能已经被网络930丢弃。在一些实现方式中，SACK响应可能已经包括在接收侧950处按顺序接收到的最后一个数据包的数据包序列号(这里是第一数据包912a的序列号)和不按顺序接收到的第一数据包的数据包序列号(这里是第三数据包912c的序列号)。因此，例如，假定使用数字式数据包序列号，SACK响应可能会说出“1、3”。以这种方式，SACK响应可以有效地指出第二数据包912b需要由传送侧900传输上下文重新传送。
响应消息通常以与数据包相同的方式遍历网络930。因此，响应消息也可能会在网络930中被丢弃。这意味着有时接收侧950传输上下文可能会生成指出一个特定数据包尚未到达的一个以上SACK。例如，对于第二示例细流904b，说出“1、3”的SACK可能已经在网络930中被丢弃。假定第四数据包912d已成功地到达接收侧950，传送侧900传输上下文可以生成表示“1、3-4”的SACK，因为接收侧950传输上下文仍未接收到第二912b数据包。
扩展示例可以更好地说明传送侧900传输上下文可以如何确定哪些数据包需要被重新发送。假定在传送侧900处的细流已经发送了数据包序列号为1、2、3、4、5、6的六个数据包。进一步假定，接收侧950的细流已经接收到序列号为1、3、5和6的数据包，并且序列号为2和4的数据包已被丢弃在网络930中。鉴于这种情况，接收侧950可以生成以下响应：
在接收到编号为1的数据包时：ACK(1)
在接收到编号为3的数据包时：SACK(1、3)
在接收到编号为5的数据包时：SACK(1、5)
在接收到编号为6的数据包时：SACK(1、5-6)
如果在传送侧900传输上下文中接收到所有这些确认消息，则第一SACK可以触发编号为2的数据包的重新传送。第二SACK可以仅触发编号为4的数据包的重新传送，因为传送侧900传输上下文可以确定它已经重新传送了编号为2的数据包。第三SACK可能不会触发任何重传。
然而，假设在网络900中第一SACK丢失，接收到第二SACK(SACK(1、5))可以触发传送侧900传输上下文重新发送编号为2、3和4的数据包。假定编号为2的数据包在编号为6的数据包之后到达，则接收侧950传输上下文将生成SACK(3、5-6)以通知传送侧900，编号为4的数据包仍然尚未到达。假设编号为3的数据包接下来到达，则接收侧950传输可以将该数据包识别为重复，并且将丢弃该重复数据包而不发送附加的响应。
在一些实现方式中，传送侧900传输上下文将重传并且继续重传尚未被确认的任何数据包。例如，对于第三细流904c，第四数据包916d具有已发送状态918d，且因此可以周期性地重传。当细流有一个以上未确认的数据包时，通常这些未确认的数据包将按顺序重新传送，从数据包序列号最低的数据包到数据包序列号最高的数据包。例如，对于第二细流904b，传送侧900传输上下文可以重新发送第二数据包912b、然后第四数据包912d、且然后再次发送第二数据包912b和第四数据包912d，直到一个或两个数据包912b、912c被确认。随着附加的SACK响应到达，可能向要重传的数据包列表添加或重新添加由SACK消息指示为未接收到的数据包。在很多情况下，传送侧900传输上下文可以被配置为避免网络930被重传数据包淹没。例如，传送侧900传输上下文可以被配置有最大释放大小，表示细流一次可以发送的数据包的最大数量。当细流发送的数据包的数量(包括首次发送的数据包和正在重新传送的数据包)达到释放大小时，需要重新传送的附加数据包可能会延迟。
在一些实现方式中，细流也可能会停止传送新的数据包，直到至少最旧的未确认的数据包已被确认。例如，在一些实现方式中，细流可以仅维护有限数量的数据包的状态信息。例如，在这些实现方式中，细流可以维护多达六个数据包的状态信息，并且细流可能已发送编号为1至6的数据包。细流还可能接收到编号为2、3和4的数据包的响应，但是未接到编号为1的数据包的响应。在细流接收到编号为1的数据包的确认之前，细流可能需要维护编号为1的数据包的状态信息，以便可以重发该数据包。此外，细流可能无法添加任何新的数据包，直到编号为1的数据包被确认，并从细流中移除，以为附加的数据包腾出空间。
返回到图9A的示例，对于第三细流904c，全部四个数据包916a-d都已经被发送到网络930中。第三细流904c的状态信息906c指出第一数据包916a的ACK状态918a，指出按顺序接收到第一数据包916a。“按顺序接收到”可能意味着，针对该细流接收到的所有数据包都具有紧接在第一数据包916a的数据包序列号之前的顺序数据包序列号(例如，假定第一数据包916a具有数据包序列号“1”，并且假设数据包序列号是从具有最大值32的计数器分配的并且能够环绕，前面的数据包序列号可以是“29、30、31、0”)，或者第一数据包916a具有“序列开始”指示符，并且因此是由该细流904c发送的第一数据包。
然而，第二916b和第三916c数据包具有NACK状态918b、918c。NACK状态918b、918c指出第二916b和第三916c数据包到达接收侧950，但是由于某种原因或其他原因，这些数据包916b、916c在接收侧950未被接受。通常将NACK响应传回到生成数据包的接收到消息的用户应用902。然后，用户应用902可以确定应该执行什么操作；例如，用户应用902可以确定应当重新发送具有NACK状态918b的数据包916b，在这种情况下，用户应用902可以将数据包916b的新副本放入流中。然而，除了将NACK响应传递回用户应用902之外，传送侧900传输上下文还可以将NACK状态918b、918c视为与ACK状态类似，并且将第二916b和第三916c数据包视为完成。这意味着可以将第一916a、第二916b和第三916c数据包及其对应的状态信息918a-c从细流904c中移除，为附加的数据包腾出新的时隙。
传送侧900传输上下文可以为每个细流904a-c维护各种定时器。例如，当接收到响应时，传送侧900传输上下文可以启动第一细流904a的定时器，且每当接收到第一细流904a的另一响应时就重置定时器。如果长时间未接收到响应，则定时器可能会过期。此时，传送侧900传输上下文可能会采取一些动作。例如，如果在第一细流904a中存在大量未完成的数据包，则传送侧900传输上下文可以决定将细流904a切换到不同的路径。大量未完成的数据包可能表示细流904a正在使用的路径非常慢，或者可能具有发生故障的链路。传送侧900传输上下文还可以调度细流904a中的任何未完成的数据包，以便进行重传。
图9B示出了接收侧950对数据包的接收和响应的生成的管理的示例。图9B的示例示出了图9A中所示的三个示例细流904a-c的接收。在图9B中，对于三个示例细流中的每一个，针对每个接收到的数据包，接收侧950传输上下文基于每个细流维护状态信息954a-c。使用状态信息954a-c，接收侧950传输上下文可能能够确定何时尚未接收到预期的数据包。然后，接收侧950传输上下文可以请求传送侧900重新传送缺失的数据包。
对于第一示例细流，状态信息954a可以指出第一数据包958a和第二数据包958b已经到达。在该示例中，第二数据包958b在接收侧950传输上下文能够生成确认成功接收到第一数据包954a的ACK响应之前已经到达。一般而言，接收侧950传输上下文可能不会针对接收到的每个数据包自动生成响应并且对响应进行排队。相反，接收侧950传输上下文可以在接收到细流中的数据包时，将细流标记为需要生成响应。然后，接收侧950传输上下文可以周期性地轮询每个细流，以查看细流是否需要生成响应，且只有直到那时才生成并发送响应。
对于第一细流，这可能意味着第一细流仅在第二数据包958b到达之后才会生成响应。此时，接收侧950传输上下文可以检查细流的状态信息954a，并且使用该信息来生成指出第一958a和第二958b数据包已经到达的累积响应。响应还可以表明这些数据包以其顺序到达，这意味着到目前为止还没有数据包未能到达。因为数据包958a、958b按顺序到达，所以确认将是ACK 960，而ACK 960将包括最近接收到的数据包(即，第二数据包958b)的数据包序列号。
在其他情况下，第一细流可能已经为第一958a和第二958b数据包中的每一个生成了ACK。例如，可以调度第一细流以在第一数据包958a到达之后并且在第二数据包958b到达之后生成响应。在这两种情况下，响应都是ACK，每个都有前一个数据包的数据包序列号。
在生成并传送ACK 960之后，第一细流可能能够清除至少第一数据包958a的状态信息。细流可以维护第二数据包958b的数据包序列号，以跟踪最近接收到的序列号。然而，细流可能会导致数据包本身被发送到接收用户应用952。通常，接收侧950传输上下文可以避免缓冲数据包，并且可以尽可能快地将它们发送到其计划的用户应用952。
对于第二示例细流，状态信息954b指出两个数据包已经到达，在这种情况下是第一数据包962a和第三数据包962c，并且在接收到第三数据包962c时第二数据包962b丢失。这里，在接收到第一数据包962a之后，细流可能已经生成了ACK，但是在第三数据包962c之后，细流将生成SACK 964，因为此时第二数据包962b丢失。SACK 964可以通知传送侧900传输上下文，未接收到第二数据包。例如，SACK响应可以在SACK 960消息中包括第一数据包962a和第三数据包962c的数据包序列号。SACK响应也可能是累积的。例如，如果在该示例中第四数据包在SACK 964被发送之前到达，则细流可以生成指出接收到第一962a、第三962c和第四数据包的SACK。
继续该示例，在第二细流传送第一962a和第三962c数据包的SACK 964之后，丢失的第二数据包962b可能到达。由于例如网络930中的缓慢，第二数据包962b可能刚刚到达。第二数据包962b也可能响应于SACK 964到达，这意味着它是被重传的。在此示例中，第二数据包962b第二次到达。第二数据包962b的第二副本可能到达，例如，因为SACK 964可能在网络964中已经被丢弃。另外，传送侧900的细流中的定时器可能已经过期，并且所有未确认的数据包可能已经被重新传送。状态信息954b允许接收侧950传输上下文识别出第二数据包962b的第二副本是重复的。细流可能随后丢弃重复副本。
对于第三示例细流，状态信息954c指出三个数据包966a-c已经到达。细流接受第一数据包966a，并生成ACK 968a以通知传送侧900传输上下文。然而，细流可能没有接受第二966b和第三966c数据包。例如，当接收用户应用952已经用完了存储器中的缓冲区，并且不可以接受任何更多数据包时，这可能会发生。当发生这种情况时，细流可能为未被接受的数据包966b、966c生成NAK 968b、968c消息。
在一些实现方式中，接收侧950传输上下文可以停止生成响应消息。当未向传送侧900处的几乎空的细流添加新的数据包并且来自该细流的数据包可能已在网络中被丢弃时，可能会发生这种情况。为了使接收侧950传输上下文生成响应(在这种情况下将是指出数据包丢失的SACK)，接收侧950细流本应必须接收另一个数据包，但由于传送侧900细流不接收新的数据包，这可能不会发生。在一些实现方式中，防止这种情况的一种方法是确保不允许细流变得几乎为空，例如，通过频繁地将数据包分配给数据包快速减少的细流。在一些实现方式中，另一种防止未完成数据包绊住细流的方法是动态调整细流的数量。在一些实现方式中，另一种解决方案是使长时间有未完成数据包的细流超时，将这些细流移到另一条路径，以及重新发送这些细流中未完成的任何数据包。
如图9A和图9B的示例所示，宽松可靠数据报传输服务可以使用响应和可能丢失的数据包的重传来保证所有数据包最终被递送。以这种方式，宽松可靠数据报传输可以用于具有高于可忽略的数据包丢弃率的网络930。如这些示例所示，数据包可能不按顺序到达接收侧950，不仅相对于其数据包序列号，而且还相对于数据包彼此相关的顺序。
图10A-10B示出了已被划分成细流1002a-c的单个数据包流以及接收用户应用接收到数据包1004a-d、1006a-d、1008a-d的顺序的示例。在此简化示例中，所示出的数据包1004a-d、1006a-d、1008a-d已经由一个发送用户应用发送并且由一个接收用户应用接收。当所示出的数据包1004a-d、1006a-d、1008a-d由发送用户应用传送时，对于此示例，数据包1004a-d、1006a-d、1008a-d具有特定的序列。例如，数据包1004a-d、1006a-d、1008a-d可以是视频流的一部分，并且承载视频流的连续帧。数据包1004a-d、1006a-d、1008a-d可由发送用户应用分配序列标识符，以通知接收应用正确的数据包顺序。
如上所述，数据包1004a-d、1006a-d、1008a-d可能不按它们最初发送的顺序到达接收用户应用。这可能是由于网络中的丢包、细流的路径改变和/或细流重启等其他原因。数据包1004a-d、1006a-d、1008a-d不按顺序到达也可能是由每组数据包所采用的网络上的路径差异引起的。因此，数据包1004a-d、1006a-d、1008a-d可能需要在到达目的地系统时重新排序。图10A示出了数据包1004a-d、1006a-d、1008a-d随时间的到达以及数据包1004a-d、1006a-d、1008a-d如何可以存储在存储器中。图10B示出了数据包1004a-d、1006a-d、1008a-d的重新排序以恢复其计划的顺序。
在图10A的示例中，数据包流被分成三个细流1002a-c，并且通过每个细流1002a-c接收四个数据包。图10A的示例示出了每个数据包1004a-d、1006a-d、1008a-d随时间的到达。图10A还示出了在存储器中配置的用于接收数据包的缓冲区1010的示例。在一些实现方式中，缓冲区1010是由接收用户应用预先配置的。在这些实现方式中，可以在主机设备的存储器中配置缓冲区1010。
如上面所讨论的，可以给每个细流1002a-c中的数据包1004a-d、1006a-d、1008a-d分配数据包序列号，数据包序列号可以在各自的细流1002a-c内确定数据包的顺序。在此示例中，数据包序列号由字母a、b、c和d表示。对于第一细流1002a，第二数据包1004b首先到达，然后是第一数据包1004a、第四数据包1004d和第三数据包1004c。如前所述，数据包1004a-d到达的顺序可能是由于数据包丢弃、数据包重传以及在有缺陷的网络中可能会发生的其他问题。对于第二细流1002b，第一数据包1006a首先到达，然后是第四数据包1006d、第二数据包1006b且然后是第三数据包1006c按此顺序到达。对于第三细流1002c，第一数据包1008a首先到达，然后在一段时间之后第二数据包1008b、第四数据包1008d和第三数据包1008c到达。
为了解释此示例，数据包1004a-d、1006a-d、1008a-d按照它们在目的地系统处被接收的顺序被放置在缓冲区1010中。同样为了解释此示例的目的，从左到右填充缓冲区1010。可以理解的是，缓冲区1010可以以任何方便的顺序填充。在此示例中，一些缓冲区1010被占用1012，或者以别的方式不可用，这可能是经常发生的情况。
虽然细流1002a-c内的数据包1004a-d、1006a-d、1008a-d具有相对于该细流1002a-c中的其他数据包1004a-d、1006a-d、1008a-d的到达顺序，但是，数据包1004a-d、1006a-d、1008a-d也具有跨多个细流1002a-c的到达顺序。在该示例中，第一细流1002a是第一个递送数据包1004b的，紧接着是第三细流1008a。这两个数据包1004b、1008a可以按照该顺序写入缓冲区1010。在一些情况下，这前两个数据包1004b、1008a可能已经由细流1002a-c大致同时(例如，在相同的时钟周期)递送。在这种情况下，数据包1004b、1008a的存储顺序可以基于它们的细流1002a、1002c身份，或者存储顺序可以是任意的。
继续该示例，数据包1008a之后可以接着是来自第二细流1002b的两个数据包1006a、1006d，随后是来自第一细流1002a的数据包1004a。第三细流1002c可以提供下一个数据包1008b，随后是分别来自第一1002a、第二1002b和第三1002c细流的数据包1004d、1006b、1008d。本示例中的最后三个数据包1006c、1004c、1008c分别由第二1002b、第一1002a和第三1002c细流递送。
一旦被存储在缓冲区1010中，数据包1004a-d、1006a-d、1008a-d不仅相对于它们的细流1002a-c不按顺序，而且相对于彼此也不按顺序。图10B示出了数据包1004a-d、1006a-d、1008a-d被重新排序并恢复其计划的顺序。如上所述，发送用户应用可能已经为每个数据包分配了序列标识符。在该示例中，通过第一细流1002a传送的数据包1004a-d的组是序列中的第一位，随后是来自第二细流1002b的数据包1006a-d的组和来自第三细流1002c的数据包1008a-d的组。
数据包重新排序可以由驱动器程序和/或接收用户应用执行。在驱动器程序管理数据包重新排序的实现方式中，驱动器程序可以在接收用户应用访问数据包1004a-d、1006a-d、1008a-d之前对它们进行重新排序。附加的存储器1020可用于对数据包1004a-d、1006a-d、1008a-d进行重新排序，并且数据包1004a-d、1006a-d、1008a-d可以以其正确的顺序被复制到该附加存储器1020中。另选地或另外地，数据包1004a-d、1006a-d、1008a-d可以通过在缓冲区1010之间复制它们来重新排序。
III.方法
图11-14示出了使用内核旁路框架并且在一些实现方式中使用宽松可靠数据报传输服务在网络上传送数据包的过程的示例。这些过程可以通过上述系统诸如例如参考图4、图5A-5B、图6A-6B和图7A-7B所描述的系统来实现。为了便于理解，示出了每个示例过程的步骤，并且各个步骤可以以不同于给定顺序的顺序执行，可以包括附加步骤，和/或可以组合成较少的步骤。
图11示出了为将要通过网络传送消息的用户应用可确定传输上下文的过程1100的示例。示例过程1100可以由被配置为实现内核旁路框架的网络适配器设备来执行。网络适配器设备可以与主机设备进行通信，并且主机设备可以运行打算通过网络发送消息的用户应用。
在步骤1102中，网络适配器设备可以接收消息和与该消息相关联的目的地信息。可以从主机设备接收消息和目的地信息。消息在大多数情况下可能是由在主机设备上执行的用户应用生成的。目的地信息通常描述网络中的消息被发送到的位置。在大多数情况下，目的地信息由发送用户应用提供。
在步骤1104中，网络适配器设备可以检查目的地信息。目的地信息可以以不同方式描述消息的预期接收者。例如，目的地信息可以是网络地址1106，例如网络上的系统的IP地址或MAC地址，和/或在网络上的系统上运行的虚拟机的IP地址。另选地或另外地，目的地信息可以是数据包流的流标识符1108。流标识符1108可以是数值，和/或可以是流的源地址和目的地地址的组合。另选地或另外地，目的地信息可以是地址句柄1110。地址句柄1110可以是引用传输上下文和/或生成数据包可能需要的信息的软件变量或指针。例如，地址句柄1110可以是对网络地址映射对象的引用。地址映射对象可以存储对适当的传输上下文的引用，并且还可以存储用于传送数据包的信息，诸如预先生成的数据包报头。在步骤1112中，网络适配器设备可以使用地址句柄1110来确定网络地址映射对象。
在步骤1114中，网络适配器设备可以使用目的地信息来确定传输上下文。在大多数实现方式中，确定的传输上下文与网络上的特定目的地相关联，其中目的地是网络上的系统，和/或在网络上的系统上运行的虚拟机，和/或在网络上的系统上运行(可能在虚拟机上运行的)用户应用。传输上下文可以管理消息在网络上的传送，包括确保消息到达其预期的目的地。在一些实现方式中，使用宽松可靠数据报传输服务来实现传输上下文。
示例性过程1100还示出了几个可选步骤。在第一可选步骤1116中，网络适配器设备可以使用消息和所确定的传输上下文来生成数据包。生成数据包可以包括生成数据包报头并将消息正文放入数据包有效载荷中。在一些实现方式中，预先生成的报头可以与所确定的传输上下文相关联。预先生成的数据包报头可以包括用于在网络上路由数据包的信息，例如源地址和目的地地址和/或端口。由于传输上下文通常与特定的目的地相关联，所以可以预先知道路由信息，并且网络适配器设备可以预先生成并存储数据包报头。
在第二可选步骤1118中，网络适配器设备可以使用所确定的传输上下文来传送在步骤1116中生成的数据包。
图12示出了用于获得地址句柄的过程1200的示例。示例过程1200可以由网络适配器设备执行。网络适配器设备可以与主机设备进行通信，并且主机设备可能正在执行打算通过网络传送消息的用户应用。
在步骤1202中，网络适配器设备可以接收对新的地址句柄的请求。请求可以由用户应用生成，并且可以包括描述网络上的目的地的信息。在一些实现方式中，网络适配器设备可以访问地址映射，地址映射可以例如被存储在网络适配器设备上的存储器中。地址映射可以存储网络上的在主机设备上运行的用户应用打算与其进行通信的系统的地址信息。网络适配器设备可以在步骤1204使用地址映射来确定在步骤1202接收到的请求是否针对新的目的地。当网络适配器设备不知道请求所提供的地址信息时，请求是针对新的目的地。例如，网络适配器设备可能无法在存储已知目的地的地址映射中找到目的地信息。
当针对新的地址句柄的请求不是针对新目的地时，则在步骤1206中，网络适配器设备可以使用目的地信息来确定传输上下文。所确定的传输上下文可能已经由针对与传输上下文相关联的目的地的地址句柄的较早请求来配置。网络适配器设备可以例如通过使用目的地信息对地址映射进行索引并且从地址映射中提取对正确的传输上下文的引用(或描述传输上下文的数据结构)来确定传输上下文。
当对新的地址句柄的请求是针对新目的地时，则网络适配器设备可以在步骤1210中可以为由目的地信息所描述的目的地生成新的传输上下文。在步骤1212中，网络适配器设备可以在新的传输上下文中存储新连接的状态信息。该步骤可以包括将传输上下文与在步骤1208建立的连接相关联。此后，传输上下文可以管理连接，包括例如建立和取消跨越网络的路径、传送数据包和/或维护未完成数据包的状态信息。
在步骤1216中，网络适配器设备可以生成新的地址映射对象。生成新的地址映射对象可以包括生成并存储预先配置的数据包报头，数据包报头包括用于将数据包路由到网络上的目的地的源和目的地信息。新地址映射对象还可以与在步骤1210中生成的新的传输上下文相关联，或者与在步骤1206中确定的传输上下文相关联。
在步骤1208中，网络适配器设备可以与网络上的与目的地信息相关联的系统建立新连接。建立新连接可以包括验证步骤，例如检查发出请求的用户应用被允许与目的地系统进行通信。建立连接还可以包括网络适配器设备和目的地系统之间的消息交换。在一些实现方式中，网络适配器设备可以在步骤1218和1220之后建立新的连接，如下所述。在一些实现方式中，网络适配器设备可以在执行其他操作的同时，在步骤1218和1220之后建立连接。在一些实现方式中，网络适配器设备可以在消息首次被传送到与在步骤1220中返回的地址句柄相关联的目的地系统时建立连接。
在步骤1218中，网络适配器可以生成新的地址句柄。地址句柄可以引用新的地址映射对象，例如，地址句柄可以是指向网络适配器设备的存储器中的地址的软件指针。
在步骤1220中，可以将新的地址句柄返回给发出请求的用户应用。发出请求的用户应用可以存储新的地址句柄以供将来使用。
图13示出了用于通过网络传送数据包以及监测每个数据包的状态以确保每个数据包被递送的过程1300的示例。示例过程1300可以由被配置为实现内核旁路框架的网络适配器设备来执行。在一些实现方式中，网络适配器设备可以使用宽松可靠数据报传输服务来发送数据包并监测它们的状态。
在步骤1302中，网络适配器设备可以接收消息和目的地信息。可以从主机设备接收消息和目的地信息，并且可以在多个发送队列中的发送队列中接收。目的地信息可以描述网络上要接收消息的目的地。网络适配器设备可以在队列对的发送队列中接收消息。队列对可以与在主机设备上执行的用户应用相关联。
在步骤1304中，网络适配器设备可以使用目的地信息和发送队列的身份来确定传输上下文。在大多数实现方式中，传输上下文可以与特定目的地相关联，其中目的地在本示例中由目的地信息和/或发送队列的身份来标识。发送队列的身份可以是网络适配器设备用来从多个队列对中标识发送队列的字母数字值。
在步骤1305中，网络适配器设备可以对于每条消息执行几个步骤。首先，在步骤1306中，网络适配器设备可以使用所确定的传输上下文来生成数据包。传输上下文可以提供将数据包通过网络路由到预期目的地所需的信息，例如端口号、网络地址和/或预先生成的数据包报头。网络适配器设备可以生成一个数据包，并将消息放入数据包的有效载荷中。另选地或另外地，网络适配器设备可以生成两个或更多个数据包，其中每个数据包都在数据包有效载荷中包括消息的一部分。在一些实现方式中，传输上下文还可以向每个数据包分配数据包序列号，其中数据包序列号指出发送数据包的顺序。
在步骤1308中，网络适配器设备可以使用传输上下文通过网络传送每个数据包。传输上下文可以管理每个数据包的传送。在步骤1310中，网络适配器设备可以进一步监测每个传送的数据包的状态。传输上下文还可以管理监测数据包状态。每个数据包的状态都指出数据包是否已在目的地系统上被接收到。在一些实现方式中，传输上下文可能期待来自网络上的目的地的响应消息，其中响应消息指出已经接收到一个或多个数据包。
可以接收至少三种类型的响应消息。第一，在步骤1312中，网络适配器设备可以接收指出在目的地处接收到一个或多个数据包的响应消息。在一些实现方式中，该响应指出按顺序接收到一个或多个数据包，其中它们的顺序由其数据包序列号提供，并且其中在序列中没有数据包丢失。例如，响应可以指出“3”，表明已接收到编号为1、2和3的数据包。
第二，在步骤1314中，网络适配器设备可以接收到指出没有接收到一个或多个数据包的响应。在一些实现方式中，该响应消息可以提供已经到达的数据包的数据包序列号，并且通过序列号中的间隙指出没有到达的数据包。例如，响应中的数据包序列号“1、3”可以指出序列号为“2”的数据包尚未到达。另选地，在一些实现方式中，响应可以列出未被接收到的数据包的数据包序列号。例如，响应中的数据包序列号“2-4”可以指示数据包2、3和4尚未到达。
第三，在步骤1316中，网络适配器设备可以接收包括重传数据包的请求的响应。在一些实现方式中，该响应指出在目的地处接收到数据包，但由于某种原因或其他原因，该数据包未被接受。在步骤1318中，网络适配器设备可以将该响应递送给主机设备。主机设备可能够确定为什么该数据包需要被重传，和/或可以生成新的消息以便重传该数据包。
网络适配器设备也可以被配置为用于没有接收到响应消息或者长时间没有接收到响应消息的情况。例如，网络适配器设备可以在步骤1310中在传送数据包时启动定时器。在步骤1320中，网络适配器设备可以确定定时器已经到期。当定时器到期时，网络适配器设备可能会重新发送先前发送的一个或多个数据包。网络适配器设备还可以采取其他动作，例如更改用于将数据包发送到网络上的目的地的路径。
图14示出了用于通过网络接收数据包并且为每个数据包生成响应以指示数据包已被接收的过程1400的示例。示例过程1400可以由被配置为实现内核旁路框架的网络适配器设备来执行。在一些实现方式中，网络适配器设备可以使用宽松可靠数据报传输服务来接收数据包并生成响应。
在步骤1402中，网络适配器设备可以在接收队列处接收数据包，在接收队列中，数据包是无序地接收的。可以通过网络接收数据包。接收队列可以是队列对的一部分。数据包的顺序可以由分配给每个数据包的数据包序列号确定。当数据包序列号不是按它们的数字顺序排列(例如，从最低到最高)，或者因为数据包序列号从序列中丢失(例如，数据包具有序列号“1、3”)时，数据包可能是无序的。
在接收到每个数据包后，网络适配器设备可以在步骤1404中标识与数据包相关联的传输上下文。网络适配器设备可以从在每个数据包中提供的源地址标识传输上下文。已标识的传输上下文可能正在管理与正在发送数据包的源系统的连接。传输上下文也可能在监测来自特定源系统的数据包的状态。
在步骤1405中，网络适配器设备可以确定数据包是否可以被接受。例如，当主机设备没有可用的存储器来放置数据包，这意味着没有缓冲区可用于接收数据包时，网络适配器设备可以确定它不可以接受数据包。当接收用户应用没有分配足够的存储器来接收数据包和/或没有足够快地释放存储器时，可能会发生这种情况。在某些情况下，需要通知发送用户应用，而在某些情况下，发送用户应用可能会降低其传送数据包的速率。另选地或另外地，网络适配器设备可能确定数据包是重复的。另选地或另外地，网络适配器设备可能确定数据包是无效的。数据包可能无效，例如，如果它没有有效地址、地址错误、损坏、和/或在接收到之前已被标记为无效。在此示例中，网络适配器设备在步骤1405中确定可以接受数据包。
在步骤1406中，网络适配器设备可以使用所标识的传输上下文和接收队列的身份来确定接收数据包的用户应用。传输上下文可以检查数据包以确定其目的地。例如，数据包可以具有目的地地址，并且该目的地地址可以至少部分地标识要接收数据包的用户应用。接收队列的身份也可能部分地标识要接收数据包的用户应用。接收队列的身份可以是网络适配器用来从多个队列对中标识接收队列的字母数字值。
在步骤1408中，网络适配器设备可以将接收到的数据包从接收队列传递到主机存储器中的与接收用户应用相关联的缓冲区。网络适配器设备可以具有分配给接收用户应用的存储器的注册密钥。网络适配器设备可以使用注册密钥将数据包直接写入分配给接收用户应用的存储器中。为了接收来自网络的数据包，接收用户应用可能已预先在此存储器中配置了缓冲区。
在一些实现方式中，网络适配器设备可以在处理一个或多个数据包时传送至少三种响应类型中的一种。传输上下文可以监测流中的数据包的状态，并且可以提供适当的响应。
第一，在步骤1410中，网络适配器设备可以传送指出接收到一个或多个数据包的响应。在一些实现方式中，该响应指出按顺序接收到一个或多个数据包，其中顺序是由分配给每个数据包的数据包序列号提供的，并且其中没有数据包从序列中丢失。例如，响应可以说“3”，其表示已接收到编号为1、2和3的数据包。
第二，在步骤1412中，网络适配器设备可以传送指出没有接收到一个或多个数据包的响应。在一些实现方式中，该响应消息可以提供已经到达的数据包的数据包序列号，并且通过序列号中的间隙指出没有到达的数据包。例如，响应中的数据包序列号“1、3”可以指出编号为“2”的数据包未到达。另选地，在一些实现方式中，响应可以列出未被接收到的数据包的数据包序列号。例如，响应中的数据包序列号“2-4”可以指示数据包2、3和4尚未到达。
第三，在步骤1414中，网络适配器设备可能确定由于以上提供的一个或多个原因，另一个数据包不可以被接受。在确定该数据包不可以被接受时，网络适配器设备可以在步骤1416丢弃该数据包。然后，网络适配器可以可选地在步骤1418中通过网络发送指出将要重新发送数据包的响应。此响应可能会向源系统指出数据包已到达，但数据包不可以被接受，且因此可能需要重新发送。
IV.网络适配器设备
图15示出了可用于实现上文所描述的系统和方法的网络适配器设备1500的示例。在该示例中，网络适配器设备1500可以包括处理核心1502、配置模块1504、管理模块1506、总线接口模块1508、存储器1510和网络接口模块1512。这些模块可以是硬件模块、软件模块或硬件和软件的组合。网络适配器设备1500可以包括这里未示出的附加模块。在一些实现方式中，网络适配器设备1500可以包括更少的模块。模块中的一个或多个可以通过通信信道1514彼此进行通信。通信信道1514可以包括一根或多根总线、网格、矩阵、结构、这些通信信道的组合或某一其他合适的通信信道。在一些实现方式中，网络适配器设备1500的操作可以以单个集成电路或以一组集成电路来实现。集成电路的示例包括ASIC和FPGA。
在一些实现方式中，处理核心1502可以包括被配置为执行指令的一个或多个处理器。可以被包括在处理核心1502中的处理器的示例包括由ARM、MIPS、AMD、Intel、Qualcomm等开发的处理器。在一些实现方式中，处理核心1502的处理器可以共享某些资源，诸如例如总线、1级(L1)高速缓存和/或2级(L2)高速缓存。处理核心1502执行的指令可以例如以计算机程序的形式存储在计算机可读存储介质上。计算机可读存储介质可以是非暂时性的。在一些情况下，计算机可读介质可以是存储器1510的一部分。在一些实现方式中，处理核心1502的操作(有时但不总是包括由处理核心1502执行的指令中的一些或全部)可以以一个或多个集成电路来实现。集成电路的示例包括ASIC和FPGA。
存储器1510可以包括易失性或非易失性存储器，或者易失性和非易失性类型的存储器两者。存储器1510可以例如包括随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、闪存和/或某一其他合适的存储介质。在一些情况下，存储器1510中的一些或全部可以在网络适配器设备1500内部，而在其他情况下，存储器中的一些或全部可以在网络适配器设备1500外部。
在一些实现方式中，配置模块1504可以包括一个或多个配置寄存器。配置寄存器可以控制网络适配器设备1500的操作。在一些实现方式中，配置寄存器中的一个或多个位可以表示网络适配器设备1500的某些能力。配置寄存器可以通过在处理核心1502中执行的指令和/或由外部实体(诸如主机设备、在主机设备上执行的操作系统和/或远程服务器)来编程。配置模块1504可以进一步包括控制网络适配器设备1500的操作的硬件和/或软件。
在一些实现方式中，管理模块1506可以被配置为管理网络适配器设备1500的不同部件。在一些情况下，管理模块1506可以在加电时配置一个或多个配置寄存器中的一个或多个位，以启用或禁用网络适配器设备1500的某些能力。
总线接口模块1508可以通过外部通信介质来实现与外部实体(例如主机设备和/或计算系统中的其他部件)的通信。总线接口1508模块可以包括用于连接到电缆、插座、端口的物理接口或到外部通信介质的其他连接。总线接口模块1508可以进一步包括管理传入和传出事务的硬件和/或软件。总线接口模块1508可以实现本地总线协议，例如NVMe、AHCI、SCSI、SAS、SATA、PATA等。总线接口1508模块可以至少包括用于这些总线协议中的任何一个的物理层，包括连接器、电源管理、错误处理等。在一些实现方式中，网络适配器设备1500可以包括用于与多个外部实体进行通信的多个总线接口模块。这些多个总线接口模块可以实现相同的本地总线协议、不同的本地总线协议或者相同和不同总线协议的组合。
网络接口模块1512可以包括用于与网络进行通信的硬件和/或软件。例如，该网络接口模块1512可以包括用于有线连接到网络的物理连接器，和/或用于与网络进行无线通信的天线。网络接口模块1512可以进一步包括被配置为实现网络协议堆栈的硬件和/或软件。网络接口模块1512可以使用网络协议(例如TCP/IP、Infiniband、RoCE、电气和电子工程师协会(IEEE)802.11无线协议、用户数据报协议(UDP)、异步传输模式(ATM)、令牌环、帧中继、高级数据链路控制(HDLC)、光纤分布式数据接口(FDDI)和/或点对点协议(PPP)等来与网络进行通信。在一些实现方式中，网络适配器设备1500可以包括多个网络接口模块，每个网络接口模块都被配置为与不同的网络进行通信。例如，在这些实现方式中，网络适配器设备1500可以包括用于与有线以太网网络、无线802.11网络、蜂窝网络、Infiniband网络等进行通信的网络接口模块。
在一些实现方式中，网络适配器设备1500是PCI型设备。在这些实现方式中，网络适配器设备1500包括用于与主机设备进行通信的PCI接口。术语“PCI”可用于描述总线协议PCI系列中的任何协议，包括原始PCI标准、PCI-X、AGP和PCIe。PCI协议是用于将本地外围设备连接到主机设备的标准总线协议。标准化的总线协议是一种数据传输协议，各个制造商为该协议定义了规范，并采用该规范。制造商确保符合规范的设备与实现总线协议的计算系统兼容，且反之亦然。
PCI设备可以包括一个或多个功能。“功能”描述了可以由网络适配器设备1500提供的操作。功能的示例包括大容量存储控制器、网络控制器、显示控制器、存储器控制器、串行总线控制器、无线控制器以及加密和解密控制器等等。在某些情况下，PCI设备可能包括一个以上功能。例如，PCI设备可以提供大容量存储控制器和网络适配器。作为另一示例，PCI设备可以提供两个存储控制器来控制两个不同的存储资源。在一些实现方式中，PCI设备可具有多达八个功能。
在一些实现方式中，网络适配器设备1500可以包括单根I/O虚拟化(SR-IOV)。SR-IOV是可以包括在PCI设备中的扩展功能。SR-IOV允许物理资源(例如，单个网络接口控制器)显现为多个资源(例如，六十四个网络接口控制器)。因此，提供特定功能(例如，网络接口控制器)的PCI设备对于使用PCI设备的设备而言可以看起来好像是提供相同功能的多个设备。支持SR-IOV的存储适配器设备的功能可以被分类为物理功能(PF)或虚拟功能(VF)。物理功能是设备的可以被发现、管理和操纵的全部特征化功能。物理功能具有可用于配置或控制存储适配器设备的配置资源。物理功能包括与非虚拟化设备将具有的相同的配置地址空间和存储器地址空间。物理功能可能有许多与其相关联的虚拟功能。虚拟功能与物理功能类似，但是是轻量级功能，缺乏配置资源，并且通常由其基础物理功能的配置来控制。可以将物理功能和/或虚拟功能中的每一个分配给在主机设备上运行的相应的执行线程(诸如例如虚拟机)。
V.计算系统
图16示出了本文所描述的特征和系统的示例体系结构1600。示例体系结构1600包括经由一个或多个网络1608连接的一个或多个服务提供商计算机1610和/或用户设备1604。上面所讨论的系统和方法可以使用图16中所描述的计算设备的一个或多个部件，或者可以代表图16中所描述的一个或多个计算设备。
在所示体系结构1600中，一个或多个用户1602可以使用用户计算设备1604(1)-(N)经由一个或多个网络1608来访问应用1606(例如，网页浏览器或移动设备应用)。在一些方面，应用1606可以由计算资源服务或服务提供商托管、管理和/或提供。一个或多个服务提供商计算机1610可以提供被配置为在用户设备1604上运行的本地应用，用户1602可以与本地应用进行交互。在一些示例中，服务提供商计算机1610可以提供计算资源，例如但不限于客户端实体、低延时数据存储、持久数据存储、数据访问、管理、虚拟化、基于云的软件解决方案、电子内容执行管理等等。服务提供商计算机1610还可以用于向用户1602提供web托管、数据库管理、计算机应用开发和/或实现平台、前述的组合等。在一些示例中，服务提供商计算机1610可以与一个或多个第三方计算机1612进行通信。
在一些示例中，网络1608可以包括诸如电缆网络、因特网、无线网络、蜂窝网络以及其他专用和/或公共网络之类的许多不同类型的网络中的任何一种或其组合。尽管所示示例表示用户1602通过网络1608访问应用1606，但是所描述的技术可以等同地适用于用户1602经由用户设备1604通过固定电话、电话亭或以某种其他方式与服务提供商计算机1610进行交互的情况。所描述的技术还可以应用于其他客户端/服务器布置(例如机顶盒等)以及非客户端/服务器布置(例如，本地存储的应用等)。
如上所述，应用1606可以允许用户1602与服务提供商计算机1610进行交互以例如访问web内容(例如，网页、音乐、视频等)。可以布置在服务器集群中或者作为服务器场的服务提供商计算机1610可以托管应用1606和/或基于云的软件服务。其他服务器体系结构也可以用于托管应用1606。应用1606可能能够处理来自许多用户1602的请求并作为响应而提供例如各种项目网页。应用1606可以提供支持用户交互的任何类型的网站，包括社交网站、在线零售商、信息网站、博客网站、搜索引擎网站、新闻和娱乐网站等。如上文所讨论的，所描述的技术可以类似地在应用1606之外实现，诸如利用在用户设备1604上运行的其他应用。
用户设备1604可以是计算设备，诸如例如移动电话、智能电话、个人数字助理(PDA)、膝上型计算机、上网本计算机、台式计算机、瘦客户端设备、平板计算机、电子书(e-book)阅读器、游戏控制台等等。在一些示例中，用户设备1604可以经由网络1608或经由其他网络连接与服务提供商计算机1610进行通信。另外，用户设备1604可以是由服务提供商计算机1610管理、由其控制的分布式系统的一部分，或以其他方式是服务提供商计算机的一部分(例如，与服务提供商计算机1610集成的控制台设备)。
在一个示例性配置中，用户设备1604可以包括至少一个存储器1614和一个或多个处理单元(或处理器1616)。处理器1616可以用硬件、计算机可执行指令、固件或其组合来实现。处理器1616的计算机可执行指令或固件实现方式可以包括以任何合适的编程语言编写的计算机可执行指令或机器可执行指令，以执行所描述的各种功能。用户设备1604还可以包括用于提供和/或记录与用户设备1604相关联的地理位置信息的地理位置设备(例如，全球定位系统(GPS)设备等)。
用户设备存储器1614可以存储在用户设备处理器1616上可加载和可执行的程序指令，以及存储在执行这些程序期间生成的数据。取决于用户设备1604的配置和类型，用户设备存储器1614可以是易失性的(诸如随机存取存储器(RAM))和/或非易失性的(诸如只读存储器(ROM)、闪存等)。用户设备1604还可以包括附加的可移动存储和/或不可移动存储，包括但不限于磁存储器、光盘、固态盘、闪存和/或磁带存储器。存储设备及其相关联的计算机可读介质可以为计算设备提供计算机可读指令、数据结构、程序模块和其他数据的非易失性存储。在一些实现方式中，存储器1614可以包括多种不同类型的存储器，诸如静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)或ROM。
转到更详细的用户设备存储器1614的内容，存储器1614可以包括操作系统和用于实现本文所公开的特征的一个或多个应用程序或服务。一个或多个应用程序或服务可以至少包括用户提供的输入元素或电子服务网页，诸如浏览器应用1606或专用应用(例如智能电话应用、平板电脑应用等)。浏览器应用1606可以被配置为接收、存储和/或显示用于与服务提供商计算机1610进行交互的网站或其他界面。另外，存储器1614可以存储访问凭证和/或其他用户信息，诸如例如用户ID、密码和/或其他用户信息。在一些示例中，用户信息可以包括用于认证账户访问请求的信息。这样的信息包括例如设备ID、cookie、IP地址、位置等。另外，用户信息可以包括用户提供的对由用户设备1604获得的安全问题或地理位置的响应。
在一些方面，服务提供商计算机1610可以包括诸如例如移动电话、智能电话、个人数字助理(PDA)、膝上型计算机、台式计算机、上网本计算机、服务器计算机、瘦客户端设备、平板计算机、游戏控制台等计算设备。另外地或另选地，在一些实施方案中，服务提供商计算机1610可以作为在托管计算环境中实现的一个或多个虚拟机来提供。托管计算环境可以包括一个或多个快速供应和释放的计算资源。这些计算资源可以包括计算、联网和/或存储设备。托管计算环境也可以被称为云计算环境。在一些示例中，服务提供商计算机1610可以经由网络1608或经由其他网络连接与用户设备1604和/或其他服务提供商进行通信。服务提供商计算机1610可以包括一个或多个服务器，这些服务器可能布置在集群中，作为服务器场，或者作为彼此不相关联的单独服务器。这些服务器可能被配置为集成的分布式计算环境的一部分。
在一个示例性配置中，服务提供商计算机1610可以包括至少一个存储器1618和一个或多个处理单元(或处理器1620)。处理器1620可以用硬件、计算机可执行指令、固件或其组合来实现。处理器1620的计算机可执行指令或固件实现方式可以包括以任何合适的编程语言编写的计算机可执行指令或机器可执行指令，以执行所描述的各种功能。
在一些情况下，硬件处理器1620可以是单核处理器或多核处理器。多核处理器可以包括同一处理器内的多个处理单元。在一些实施方案中，多核处理器可以共享某些资源，诸如总线和第二或第三级高速缓存。在某些情况下，单核或多核处理器中的每个核心都还可能包括多个执行逻辑处理器(或执行线程)。在这种核心(例如那些具有多个逻辑处理器的核心)中，执行流水线的几个阶段以及更低级别的高速缓存也可以被共享。
存储器1618可以存储在处理器1620上可加载和可执行的程序指令，以及存储在执行这些程序期间生成的数据。取决于服务提供商计算机1610的配置和类型，存储器1618可以是易失性的(诸如RAM)和/或非易失性的(诸如ROM、闪存等)。存储器1618可以包括用于实现本文所公开的特征的操作系统1628、一个或多个数据存储区1630、一个或多个应用程序1632、一个或多个驱动器1634和/或服务。
操作系统1628可支持服务提供商计算机1610的基本功能，诸如调度任务、执行应用和/或控制外围设备。在一些实现方式中，服务提供商计算机1610可以托管一个或多个虚拟机。在这些实现方式中，每个虚拟机都可以被配置为执行其自己的操作系统。操作系统的示例包括Unix、Linux、Windows、Mac OS、iOS、Android等。操作系统1628也可以是专有操作系统。
数据存储区1630可以包括由操作系统1628、应用程序1632或驱动器1634使用和/或操作的永久或暂时数据。这种数据的示例包括网页、视频数据、音频数据、图像、用户数据等等。在一些实现方式中，数据存储区1630中的信息可以通过网络1608提供给用户设备1604。在一些情况下，数据存储区1630可以另外地或另选地包括存储的应用程序和/或驱动器。另选地或另外地，数据存储区1630可以存储标准和/或专有软件库，和/或标准和/或专用应用用户接口(API)库。存储在数据存储区1630中的信息可以是机器可读目标代码、源代码、解释代码或中间代码。
应用程序1632包括程序可以包括可由用户设备1604通过网络1608访问的程序。这样的程序的示例包括文字处理程序、会计程序、媒体播放器、图像编辑程序、游戏等。应用程序1632可以另选地或另外地包括在集群或分布式环境中执行的程序，即，在多个服务器提供商计算机1610之间协同执行的应用。
驱动器1634包括可以在服务器提供商计算机1610中的部件之间提供通信的程序。例如，一些驱动器1634可以提供操作系统1628和附加存储器1622、通信连接1624和/或I/O设备1626之间的通信。另选地或另外地，一些驱动器1634可以提供应用程序1632和操作系统1628和/或应用程序1632和服务提供商计算机1610可访问的外围设备之间的通信。在很多情况下，驱动器1634可以包括提供良好理解功能的驱动器(例如，打印机驱动器、显示驱动器，硬盘驱动器)。在其他情况下，驱动器1634可以是专有的或专门的功能。
服务提供商计算机1610或服务器还可以包括附加存储器1622，其可以包括可移动存储器和/或不可移动存储器。附加存储器1622可以包括磁存储器、光盘、固态盘、闪存和/或磁带存储器。附加存储器1622可以与服务提供商计算机1610一起容纳在相同的机箱中，或者可以位于外部机箱中。存储器1618和/或附加存储器1622及其相关联的计算机可读介质可以为计算设备提供计算机可读指令、数据结构、程序模块和其他数据的非易失性存储。在一些实现方式中，存储器1618可以包括多种不同类型的存储器，诸如SRAM、DRAM或ROM。
存储器1618、附加存储1622(可移动和不可移动两者)是计算机可读存储介质的示例。例如，计算机可读存储介质可以包括以用于存储信息的方法或技术实现的易失性或非易失性、可移动或不可移动介质，信息例如包括计算机可读指令、数据结构、程序模块或其他数据。存储器1618和附加存储器1622是计算机存储介质的示例。可能存在于服务提供商计算机1610中的附加类型的计算机存储介质可以包括但不限于PRAM、SRAM、DRAM、RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、DVD或其他光存储器、磁带盒、磁带、磁盘存储器或其他磁存储设备、固态驱动器或可用于存储所需信息并且可被服务提供商计算机1610访问的某种其他介质。计算机可读介质还包括任何上述介质类型的组合。
另选地或另外地，计算机可读通信介质可以包括在诸如载波或其他传输之类的数据信号内传送的计算机可读指令、程序模块或其他数据。然而，如本文所使用的，计算机可读存储介质不包括计算机可读通信介质。
服务提供商计算机1610还可以包含允许服务提供商计算机1610与存储的数据库、另一计算设备或服务器、用户终端和/或网络1608上的其他设备进行通信的通信连接1624。服务提供商计算机1610还可以包括I/O设备1626、诸如键盘、鼠标、笔、语音输入设备、触摸输入设备、显示器、扬声器、打印机等等。通信连接1624和I/O设备1626连同存储器1622可以被描述为外围设备。
服务提供商计算机1610还可以包括一个或多个通信信道1634。通信信道1634可以提供介质，通过介质，服务提供商计算机1610的各种部件可以进行通信。一个或多个通信信道1634可以采用总线、环、交换结构或网络的形式。
本文所描述的模块可以是软件模块、硬件模块或其适当的组合。如果模块是软件模块，则模块可以体现在非暂时性计算机可读介质上并且由本文所述的任何计算机系统中的处理器来处理。应该注意，所描述的过程和体系结构可以在任何用户交互之前以实时或异步模式执行。模块可以按照图16中建议的方式配置，和/或本文所描述的功能可以由作为单独模块存在的一个或多个模块来提供，和/或本文所描述的模块功能可以分布在多个模块上。
图17示出了根据各个实施方案的用于实现各方面的示例性环境1700的各方面。如将了解，尽管出于解释目的使用基于Web的环境，但是可视情况使用不同环境来实现各个实施方案。环境包括电子客户端设备1702，该电子客户端设备可包括可操作来在适当网络1704上发送和接收请求、消息或信息并且将信息传送回设备用户的适当设备。此类客户端设备的示例包括个人计算机、手机、手持式消息传递设备、膝上计算机、机顶盒、个人数据助理、电子书阅读器等等。网络可包括任何适当网络，包括内联网、互联网、蜂窝网、局域网或任何其他此类网络或上述网络的组合。此类系统所用的部件可以至少部分地取决于所选网络和/或环境的类型。用于通过此类网络进行通信的协议和部件是众所周知的，因而本文不再详细论述。网络上的通信可通过有线或无线连接及其组合来实现。在这个示例中，网络包括互联网，因为环境包括用于接收请求并且响应于所述请求而提供内容的Web服务器1706，然而对于其他网络来说，可使用具有类似目的的替代设备，如本领域技术人员所明白的。
所示环境包括至少一个应用服务器1708和数据存储区1710。应当理解，可以存在可以链接起来或以其他方式来配置的若干应用服务器、层或其他元件、过程或部件，所述应用服务器、层或其他元件、过程或部件可交互来执行如从适当数据存储区获取数据之类的任务。如本文所使用的，术语“数据存储区”指代能够存储、访问和检索数据的任何设备或设备组合，其可包括任何标准、分布式或集群式环境中的任何组合和任何数目的数据服务器、数据库、数据存储设备和数据存储介质。应用服务器可包括根据需要而与数据存储区集成的任何适当硬件和软件，用于执行客户端设备的一个或多个应用的各方面、处理应用的大多数数据访问和业务逻辑。应用服务器与数据存储区一起提供访问控制服务，并且能够生成要传递给用户的诸如文本、图形、音频和/或视频之类的内容，其可以由Web服务器以超文本标记语言(“HTML”)、可扩展标记语言(“XML”)或本示例中的另一适当的结构化语言的形式供应给用户。对所有请求和响应的处理以及客户端设备1702与应用服务器1708之间的内容递送可由Web服务器@@06来处理。应当理解，Web服务器1706和应用服务器1708不是必要的，且仅仅是示例性部件，因为本文所论述的结构化代码可在如本文其他地方所论述的任何适当设备或主机上执行。
数据存储区1710可包括若干单独的数据表、数据库或其他数据存储机制和介质，用来存储与特定方面相关的数据。举例来说，所示数据存储区1720包括用于存储生产数据1712和用户信息1716的机制，这些机制可用于为生产端提供内容。数据存储区还被示为包括用于存储日志数据1714的机制，该机制可用于报告、分析或其他此类目的。应当理解，可能存在可能需要存储在数据存储区1710中的许多其他方面，如页面图像信息和访问权信息，所述方面可视情况以上文所列机制中的任何机制来存储或以数据存储区1710中的另外的机制来存储。数据存储区1710可通过与它相关联的逻辑来操作，以便从应用服务器1708接收指令，并且响应于所述指令而获取、更新或以其他方式处理数据。在一个示例中，用户可以针对某种类型的项目提交搜索请求。在此情况下，数据存储区1710可能访问用户信息1716来验证用户的身份，并且可访问目录详细信息以获取有关所述类型的项目的信息。接着可将信息如以网页上的结果列表的形式返回给用户，用户能够通过用户设备1702上的浏览器来查看所述网页。可在浏览器的专用页面或窗口中查看到感兴趣的特定项目的信息。
每个服务器1706、1708通常将包括操作系统，操作系统提供用于所述服务器的一般管理和操作的可执行程序指令，并且通常将包括存储指令的计算机可读存储介质(例如，硬盘、随机存取存储器、只读存储器等)，当由服务器的处理器执行时，所述指令允许服务器实行其期望的功能。用于操作系统和服务器的一般功能的合适的实现方式是已知的，或可在市场上买到，并由本领域的普通技术人员特别是根据本文的公开内容容易地实现。
在一个实施方案中，环境1700是利用通过通信链路、使用一个或多个计算机网络或直接连接来互连的若干计算机系统和部件的分布式计算环境。然而，本领域普通技术人员应理解，这种系统可在具有比图17所示的部件更少或更多部件的系统中同样顺利地操作。因此，图17中的对系统的描绘应该被认为本质上是说明性的，而不是限制本公开的范围。
可根据以下条款来描述本公开的各个实施方案：
条款1.一种计算系统，其包括：
主机设备，其包括：
处理器；
与所述处理器耦合并且可由所述处理器读取的存储器，其中所述存储器被配置为存储用户应用；以及
网络适配器设备，其被配置为与网络进行通信；
其中所述主机设备被配置为：
执行所述用户应用，其中所述用户应用被配置为：
确定消息的目的地地址，其中所述目的地地址与所述网络上的服务器相关联；
确定所述目的地地址的地址句柄；
将所述消息和所述地址句柄提供给所述网络适配器；
并且其中所述网络适配器设备被配置为：
使用所述地址句柄来确定传输上下文，其中所述传输上下文包括与所述网络上与所述目的地地址相关联的所述服务器的连接的状态；
使用所述消息和所述传输上下文来生成数据包；以及
通过所述网络来传送所述数据包。
条款2.根据条款1所述的计算系统，其中所述主机设备还被配置为执行驱动器程序，并且其中所述用户应用还被配置为在不能确定所述目的地地址的所述地址句柄时：
从所述驱动器程序请求地址句柄，其中所述请求包括所述目的地地址；
并且其中所述驱动器程序被配置为：
使用地址映射来确定所述目的地地址的地址句柄；以及
向所述用户应用提供所述地址句柄。
条款3.根据条款2所述的计算系统，其中所述驱动器程序还被配置为：
确定所述地址映射不包括所述目的地地址；以及
向所述网络适配器设备提供所述目的地地址；
其中所述网络适配器设备还被配置为：
为新连接生成新的传输上下文；
将所述新连接的状态存储在所述新的传输上下文中；
将新的地址句柄与所述新的传输上下文相关联；
向驱动器程序提供新的地址句柄；以及
与所述网络上的与所述目的地地址相关联的所述服务器建立所述新连接；
其中所述驱动器程序还被配置为：
使用所述新的地址句柄来将所述目的地址存储在所述地址映射中；
其中所述确定的传输上下文是所述新的传输上下文，并且其中由所述驱动器程序提供的所述地址句柄是所述新的地址句柄。
条款4.一种装置，其包括：
处理器；以及
与所述一个或多个处理器耦合并且可由所述一个或多个处理器读取的存储器，其中所述存储器被配置为存储多个传输上下文；
其中所述装置被配置为：
与网络和主机设备进行通信；
从所述主机设备接收消息和与所述消息相关联的目的地信息；以及
使用所述目的地信息来确定来自所述多个传输上下文的传输上下文，其中所述传输上下文包括与所述网络上的目的地的连接的状态，其中所述网络上的所述目的地与所述目的地信息相关联。
条款5.根据条款4所述的装置，其中所述装置还被配置为：
使用所述消息和所述传输上下文来生成数据包；以及
使用所述传输上下文通过所述网络来传送所述数据包。
条款6.根据条款4或5所述的装置，其中所述目的地信息包括地址句柄，并且其中所述装置还被配置为：
使用所述地址句柄来确定来自多个地址映射对象的网络地址映射对象，其中所述多个地址映射对象被存储在所述存储器中，并且其中所述地址映射对象与所述确定的传输上下文相关联。
条款7.根据条款6所述的装置，其中所述网络地址映射对象包括预先生成的数据包报头。
条款8.根据条款6所述的装置，其中所述装置还被配置为：
接收对新的地址句柄的请求，其中所述请求包括所述目的地信息；
使用所述新的目的地信息来标识所述网络地址映射对象；
生成所述新的地址句柄，其中所述新的地址句柄与所述网络地址映射对象相关联；以及
返回所述新的地址句柄。
条款9.根据条款6所述的装置，其中所述装置还被配置为：
接收对新的地址句柄的请求，其中所述请求包括新的目的地信息；
在确定所述多个传输上下文不包括与所述新的目的地信息相关联的传输上下文时：
生成新的传输上下文；以及
将所述新连接的状态存储在所述新的传输上下文中；以及
生成新的网络地址映射对象，其中所述网络地址映射对象与所述新的传输上下文相关联；
生成所述新的地址句柄，其中所述新的地址句柄与所述新的网络地址映射对象相关联；以及
返回所述新的地址句柄。
条款10.根据条款9所述的装置，其中所述装置还被配置为在确定所述多个传输上下文不包括与所述新目的地信息相关联的传输上下文时，与所述网络上与所述新目的地信息相关联的新的目的地建立新连接。
条款11.根据条款9所述的装置，其中生成新的网络地址映射对象包括使用所述新的目的地信息来生成数据包报头，其中所述生成的数据包报头存储在所述新的网络地址映射对象中。
条款12.根据条款4-11中任一项所述的装置，其中所述装置还被配置为与所述网络上与所述目的地信息相关联的目的地建立连接。
条款13.根据条款4-12中任一项所述的装置，其中所述目的地信息包括网络地址。
条款14.根据条款4-13中任一项所述的装置，其中所述目的地信息包括流标识符。
条款15.根据条款4-14中任一项所述的装置，其中所述网络上的所述目的地与所述网络上的服务器相关联。
条款16.根据条款4-15中任一项所述的装置，其中所述网络上的所述目的地与一个或多个互联网协议地址相关联。
条款17.根据条款4-16中任一项所述的装置，其中所述网络上的所述目的地与互联网协议地址和通信端点标识符相关联。
条款18.根据条款4-17中任一项所述的装置，其中所述消息包括序列标识符，所述序列标识符指出所述消息的相对于来自所述消息的源的其他消息的顺序，并且其中所述装置被配置为：
使用所述传输上下文来生成包括所述消息和所述消息的序列标识符的数据包；
使用所述传输上下文通过所述网络来传送所述数据包。
监测所述传送的数据包的状态。
条款19.根据条款4-18中任一项所述的装置，其中所述装置是网络适配器设备。
条款20.根据条款4-19中任一项所述的装置，其中所述装置是片上系统(SoC)、现场可编程门阵列(FPGA)或专用集成电路(ASIC)。
条款21.一种装置，其包括：
处理器；以及
与所述一个或多个处理器耦合并且可由所述一个或多个处理器读取的存储器，其中所述存储器被配置为存储多个传输上下文；
其中所述装置被配置为：
与网络进行通信；
通过所述网络接收数据包，所述数据包请求建立与所述网络上的源的连接；
生成与所述网络上的所述源相关联的传输上下文，其中所述传输上下文包括与所述网络上的所述源的连接的状态；
将所述传输上下文存储在所述存储器中；以及
向所述网络上的所述源传送响应，所述响应确认建立了所述连接。
条款22.根据条款21所述的装置，其中所述装置还被配置为：
通过所述网络接收第二数据包，所述第二数据包请求建立与所述网络上的第二源的第二连接；
使用所述第二数据包来标识所述传输上下文；以及
向所述网络上的所述第二源传送第二响应，所述第二响应确认建立了所述第二连接。
条款23.根据条款21或22所述的装置，其中所述装置被配置为：
标识相对于其他数据包接收所述数据包的顺序；
确定所述数据包是否可以被接受；以及
在确定所述数据包可以被接受时：
使用包括在所述数据包中的目的地信息来确定接收队列，其中所述接收队列与所述主机设备上的用户应用相关联；
将所述数据包传递到所述接收队列；以及
传送指出所述数据包的状态的响应。
条款24.一种方法，其包括：
由网络适配器设备接收消息和与所述消息相关联的目的地信息；
使用所述目的地信息来确定来自多个传输上下文的传输上下文，其中所述传输上下文包括与所述网络上的目的地的连接的状态，其中所述网络上的所述目的地与所述目的地信息相关联。
条款25.根据条款24所述的方法，其还包括：
使用所述消息和所述传输上下文来生成数据包；以及
使用所述传输上下文通过所述网络来传送所述数据包。
条款26.根据条款24或25所述的方法，其中所述目的地信息包括地址句柄，并且还包括：
使用所述地址句柄来确定来自多个地址映射对象的网络地址映射对象，其中所述多个地址映射对象被存储在所述存储器中，并且其中所述地址映射对象与所述确定的传输上下文相关联。
条款27.根据条款26所述的方法，其还包括：
由所述网络适配器设备接收对新的地址句柄的请求，其中所述请求包括所述目的地信息；
使用所述新的目的地信息来标识所述网络地址映射对象；
生成所述新的地址句柄，其中所述新的地址句柄与所述网络地址映射对象相关联；以及
返回所述新的地址句柄。
条款28.根据条款26所述的方法，其还包括：
由所述网络适配器设备接收对新的地址句柄的请求，其中所述请求包括新目的地信息；
在确定所述多个传输上下文不包括与所述新的目的地信息相关联的传输上下文时：
生成新的传输上下文；以及
将所述新连接的状态存储在所述新的传输上下文中；以及
与所述网络上与所述新目的地信息相关联的新目的地建立新连接；
生成新的网络地址映射对象，其中所述网络地址映射对象与所述新的传输上下文相关联；
生成所述新的地址句柄，其中所述新的地址句柄与所述新的网络地址映射对象相关联；以及
返回所述新的地址句柄。
条款29.一种计算系统，其包括：
主机设备，其包括：
处理器；以及
与所述处理器耦合并且可由所述处理器读取的存储器；其中所述存储器被配置为存储用户应用；以及
网络适配器设备，其被配置为与网络进行通信；
其中所述主机设备被配置为执行所述用户应用，其中所述用户应用被配置为：
在所述存储器中配置多个缓冲区；
其中所述网络适配器设备被配置为：
通过所述网络接收多个数据包，其中所述多个数据包源自所述网络上的源，并且其中所述多个数据包被无序地接收；
在接收到来自所述多个数据包的数据包时：
标识与所述数据包的所述源和目的地相关联的传输上下文；
使用所述数据包中包括的端点标识符来确定所述数据包是用于所述用户应用的；以及
将所述接收到的数据包传递到来自所述多个缓冲区的缓冲区；以及
使用所述标识的传输上下文通过所述网络传送指出来自所述多个数据包的数据包的状态的响应；
并且其中所述用户应用还被配置为：
对在所述多个缓冲区中接收到的所述数据包进行重新排序，以按顺序地放置所述接收到的数据包。
条款30.根据条款29所述的计算系统，其中所述网络适配器设备还被配置为：
监测来自所述多个数据包的每个数据包所包括的标识符；以及
确定未接收到来自所述多个数据包的一个或多个数据包；
其中所述响应标识未被接收到的所述一个或多个数据包。
条款31.根据条款29或30所述的计算系统，其中所述网络适配器设备还被配置为：
确定所述多个缓冲区已满；以及
丢弃来自所述多个数据包的一个或多个数据包。
条款32.根据条款31所述的计算系统，其中所述响应标识被丢弃的所述一个或多个数据包。
条款33.一种装置，其包括：
处理器，以及
多个接收队列；
其中所述装置被配置为：
与主机设备和网络进行通信；
通过所述网络接收数据包，其中所述数据包源自所述网络上的源并被无序地接收；以及
对于每个接收到的数据包：
标识与所述接收的数据包的所述源和目的地相关联的传输上下文；
标识所述接收到的数据包被接收的相对于其他数据包的顺序；
确定所述接收到的数据包是否可以被接受；以及
在确定所述接收到的数据包可以被接受时：
使用包括在所述接收到的数据包中的目的地信息来确定接收队列，其中所述接收队列与所述主机设备上的用户应用相关联；以及
将所述接收到的数据包传递到所述接收队列。
条款34.根据条款33所述的装置，其中所述装置还被配置为在确定所述数据包可以被接受时，使用所述标识的传输上下文通过所述网络传送指出所述接收到的数据包中的一个或多个的状态的响应。
条款35.根据条款34所述的装置，其中所述响应指出接收到一个或多个数据包。
条款36.根据条款34所述的装置，其中所述响应指出没有接收到一个或多个数据包。
条款37.根据条款33-36中任一项所述的装置，其中所述装置被配置为针对第二接收到的数据包：
确定所述第二接收到的数据包不可以被接受；以及
丢弃所述第二接收到的数据包。
条款38.根据条款37所述的装置，其中所述装置被配置为通过确定所述多个缓冲区已满而确定所述第二数据包不可以被接受。
条款39.根据条款37所述的装置，其中所述装置被配置为通过确定先前接收到与所述第二接收到的数据包对应的数据来确定所述第二数据包不可以被接受。
条款40.根据条款37所述的装置，其中所述装置被配置为通过确定所述第二接收到的数据包无效而确定所述第二数据包不可以被接受。
条款41.根据条款37所述的装置，其中所述装置还被配置为在确定所述第二接收到的数据包不可以被接受时，使用所述标识的传输上下文来通过所述网络传送标识要重新发送的一个或多个数据包的响应，所述一个或多个数据包包括所述第二接收到的数据包。
条款42.根据条款33-41中任一项所述的装置，其中所述标识的传输上下文包括所述装置与所述网络上的所述源之间的连接的状态。
条款43.根据条款33-42中任一项所述的装置，其中所述标识的传输上下文提供所述网络上的从所述网络上的所述源到所述装置的多条路径。
条款44.根据条款33-43中任一项所述的装置，其中所述数据包被分成数据包的子流。
条款45.根据条款33-44中任一项所述的装置，其中通过不同的网络路径接收每个数据包子流。
条款46.根据条款33-44中任一项所述的装置，其中所述装置还被配置为：
对于数据包的子流，监测来自所述数据包的子流的每个数据包所包括的标识符；以及
使用所述标识符来确定来自所述数据包子流的特定数据包是按顺序接收的；
其中所述响应标识来自所述数据包子流的按顺序接收到的一个或多个数据包，来自所述数据包子流的所述一个或多个数据包包括所述特定数据包。
条款47.根据条款33-44中任一项所述的装置，其中所述装置还被配置为：
对于数据包的子流，监测来自所述数据包的子流的每个数据包所包括的标识符；以及
使用所述标识符确定未接收到来自所述数据包子流的特定数据包；
其中所述响应标识来自所述数据包子流的未被接收到的一个或多个数据包，来自所述数据包子流的所述一个或多个数据包包括所述特定数据包。
条款48.根据条款33-47中任一项所述的装置，其中所述装置是网络适配器设备。
条款49.根据条款33-48中任一项所述的装置，其中所述装置是片上系统(SoC)、现场可编程门阵列(FPGA)或专用集成电路(ASIC)。
条款50.一种方法，其包括：
在网络适配器设备处通过网络接收多个数据包，其中所述多个数据包源自所述网络上的源并且被无序地接收；以及
在接收到来自所述多个数据包的数据包时：
标识与所述接收到的数据包的所述源和目的地相关联的传输上下文；
标识所述接收到的数据包被接收的相对于来自所述多个数据包的其他数据包的顺序；
确定所述接收到的数据包是否可以被接受；以及
在确定所述接收到的数据包可以被接受时：
使用包括在所述接收到的数据包中的目的地信息来确定接收队列，其中所述接收队列与用户应用相关联；以及
将所述接收到的数据包传递到所述接收队列；以及
使用所述标识的传输上下文，通过所述网络，传送指出来自所述多个数据包的一个或多个数据包的状态的响应。
条款51.根据条款50所述的方法，其中所述响应指出接收到来自所述多个数据包的所述一个或多个数据包。
条款52.根据条款50或51所述的方法，其中所述响应指出未接收到来自所述多个数据包的所述一个或多个数据包。
条款53.根据条款50-52中的任一项所述的方法，其还包括，对于第二接收到的数据包：
确定所述第二接收到的数据包不可以被接受；
丢弃所述第二接收到的数据包；
其中所述响应标识要重新发送的一个或多个数据包，所述一个或多个数据包包括所述第二接收到的数据包。
条款54.根据条款50-53中任一项所述的方法，其中所述标识的传输上下文包括所述网络适配器设备和所述网络上的所述源之间的连接的状态。
条款55.一种计算系统，其包括：
主机设备，其包括：
处理器；
与所述处理器耦合并且可由所述处理器读取的存储器，其中所述存储器被配置为存储用户应用；以及
网络适配器设备，其被配置为与网络进行通信；
其中所述主机设备被配置为：
执行所述用户应用，其中所述用户应用被配置为向所述网络适配器设备提供消息，其中每条消息都包括地址句柄；
其中所述网络适配器设备被配置为：
对于来自所述用户应用的每条消息：
使用所述地址句柄来确定所述消息的传输上下文，其中所述传输上下文与所述网络上的目的地相关联，并且其中所述传输上下文提供目的地地址；
为所述消息生成数据包，所述数据包包括所述目的地地址；以及
通过所述网络来传送所述数据包；
通过所述网络接收响应，其中每个响应都指出针对所述消息发送的一个或多个数据包的状态；以及
向所述用户应用报告所述一个或多个数据包的所述状态。
条款56.根据条款55所述的计算系统，其中响应指出一个或多个数据包被成功接收。
条款57.根据条款55或56所述的计算系统，其中响应指出没有接收到一个或多个数据包，并且其中所述网络适配器设备还被配置为：
重传被指出为未接收到的所述一个或多个数据包。
条款58.根据条款55-57中任一项所述的计算系统，其中响应指出一个或多个数据包在所述目的地被丢弃，并且其中所述网络适配器设备还被配置为：
向所述用户应用报告所述响应。
条款59.一种装置，其包括：
处理器；以及
多个发送队列；
其中所述装置被配置为与主机设备和网络进行通信，并且其中所述装置还被配置为：
在所述多个发送队列处从所述主机设备接收消息，每条消息都包括相应的序列标识符，所述序列标识符指出每条相应消息的相对于来自所述消息的源的其他消息的顺序，其中所述消息中的每一条都与同一目的地信息相关联；
确定来自所述多个发送队列的发送队列供进行处理；以及
对于所述确定的发送队列中的每条消息：
使用所述目的地信息和所述确定的发送队列的身份来确定与所述网络上的目的地相关联的传输上下文；
使用所述传输上下文来生成包括所述消息和所述消息的序列标识符的数据包；
使用所述传输上下文通过所述网络来传送所述数据包；以及
监测所述传送的数据包的状态。
条款60.根据条款59所述的装置，其中所述装置还被配置为：
通过所述网络接收响应，其中所述响应指出在所述网络上的所述目的地处接收到针对所述消息的所述数据包中的一个或多个。
条款61.根据条款60所述的装置，其中所述装置还被配置为：
通过所述网络接收响应，其中所述响应指出在所述网络上的所述目的地处未接收到针对所述消息的所述数据包中的一个或多个；以及
重传被指出为未接收到的所述一个或多个数据包。
条款62.根据条款60所述的装置，其中所述装置还被配置为：
通过所述网络接收响应，其中所述响应包括重传针对所述消息的所述数据包中的一个或多个的请求；以及
向所述主机设备报告所述响应。
条款63.根据条款59-62中任一项所述的装置，其中所述传输上下文在所述网络上提供到达所述网络上的所述目的地的多条路径。
条款64.根据条款59-63中任一项所述的装置，其中所述装置还被配置为：
将针对所述消息的所述数据包划分为数据包的子流。
条款65.根据条款64所述的装置，其中所述装置还被配置为：
通过不同的网络路径传送每个数据包子流。
条款66.根据条款64所述的装置，其中所述装置还被配置为：
接收指出来自数据包的子流的一个或多个数据包被成功接收的响应。
条款67.根据条款64所述的装置，其中所述装置还被配置为：
通过所述网络接收指出来自数据包的子流的一个或多个数据包未在所述网络上的所述目的地处被接收到的响应；以及
重传被指出为未接收到的所述一个或多个数据包。
条款68.根据条款64所述的装置，其中所述装置还被配置为，针对每个数据包子流：
在传送来自所述数据包子流的数据包时，启动定时器；
在所述定时器到期时，重传来自所述数据包子流的一个或多个数据包。
条款69.根据条款59-68中任一项所述的装置，其中所述装置是网络适配器设备。
条款70.根据条款59-69中任一项所述的装置，其中所述装置是片上系统(SoC)、现场可编程门阵列(FPGA)或专用集成电路(ASIC)。
条款71.一种方法，其包括：
由网络适配器设备在多个发送队列处从主机设备接收消息，每条消息都包括序列标识符，所述序列标识符指出每条相应消息的相对于来自所述消息的源的其他消息的顺序，其中所述消息中的每一条都与同一目的地信息相关联；
确定来自所述多个发送队列的发送队列供进行处理；以及
对于所述确定的发送队列中的每条消息：
使用所述目的地信息和所述确定的发送队列的身份来确定传输上下文，其中所述传输上下文与所述网络上的目的地相关联；
使用所述传输上下文来生成包括所述消息和所述消息的序列标识符的数据包；
使用所述传输上下文通过所述网络来传送所述数据包；以及
监测所述传送的数据包的状态。
条款72.根据条款71所述的方法，其还包括：
通过所述网络接收响应，其中所述响应指出在所述网络上的所述目的地处接收到针对所述消息的所述数据包中的一个或多个。
条款73.根据条款71或72所述的方法，其还包括：
通过所述网络接收响应，其中所述响应指出在所述网络上的所述目的地处未接收到针对所述消息的所述数据包中的一个或多个；以及
重传被指出为未接收到的所述一个或多个数据包。
条款74.根据条款71-73中任一项所述的方法，其还包括：
通过所述网络接收响应，其中所述响应包括重传针对所述消息的所述数据包中的一个或多个的请求；以及
向所述主机设备报告所述响应。
条款75.根据条款71-74中任一项所述的方法，其还包括，对于数据包子流：
在传送所述数据包时，启动定时器；
在所述定时器到期时，重传来自所述数据包子流的一个或多个数据包。
各个实施方案可进一步在各种操作环境中实现，在一些情况下，所述环境可包括一个或多个用户计算机、计算设备或可用于操作多个应用中的任一个的处理设备。用户或客户端设备可包括多个通用个人计算机中的任何一个，如运行标准操作系统的台式计算机或膝上计算机，以及运行移动软件并且能够支持多个网络连接协议和消息传递协议的蜂窝设备、无线设备和手持式设备。这样的系统还可以包括多个工作站，它们运行各种市场上可买到的操作系统中的任何一个以及用于诸如开发和数据库管理之类的用途的其他已知应用。这些设备还可以包括其他电子设备，例如虚拟终端、瘦客户端、游戏系统以及能够通过网络进行通信的其他设备。
大多数实施方案利用本领域技术人员熟悉的至少一种网络，用于使用各种市场上可买到的协议中的任何一种诸如传输控制协议/因特网协议(“TCP/IP”)、开放式系统互连(“OSI”)、文件传输协议(“FTP”)、通用即插即用(“UpnP”)、网络文件系统(“NFS”)、公共因特网文件系统(“CIFS”)以及AppleTalk来支持通信。网络例如可以是局域网、广域网、虚拟专用网、互联网、内联网、外联网、公共交换电话网、红外网络、无线网络以及上述网络的任何组合。
在利用Web服务器的实施方案中，Web服务器可以运行各种各样服务器或中间层应用中的任一种，包括超文本传输协议(“HTTP”)服务器、FTP服务器、公共网关接口(“CGI”)服务器、数据服务器、Java服务器和业务应用服务器。服务器还能够响应来自用户设备的请求而执行程序或脚本，如通过执行可以实施为以任何编程语言(如
Figure BDA0002240972880001021
C、C#或C++)或任何脚本语言(如Perl、Python或TCL)以及其组合写成的一个或多个脚本或程序的一个或多个Web应用。服务器还可以包括数据库服务器，包括但不限于可从
Figure BDA0002240972880001022
Figure BDA0002240972880001023
和
Figure BDA0002240972880001024
购得的那些数据库服务器。
环境可包括如上文所论述的各种各样数据存储区以及其他存储器和存储介质。这些可驻留在各种位置，例如驻留在计算机中的一个或多个本地(和/或驻留在所述计算机中的一个或多个中)或远离整个网络上的任何或全部计算机的存储介质上。在一组特定的实施方案中，信息可以驻留在本领域技术人员熟悉的存储区域网络(“SAN”)中。类似地，用于执行归属于计算机、服务器或其他网络设备的功能的任何必要文件可酌情存储在本地和/或远程地存储。在系统包括计算机化设备的情况下，每一个这样的设备都可包括可通过总线电耦合的硬件元件，所述元件包括例如至少一个中央处理单元(“CPU”)、至少一个输入设备(例如，鼠标、键盘、控制器、触摸屏或小键盘)和至少一个输出设备(例如，显示设备、打印机或扬声器)。这样的系统还可以包括一个或多个存储设备，诸如磁盘驱动器、光存储设备以及诸如随机存取存储器(“RAM”)或只读存储器(“ROM”)之类的固态存储设备，以及可移动介质设备、存储卡、闪存卡等。
此类设备还可包括计算机可读存储介质读取器、通信设备(例如，调制解调器、网卡(无线或有线)、红外线通信设备等)和如上文所述的工作存储器。计算机可读存储介质读取器可与计算机可读存储介质连接或被配置为接收计算机可读存储介质，计算机可读存储介质表示远程、本地、固定和/或可移动存储设备以及用于暂时和/或更永久地含有、存储、传输和检索计算机可读信息的存储介质。系统和各种设备通常还将包括位于至少一个工作存储器设备内的多个软件应用、模块、服务或其他元件，包括操作系统和应用程序，如客户端应用或网络浏览器。应当了解，替代实施方案可具有与上述实施方案不同的众多变体。例如，也可使用定制硬件，和/或特定元件可以以硬件、软件(包括可移植软件，如小程序)或两者来实现。此外，可以采用与诸如网络输入/输出设备之类的其他计算设备的连接。
用于含有代码或部分代码的存储介质和计算机可读介质可包括本领域已知或已使用的任何适当介质，包括存储介质和通信介质，如但不限于以用于存储和/或传输信息(如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术所实现的易失性和非易失性、可移动和不可移动的介质，包括RAM、ROM、电可擦可编程只读存储器(“EEPROM”)、闪存或其他存储器技术、只读光盘存储器(“CD-ROM”)、数字通用光盘(DVD)或其他光学存储器、磁盒、磁带、磁盘存储设备或其他磁性存储设备，或可用于存储所需信息且可由系统设备访问的任何其他介质。基于本文中提供的公开和教导，本领域普通技术人员将理解实现各实施方案的其他方式和/或方法。
因此，说明书和附图被认为是说明性的而不是限制性的意义。然而，在不脱离如在权利要求中阐述的本公开的较宽泛的精神和范围的情况下可对其做出各种修改和改变将是明显的。
其他变体也在本公开的精神内。因此，尽管所公开的技术可容许各种修改和替代构造，但在附图中已示出并且在上文中详细描述所示的其特定实施方案。然而，应当了解，并不旨在将本公开限制于所公开的一种或多种具体形式，相反地，旨在涵盖落在如所附权利要求书限定的本公开的精神和范围内的所有修改、替代构造和等效物。
在描述所公开实施方案的上下文中(尤其是在以下权利要求书的上下文中)，术语“一(a/an)”和“该”以及类似指称对象的使用应解释为涵盖单数和复数两者，除非在本文另外地指示或明显地与上下文矛盾。术语“包括”、“具有”、“包括”和“含有”应解释为开放式术语(即，意味着“包括但不限于”)，除非另外地注解。术语“连接型”应解释为部分地或全部地纳入、附接至或结合在一起，即使存在中间物。除非本文中另外指出，否则本文中对值范围的引用仅意在充当分别引用处于所述范围内的各单个值的简写方法，且各单个值都并入本文中，如同在本文中对其分别进行引用一样。除非本文中另外指出或与上下文明显矛盾，否则本文中所描述的所有方法都可以按任何合适的顺序执行。本文提供的任何和所有示例或示例性语言(例如，“诸如”)的使用仅旨在更好地说明本公开的实施方案，而不会对本公开的范围构成限制，除非另有声明。本说明书中的语言不应解释为将任何非要求保护的要素指示为实践本公开所必需。
诸如短语“X、Y或Z中的至少一个”之类的析取语言意图在上下文中被理解为通常用于表示项目、项等可以是X、Y或Z或其任何组合(例如，X、Y和/或Z)，除非另有具体陈述。因此，这样的析取语言通常并不意味着并且不应该暗示某些实施方案要求X中的至少一个、Y中的至少一个或者Z中的至少一个每个存在。
本文中描述了本公开的优选实施方案，包括发明人已知用于实行本公开的最佳模式。阅读上述说明后那些优选实施方案的变体对于本领域的普通技术人员可以变得明显。发明人希望技术人员视情况采用此类变体，并且发明人意图本公开以不同于如本文所特别描述的方式来实践。因此，只要适用的法律允许，本公开包括此处所附权利要求书中叙述的主题的所有修改和等效物。此外，除非本文另外指示或另外明显地与上下文矛盾，否则本公开涵盖其所有可能变体中的上文所描述的元素的任何组合。

Claims (21)

1.一种计算系统，其包括：
主机设备，其包括：
处理器；以及
与所述处理器耦合并且可由所述处理器读取的存储器；其中
所述存储器被配置为存储用户应用；以及
网络适配器设备，其被配置为与网络进行通信；
其中所述主机设备被配置为执行所述用户应用，其中所述用户应用被配置为向所述网络适配器设备提供消息，所述消息包括对所述传输上下文的参考；
所述网络适配器设备被配置为：
使用对所述传输上下文的所述参考来确定所述消息的传输上下文，其中所述传输上下文将发射应用与所述网络上第二主机设备上的接收应用相关联，所述用户应用是所述发射应用，并且所述传输上下文提供所述第二主机设备的目的地地址；
使用所述传输上下文来确定使用传输服务，其中所述传输服务使得能够在没有专用连接的情况下有保证的数据包的乱序传送，其中使用所述传输上下文包括：
为所述消息生成多个数据包，来自所述多个数据包的每个数据包括所述目的地地址和所述消息的一部分；
将所述多个数据包添加到与所述传输上下文相关联的数据包流中，其中所述数据包流中的每个数据包被分配一序列号；
通过所述网络传送所述多个数据包；
通过所述网络接收响应，其中所述响应指出来自所述多个数据包的一个或更多个数据包的状态，所述一个或更多个数据包在所述响应中由序列号标识；以及
向所述发射应用报告所述一个或更多个数据包的所述状态。
2.如权利要求1所述的计算系统，其中所述响应指出在所述第二主机设备处接收到了一个或多个数据包。
3.如权利要求1所述的计算系统，其中所述响应指出没有接收到一个或更多个数据包，并且所述网络适配器设备被进一步配置为：
重传被指出没有在所述第二主机设备处接收到的所述一个或更多个数据包。
4.如权利要求1所述的计算系统，其中所述响应指出在所述第二主机设备处丢弃了一个或更多个数据包，并且所述网络适配器设备被进一步配置为：
向所述发射应用报告所述响应。
5.一种装置，包括：
集成电路，被配置为执行管理模块，其中所述管理模块被配置为管理传输服务，所述传输服务使得能够在没有专用连接的情况下有保证的数据包的乱序传送，且其中所述管理模块被配置为：
维护多个发送队列；
接收来自所述多个发送队列的一发送队列处的消息，其中所述消息被接收自在网络上的主机设备上执行的发射应用；并且所述消息包括目的地信息；
确定传输上下文，其中所述传输上下文将所述发射应用与所述网络上第二主机设备上的接收应用相关联，并且所述传输上下文是用所述目的地信息和所述发送队列的身份来确定的；
使用所述传输上下文，确定使用所述传输服务来传送所述消息，其中使用所述传输服务包括：
为所述消息生成多个数据包；
将所述多个数据包添加到与所述传输上下文相关联的数据包流中，其中所述数据包流中的每个数据包被分配一序列号；
通过所述网络传送所述多个数据包；以及
监测来自所述多个数据包的每个数据包的状态，其中监测包括使用所述序列号来确定是否在所述第二主机设备处接收到了来自所述多个数据包的每个数据包。
6.如权利要求5所述的装置，其中使用所述传输服务还包括：
通过所述网络接收响应，其中所述响应指出在所述第二主机设备处接收到了来自所述多个数据包的一个或更多个数据包。
7.如权利要求5所述的装置，其中使用所述传输服务还包括：
通过所述网络接收响应，其中所述响应指出在所述第二主机设备处没有接收到来自所述多个数据包的一个或更多个数据包；
重传被指出没有接收到的所述一个或更多个数据包。
8.如权利要求5所述的装置，其中使用所述传输服务还包括：
通过所述网络接收响应，其中所述响应包括针对重传来自所述多个数据包的一个或更多个数据包的请求；以及
向所述发射应用报告所述响应。
9.如权利要求5所述的装置，其中所述传输上下文使得所述多个数据包能够使用所述网络上、在所述主机设备与所述第二主机设备之间的多条路径。
10.如权利要求5所述的装置，其中使用所述传输服务还包括：
将所述数据包流中的所述数据包分成数据包的子流。
11.如权利要求10所述的装置，其中使用所述传输服务还包括：
通过不同的网络路径传送数据包的每个子流。
12.如权利要求10所述的装置，其中使用所述传输服务还包括：
接收响应，所述响应指出在所述第二主机设备处接收到了来自数据包子流的一个或更多个数据包。
13.如权利要求10所述的装置，其中使用所述传输服务还包括：
通过所述网络接收响应，其中所述响应指出在所述第二主机设备处没有接收到来自数据包子流的一个或更多个数据包；
重传被指出没有接收到的所述一个或更多个数据包。
14.如权利要求10所述的装置，其中使用所述传输服务还包括，针对每个数据包子流：
在传送来自所述数据包子流的数据包时启动定时器，当接收到响应时重启所述定时器，其中所述响应指出在所述第二主机设备处接收到了来自所述数据包子流的另一个数据包；
在所述定时器到期时，重传来自所述数据包子流的一个或多个数据包。
15.如权利要求5所述的装置，其中所述装置是网络适配器设备。
16.如权利要求5所述的装置，其中，所述装置是片上系统(SoC)、现场可编程门阵列(FPGA)或专用集成电路(ASIC)。
17.一种方法，包括：
由网络适配器设备接收来自多个发送队列的一发送队列处的消息，其中所述多个发送队列由所述网络适配器设备维护，所述消息是从在网络上的主机设备上执行的发射应用接收的，并且所述消息包括目的地信息；
确定传输上下文，其中所述传输上下文将所述发射应用与所述网络上第二主机设备上的接收应用相关联，并且所述传输上下文是用所述目的地信息和所述发送队列的身份来确定的；
使用所述传输上下文，确定使用所述传输服务，其中所述传输服务使得能够在没有专用连接的情况下有保证的数据包的乱序传送，并且使用所述传输上下文包括：
为所述消息生成多个数据包；
将所述多个数据包添加到与所述传输上下文相关联的数据包流中，其中所述数据包流中的每个数据包被分配一序列号；
通过所述网络传送所述多个数据包；
监测来自所述多个数据包的每个数据包的状态，其中监测包括使用所述序列号来确定是否在所述第二主机设备处接收到了来自所述多个数据包的每个数据包。
18.如权利要求17所述的方法，其中使用所述传输上下文还包括：
通过所述网络接收响应，其中所述响应指出在所述第二主机设备处接收到了来自所述多个数据包的一个或更多个数据包。
19.如权利要求17所述的方法，其中使用所述传输服务还包括：
通过所述网络接收响应，其中所述响应指出在所述第二主机设备处没有接收到来自所述多个数据包的一个或更多个数据包；以及
重传被指出没有接收到的所述一个或更多个数据包。
20.如权利要求17所述的方法，其中使用所述传输服务还包括：
通过所述网络接收响应，其中所述响应包括针对重传来自所述多个数据包的一个或更多个数据包的请求；以及
向所述发射应用报告所述响应。
21.如权利要求17所述的方法，其中使用所述传输服务还包括：
在传送来自所述多个数据包的数据包时启动定时器，当接收到响应时重启所述定时器，其中所述响应指出在所述第二主机设备处接收到了来自所述多个数据包的另一个数据包；以及
当所述定时器到期时，重传来自所述多个数据包的一个或多个数据包。
CN201910999930.5A 2015-12-29 2016-12-28 网络技术 Active CN110719294B (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US14/983,431 2015-12-29
US14/983,436 US9985904B2 (en) 2015-12-29 2015-12-29 Reliable, out-of-order transmission of packets
US14/983,434 2015-12-29
US14/983,434 US9985903B2 (en) 2015-12-29 2015-12-29 Reliable, out-of-order receipt of packets
US14/983,436 2015-12-29
US14/983,431 US10148570B2 (en) 2015-12-29 2015-12-29 Connectionless reliable transport
CN201680076964.1A CN108476209B (zh) 2015-12-29 2016-12-28 网络技术

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201680076964.1A Division CN108476209B (zh) 2015-12-29 2016-12-28 网络技术

Publications (2)

Publication Number Publication Date
CN110719294A true CN110719294A (zh) 2020-01-21
CN110719294B CN110719294B (zh) 2021-06-01

Family

ID=57822100

Family Applications (3)

Application Number Title Priority Date Filing Date
CN201680076964.1A Active CN108476209B (zh) 2015-12-29 2016-12-28 网络技术
CN201910999314.XA Active CN110557408B (zh) 2015-12-29 2016-12-28 用于网络传输的计算系统和方法以及网络适配器设备
CN201910999930.5A Active CN110719294B (zh) 2015-12-29 2016-12-28 网络技术

Family Applications Before (2)

Application Number Title Priority Date Filing Date
CN201680076964.1A Active CN108476209B (zh) 2015-12-29 2016-12-28 网络技术
CN201910999314.XA Active CN110557408B (zh) 2015-12-29 2016-12-28 用于网络传输的计算系统和方法以及网络适配器设备

Country Status (10)

Country Link
EP (3) EP3734931B1 (zh)
JP (3) JP6490310B2 (zh)
KR (3) KR102055535B1 (zh)
CN (3) CN108476209B (zh)
AU (3) AU2016382952B2 (zh)
BR (1) BR112018013438A2 (zh)
CA (1) CA3010186C (zh)
CL (1) CL2018001771A1 (zh)
SG (1) SG11201805409SA (zh)
WO (1) WO2017117259A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022056791A1 (zh) * 2020-09-17 2022-03-24 华为技术有限公司 一种报文重传方法和装置
US11343198B2 (en) 2015-12-29 2022-05-24 Amazon Technologies, Inc. Reliable, out-of-order transmission of packets

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115941616A (zh) * 2017-12-15 2023-04-07 微软技术许可有限责任公司 多路径rdma传输
US10708170B2 (en) 2018-03-14 2020-07-07 At&T Intellectual Property I, L.P. Transferring data over multiple network paths using decoupled sub-flows
US10574755B2 (en) * 2018-03-28 2020-02-25 Wipro Limited Method and high performance computing (HPC) switch for optimizing distribution of data packets
CN109271268B (zh) * 2018-09-04 2022-03-18 超越科技股份有限公司 一种基于dpdk的智能容错方法
US10945190B2 (en) 2019-01-04 2021-03-09 Apple Inc. Predictive routing based on microlocation
CN109951532B (zh) * 2019-02-27 2021-09-24 江苏省未来网络创新研究院 一种基于dpdk的流量模型自动变换装置
US20220272060A1 (en) * 2019-08-01 2022-08-25 Shift5, Inc Systems, methods, and data structures for serial data collection and compression
CN112749142B (zh) * 2019-10-31 2023-09-01 上海哔哩哔哩科技有限公司 句柄管理方法和系统
CN111064587B (zh) * 2019-11-15 2021-09-07 宁波积幂信息科技有限公司 一种分布式数据系统的节点及广播传输数据管理方法
CN111404893B (zh) * 2020-03-06 2021-12-21 深信服科技股份有限公司 一种主机分类方法、装置、设备及计算机存储介质
US11604743B2 (en) 2020-08-31 2023-03-14 International Business Machines Corporation Input/output queue hinting for resource utilization
WO2023241770A1 (en) * 2022-06-13 2023-12-21 Huawei Technologies Co., Ltd. Efficient rerouting of a selective-repeat connection
CN115174484A (zh) * 2022-06-16 2022-10-11 阿里巴巴（中国）有限公司 基于rdma的数据传输方法、装置、设备及存储介质
CN115550250B (zh) * 2022-11-17 2023-04-07 鹏城实验室 小流报文重传方法、系统、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1625179A (zh) * 2003-11-20 2005-06-08 微软公司 按可定制的、基于标签协议中的引用发送
US6990528B1 (en) * 2000-10-19 2006-01-24 International Business Machines Corporation System area network of end-to-end context via reliable datagram domains
WO2013169073A1 (en) * 2012-05-10 2013-11-14 Samsung Electronics Co., Ltd. Method and system for connectionless transmission during uplink and downlink of data packets
CN104620664A (zh) * 2012-07-02 2015-05-13 阿尔卡特朗讯 利用包括在上行链路数据分组中的隧道标识符和基站标识符的承载激活

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7171484B1 (en) * 2000-05-24 2007-01-30 Krause Michael R Reliable datagram transport service
US6898638B2 (en) * 2001-01-11 2005-05-24 International Business Machines Corporation Method and apparatus for grouping data for transfer according to recipient buffer size
US20030005039A1 (en) * 2001-06-29 2003-01-02 International Business Machines Corporation End node partitioning using local identifiers
US7116673B2 (en) * 2001-08-09 2006-10-03 International Business Machines Corporation Queue pair resolution in infiniband fabrics
US7149220B2 (en) * 2002-04-25 2006-12-12 International Business Machines Corporation System, method, and product for managing data transfers in a network
US7912979B2 (en) * 2003-12-11 2011-03-22 International Business Machines Corporation In-order delivery of plurality of RDMA messages
US7533176B2 (en) * 2004-07-14 2009-05-12 International Business Machines Corporation Method for supporting connection establishment in an offload of network protocol processing
US20060075067A1 (en) * 2004-08-30 2006-04-06 International Business Machines Corporation Remote direct memory access with striping over an unreliable datagram transport
US20070208820A1 (en) * 2006-02-17 2007-09-06 Neteffect, Inc. Apparatus and method for out-of-order placement and in-order completion reporting of remote direct memory access operations
US9697147B2 (en) * 2012-08-06 2017-07-04 Advanced Micro Devices, Inc. Stacked memory device with metadata management
CN103986647A (zh) * 2014-05-21 2014-08-13 大唐移动通信设备有限公司 报文传输方法及设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6990528B1 (en) * 2000-10-19 2006-01-24 International Business Machines Corporation System area network of end-to-end context via reliable datagram domains
CN1625179A (zh) * 2003-11-20 2005-06-08 微软公司 按可定制的、基于标签协议中的引用发送
WO2013169073A1 (en) * 2012-05-10 2013-11-14 Samsung Electronics Co., Ltd. Method and system for connectionless transmission during uplink and downlink of data packets
CN104620664A (zh) * 2012-07-02 2015-05-13 阿尔卡特朗讯 利用包括在上行链路数据分组中的隧道标识符和基站标识符的承载激活

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11343198B2 (en) 2015-12-29 2022-05-24 Amazon Technologies, Inc. Reliable, out-of-order transmission of packets
US11770344B2 (en) 2015-12-29 2023-09-26 Amazon Technologies, Inc. Reliable, out-of-order transmission of packets
WO2022056791A1 (zh) * 2020-09-17 2022-03-24 华为技术有限公司 一种报文重传方法和装置

Also Published As

Publication number Publication date
AU2018250412A1 (en) 2018-11-08
CN110719294B (zh) 2021-06-01
EP3398315B1 (en) 2020-05-20
KR101941416B1 (ko) 2019-04-12
AU2016382952B2 (en) 2018-08-02
EP3734931A1 (en) 2020-11-04
EP3734931B1 (en) 2022-07-27
JP6569020B2 (ja) 2019-08-28
JP6564960B2 (ja) 2019-08-21
AU2018250412B2 (en) 2019-08-15
CN110557408A (zh) 2019-12-10
EP3731487A1 (en) 2020-10-28
JP6490310B2 (ja) 2019-03-27
CN108476209B (zh) 2019-11-05
JP2019504557A (ja) 2019-02-14
KR20190009419A (ko) 2019-01-28
BR112018013438A2 (pt) 2019-04-24
AU2019261814A1 (en) 2019-12-05
CL2018001771A1 (es) 2018-10-12
CN110557408B (zh) 2021-02-05
CN108476209A (zh) 2018-08-31
EP3398315A1 (en) 2018-11-07
EP3731487B1 (en) 2022-07-06
JP2019092217A (ja) 2019-06-13
KR102023122B1 (ko) 2019-09-20
KR20180089548A (ko) 2018-08-08
AU2016382952A1 (en) 2018-07-12
JP2019092218A (ja) 2019-06-13
AU2019261814B2 (en) 2020-09-24
CA3010186C (en) 2021-07-13
SG11201805409SA (en) 2018-07-30
WO2017117259A1 (en) 2017-07-06
KR102055535B1 (ko) 2019-12-12
CA3010186A1 (en) 2017-07-06
KR20190108188A (ko) 2019-09-23

Similar Documents

Publication Publication Date Title
CN110719294B (zh) 网络技术
US11770344B2 (en) Reliable, out-of-order transmission of packets
US10917344B2 (en) Connectionless reliable transport
US10673772B2 (en) Connectionless transport service

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