CN103731409B - 用于具有tcp加速的嵌入式汽车采集设备的分布式测量装置 - Google Patents

用于具有tcp加速的嵌入式汽车采集设备的分布式测量装置 Download PDF

Info

Publication number
CN103731409B
CN103731409B CN201310481321.3A CN201310481321A CN103731409B CN 103731409 B CN103731409 B CN 103731409B CN 201310481321 A CN201310481321 A CN 201310481321A CN 103731409 B CN103731409 B CN 103731409B
Authority
CN
China
Prior art keywords
data
tcp
transmission
control protocol
buffer
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
CN201310481321.3A
Other languages
English (en)
Other versions
CN103731409A (zh
Inventor
P.莫尔
S.施特劳布
C.波尔
K.勒特格
H.洛伊韦尔
T.拜尔
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.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
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 Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of CN103731409A publication Critical patent/CN103731409A/zh
Application granted granted Critical
Publication of CN103731409B publication Critical patent/CN103731409B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Communication Control (AREA)
  • Small-Scale Networks (AREA)

Abstract

本发明涉及用于具有TCP加速的嵌入式汽车采集设备的分布式测量装置，其涉及用于在通信系统的客户端层和/或传输层中的任何两个设备之间在任一方向上传送数据的方法和通信系统。根据在下文中称为TCP的传输控制协议来执行数据传输。为了实现高数据传输速率，提出了在通信系统内提供用于缓冲要传送的数据的中央存储装置（12）和TCP协议操作块（10），其中，TCP协议操作块（10）处理对存储在存储装置（12）中的已传输数据的参考而不是数据本身。本发明还涉及位于通信系统的两个设备之间的嵌入式采集设备（1），在所述两个设备之间将传送数据。所述采集设备（1）包括适合于执行根据本发明的方法的装置。

Description

用于具有TCP加速的嵌入式汽车采集设备的分布式测量装置
技术领域
本发明涉及一种分布式测量系统。在此类系统中，传输控制协议(TCP)被广泛地用于被连接到汽车电子控制单元(ECU)的嵌入式采集设备与在个人计算机(例如，来自ETASGmbH的INCA)上运行的汽车开发软件工具之间的测量、校准和诊断(MCD)数据的可靠传输。
背景技术
嵌入式采集设备常常被共同定位至ECU(测试下的设备，DUT)，并且必须在与ECU本身相同的苛刻环境条件下操作。从车辆电池供应的采集设备的功耗必须是低的，以便在不对电池施加过大压力的情况下保持在待机模式，以便能够捕捉ECU的启动行为。
传输控制协议(TCP)是互联网协议组的核心协议中的一个。TCP是该协议组的两个原始组成部分中的一个，补充了互联网协议(IP)，并且因此整个协议组一般被称为TCP／IP。TCP提供八位位组(octet)的流从一个计算机上的程序到另一计算机上的另一程序的可靠、有序输送。TCP是由诸如万维网、电子邮件、远程管理和文件传输的主要互联网应用所使用的协议。不要求可靠数据流服务的其他应用可以使用用户数据报协议(UDP)，其提供相比于可靠性而言强调减少的等待时间的数据报服务。
该协议对应于TCP／IP组的传输层。TCP在应用程序与互联网协议(IP)之间的中间层级处提供通信服务。也就是说，当应用程序期望使用IP跨越互联网发送大的数据块而不是将数据分解成IP尺寸的片并发布一系列IP请求时，软件能够向TCP发布单个请求并让TCP处理IP细节。
IP通过交换称为分组的信息片来进行工作。分组是八位位组序列并由后面是主体的报头组成。报头描述分组的目的地和可选地描述将用于进行转发直至其到达其目的地的路由器。主体包含有效载荷数据。
由于网络拥挤、业务量负荷平衡或其他不可预测的网络行为，IP分组可能丢失、被复制或不按顺序输送。TCP检测这些问题，请求对丢失数据的重传，重新布置不按顺序的数据，并且甚至帮助使网络拥挤最小化以减少其他问题的发生。一旦TCP接收器已经重新组装最初传送的八位位组序列，则其将它们传递至应用程序。因此，TCP从底层联网细节提取应用的通信。
TCP广泛地被许多互联网最流行的应用所利用，包括万维网(WWW)、电子邮件、 文件传输协议、安全壳、对等文件共享以及某些流媒体应用。
TCP是保证接收到的所有字节将与发送的字节相同并按照正确的顺序的可靠流输送服务。由于分组传输是不可靠的，所以能够使用称为具有重传的肯定确认的技术来保证分组传输的可靠性。这种基础技术要求接收器在其接收到数据时用确认消息进行响应。发送器保持其发送的每个分组的记录。发送器还保持从发送分组时开始的定时器，并且如果该定时器在消息已被确认之前到期，则重传分组。在分组变为丢失或被损坏的情况下需要该定时器。
TCP由一组规则组成：对于协议而言，其与互联网协议一起使用，并且对于IP而言，其被用于通过互联网在计算机之间“以消息单元的形式”发送数据。虽然IP处理数据的实际输送，但TCP跟踪数据传输的各个单元，称为段，消息被划分成所述段以用于通过网络进行有效路由。例如，当从网络服务器发送HTML文件时，该服务器的TCP软件层将文件的八位位组序列划分成段并将其单独地转发到IP软件层(互联网层)。互联网层通过添加包括(除其他数据之外)目的地IP地址的报头来将每个TCP段封装到IP分组中。即使每个分组具有相同的目的地地址，也能够通过网络在不同的路径上将其路由。当目的地计算机上的客户端程序接收到它们时，TCP层(传输层)将各个段重新组装并在其将这些段流送至应用时确保这些段被正确地排序且没有错误。
下面描述TCP段结构。传输控制协议从数据流接受数据，将其分段成块，并添加TCP报头，创建TCP段。TCP段然后被封装到互联网协议(IP)数据报中。TCP段是“TCP用来与其对端交换数据的信息分组”。
虽然有时被非正式地使用，术语TCP分组并不符合当前术语，其中，段指的是TCPPDU(协议数据单元)，数据报指的是IP PDU，以及帧指的是数据链路层PDU。
进程通过访问TCP并将数据的缓冲器作为自变量进行传递来传送数据。TCP将来自这些缓冲器的数据包装成段并访问互联网协议(例如，IP)以将每个段传送到目的地TCP。
TCP段由段报头和数据区段组成。TCP报头包含10个强制字段以及可选扩展字段(选项、表格形式的橙色背景)。
数据区段跟随报头。其内容是为应用所载送的有效载荷数据。在TCP段报头中未指定数据区段的长度。其能够通过用总IP数据报长度(在IP报头中指定)减去TCP报头和封装IP报头的组合长度来计算。
图7示出了TCP报头的格式，具体如下：
·源端口(Source port)(16位)-识别发送端口
·目的地端口(Destination port)(16位)-识别接收端口
·序列号(Sequence number)(32位)-具有双重作用：
·如果SYN标志被置位(1)，则这是初始序列号。实际第一数据字节的序列号和相应ACK中的已确认的号则是此序列号加1。
·如果SYN被清零(0)，则这是用于当前会话的此分组的第一数据字节的累积序列号。
·确认号(Acknowledgment number)(32位)-如果ACK标志被置位，则此字段的值是接收器正在预期的下一序列号。其确认所有在先字节(如果有的话)的接收。由每个端点所发送的第一ACK确认其他端点的初始序列号本身，但没有数据。
·数据偏移(Data offset)(4位)-以32位字来指定TCP报头的尺寸。最小尺寸报头是5个字且最大的是15个字，因此给出20字节的最小尺寸和60字节的最大尺寸，允许报头中的多达40个字节的选项。此字段因其也是从TCP段的开始至实际数据的偏移的事实而得名。
·预留(Reserved)(3位)-用于未来适用并应被置位为零
·标志(9位)(也称为控制位)-包含9个1位标志
·NS(1位)-当前ECN(ECN-nonce)隐藏保护(被RFC3540添加到报头)。
·CWR(1位)-拥挤窗口减少(CWR)标志被发送主机置位以指示其接收到具有被置位的ECE标志的TCP段并已经以拥挤控制机制(被RFC3168添加到报头)进行响应。
·ECE(1位)-ECN回波(echo)指示
·如果SYN标志被置位(1)，则TCP对端具备ECN能力。
·如果SYN标志被清零(0)，则在正常传输期间接收IP报头组中的具有经历拥挤标志的分组(由RFC3168添加到报头)。
·URG(1位)-指示紧急指针字段是显著的
·ACK(1位)-指示确认字段是显著的。由客户端发送的初始SYN分组之后的所有分组应当使此标志被置位。
·PSH(1位)-推动函数。要求将已缓冲数据推到接收应用。
·RST(1位)-将连接重置
·SYN(1位)-使序列号同步。只有从每个端点发送的第一分组应当使此标志被置位。某些其他标志基于此标志而改变含义，并且某些标志仅在其被置位时是有效的，并且其他标志在其清零时是有效的。
·FIN(1位)-不再有来自发送器的数据
·窗口尺寸(Window Size)(16位)-接收窗口的尺寸，其指定此段的发送器当前正原意接收的字节的数目(超过确认字段中的序列号)(参见流程控制和窗口缩放)
·校验和(Checksum)(16位)-16位校验和字段被用于报头和数据的检错
·紧急指针(Urgent pointer)(16位)-如果URG标志被置位，则此16位字段是与指示最后紧急数据字节的序列号的偏移
·选项(Option)(可变0-320位，可除以32)-此字段的长度由数据偏移字段确定。选项具有多达三个字段：选项-种类(1字节)、选项-长度(1字节)、选项-数据(可变)。选项-种类字段指示选项的类型，并且是不可选的唯一字段。根据正在处理什么种类的选项，可以将接下来的两个字段置位：选项-长度字段指示选项的总长度，以及选项-数据字段包含选项的值，如果可适用的话。例如，0x01的选项种类字节指示这是仅被用于填充(padding)的无操作选项，并且不具有跟随其后的选项-长度或选项-数据字节。0的选项-种类字节是选项结束选项，并且也仅是一个字节。0x02的选项-种类字节指示这是最大段尺寸选项，并且后面将是指定MSS字段的长度(应是0x04)的字节。注意到，此长度是给定选项字段的总长度，包括选项-种类和选项-长度字节。因此，虽然通常以两个字节来表达MSS值，但字段的长度将是4字节(种类和长度的+2字节)。简而言之，具有0x05B4的值的MSS选项字段在TCP选项区段中将显示为(0x02 0x04 0x05B4)。
·填充-TCP报头填充被用来确保TCP报头结束且数据在32位边界上开始。填充由零组成。
某些选项可能只有当SYN被置位时才发送；其在下面被指示为[SYN]。选项-种类和标准长度被给定位(选项-种类，选项-长度)。
·0(8位)-选项列表的结束
·1(8位)-无操作(NOP，填充)。这可以被用来使32位边界上的选项字段对准以获得更好的性能。
·2，4，SS(32位)-最大段尺寸(参见最大段尺寸)[SYN]
·3，3，S(24位)-窗口比例(细节参见窗口缩放)[SYN]
·4,2(16位)-许可的选择性确认。[SYN](细节参见选择性确认)
·5,N,BBBB,EEEE,…(可变位，N是10、18、26或34)-选择性确认(SACK)。这前两个字节后面是被选择性地确认的1-4个块的列表，被指定为32位开始／结束指针。
·8，10,TTTT，EEEE(80位)-时间戳和前一时间戳的回波(细节参见TCP时间戳)
·14,3,S(24位)-TCP替换校验和请求。[SYN]
·15，N，…(可变位)-TCP替换校验和数据。
(其余选项是过时的、实验的、尚未被标准化的或未分配的)
具有不同服务质量(QoS)的许多应用需要依赖于TCP，作为底层可靠的传输机制或者依赖于UDP作为底层低等待时间的传输机制：
-高吞吐量流送测量数据传输，其使用在单个TCP连接上具有在数十兆字节／秒的范围内的数据速率的应用特定汽车协议。
-使用UDP的用于环路中函数(FIL)原型使用情况的低等待时间和低抖动流送测量数据传输。
-使用TCP或UCP的基于交易的控制、校准和诊断服务，具有低等待时间需求以确保低交易往返时间。
-标准尽力TCP／IP服务，类似于http、ftp或终端模拟。
在许多情况下，这些应用共存于单个嵌入式采集设备上，并且每个应用特定且服务感知的汽车协议需要其自己的TCP连接。
TCP／IP主要是以软件实现的，并且在CPU的监管模式(核心空间)中作为操作系统服务而运行。然而，基于软件的协议实施方式主要遭受由于大量的情境切换和必须对每个接收或传送帧执行的工作量而引起的帧速率限制。对于具有有限CPU性能的小型嵌入式系统而言尤其如此，该小型嵌入式系统被连接到具有其非常高的帧速率的高吞吐量、低等待时间吉比特(Gigabit)以太网链路。
到目前为止在现有技术中已经提出了各种方法以便改善每个帧事件消耗的CPU处理功率的比。这些方法中最流行的是：
-卸载引擎
○卸载引擎尝试减少每个IP帧要执行的操作的数目，例如通过以硬件来计算报头和有效载荷校验和。
○这种方法减少了每个事件的处理功率的量，但是其并未减少用于软件的帧速率。过多情境切换的问题仍存在。
-中断节流(throttling)或中断串联
○通过将用于多个帧到达的处理串联成单个中断服务动作来减少情境切换的数目。
○中断节流很大地帮助减少每个时间单位的情境切换的数目。然而，由于其在链路层(以太网)水平上操作，所以其并不是服务感知的且向所有服务引入不期望的等待时间。
-巨型帧的使用
○巨型帧是具有通常达到9600字节而不是标准1518字节的扩展长度的以太网帧。这被认为通过允许较大TCP段尺寸而减少帧速率。
○巨型帧已被IEEE801.3标准化，并且很少在局域网(LAN)中使用且几乎不与TCP相结合地使用。其必须在链路的两端处被支持且并不保证通过每个以太网桥接的或IP路由的网络。TCP接收器甚至能够通过使用对应的TCP最大段尺寸选项来迫使具备巨型帧能力的TCP发送器发送较小TCP段。
-多核技术
○多核CPU上的并行分组处理相当可观地改善了计算机的遍及各处的分组吞吐量。
○这种技术仅在独立分组会话的情况下是有益的。类似于TCP连接的单个会话并不受益于多个核，因为这些核必须遵守分组序列，这最终导致多个核上的分组的串行化处理，这甚至变得更坏，因为会话在这些核之间跳跃；CPU核的层级1的利用进行高速缓冲且系统性能退化。
-独立TCP硬件实施方式(ASIC或FPGA IP)
○独立TCP硬件实施方式以硬件来提供完整、但单片的TCP／IP堆栈实施方式。此类实施方式通常示出了朝向包括地址解析协议(ARP)的链路层网络的TCP和IP功能的紧密集成。其提供朝向客户端层的简单流送数据接口和朝向连接管理的类似于套接字(socket)的控制接口。
○客户端层数据按值通过这些部件。为了处理合理数目的TCP连接，硬件实施方式中的独立TCP要求足够的私有数据存储和对应的缓冲器管理以用于重传和重新排序缓冲器。由于数据存储和缓冲器管理在外部是不可访问的，所以任何服务感知客户端层(例如，以太网上的XCP)必需实现其自己的缓冲方案。这导致增加的存储器需求。高比特触发率(toggle rate)导致高系统功耗。TCP、IP和ARP到单片部件的紧密集成使得基于硬件和基于软件的分组业务量的复用和解复用变得复杂。
客户端层是若干应用层中的一个，在那里，用户访问应用。应用可以要求任何类型的客户端。例如，ECU与设备(例如，嵌入式采集设备)之间的数据通信在客户端层中执行。传输层为网络部件和协议的分层架构内的应用提供端对端通信服务。例如，设备(例如，嵌入式采集设备)与外部个人计算机之间的数据通信在传输层中执行。
标准化传输控制协议(TCP)是ECU与MCD应用软件之间的测量、校准和诊断(MCD)数据的可靠传输所需的接口模块中的核心部件。利用具有必要地受限的CPU性能的常规嵌入式ECU接口模块中的基于软件的传输功能的当前范例，不能满足即将到来的客 户数据吞吐量要求。相同的限制将适用于具有汽车以太网引入的ECU本身。
用于TCP加速的可用解决方案的讨论表明了这些解决方案中没有一个解决了嵌入式汽车采集设备的硬件中特定TCP的问题。因此，本发明的目的是提供通信系统的客户端层和／或传输层中的任何两个设备之间的快速且可靠的数据传输，其中，数据传输是根据TCP执行的。特别地，本发明的目的是提供汽车ECU与例如在个人计算机上运行的开发软件工具之间的快速且可靠的MCD数据传输。
发明内容
由根据权利要求1的方法、由根据权利要求7的通信系统以及由根据权利要求11的嵌入式采集设备来解决此目的。
特别地，提出了一种用于在通信系统的客户端层和／或传输层中的任何两个设备之间传送数据的方法。数据传输是根据在下文中称为TCP的传输控制协议来执行的。该方法的特征在于要传送的数据被缓冲在中央存储装置中，并且TCP协议操作块处理对存储在存储装置中的已传输数据的参考而不是数据本身。
此外，提出了适合于在通信系统的客户端层和／或传输层中的任何两个设备之间传送数据的通信系统。该数据传输是根据在下文中称为TCP的传输控制协议来执行的。该通信系统的特征在于其包括用于缓冲要传送的数据的中央存储装置和适合于处理对存储在存储装置中的已传输数据的参考而不是数据本身的TCP协议操作块。
最后，提出了位于通信系统的任何两个设备之间的嵌入式采集设备，在两个设备之间，在通信系统的客户端层和／或传输层中传送数据。该采集设备适合于根据在下文中称为TCP的传输控制协议来执行数据传输。该采集设备的特征在于其包括适合于处理对被缓冲在通信系统的中央存储装置中的要传送数据的参考而不是数据本身的TCP协议操作块。
在本专利申请中，以其最广泛意义来使用术语“传送”、“传输”和“已传送”，包括两个方向上的数据传输，亦即包括第一方向上的数据(或帧)的发送和相反方向上的数据(或帧)的接收。
根据本发明的优选实施例，在通信系统中在一方面的汽车电子控制单元与另一方面的在外部个人计算机上运行的汽车开发软件工具之间传送测量、校准和诊断数据。数据传输是跨TCP采集设备执行的，该TCP采集设备处理对要传送的数据的参考，该数据被缓冲在通信系统的中央存储装置中。
进一步的从属权利要求包括本发明的有利实施例。在以下描述中详细地描述其优点。
在本发明中呈现的解决方案实现了吉比特以太网链路上的线速TCP吞吐量并克服了与小型嵌入式系统相关联的特定限制。提出的TCP协议端接(termination)完全是以硬件实现的，因此将其称为TCPHW(以硬件的TCP)。该设计是基于以下基本思想和范例：
-客户端层有效载荷的分段
○客户端层有效载荷被分段成有限尺寸的数据块。不同客户端层的数据块被交织，允许多个客户端层利用朝向TCPHW的单个多信道数据接口。这简化了处理当前用于多个客户端层应用的多个连接的虚拟并行工作TCP协议引擎的实施方式。
-网络层有效载荷的分段
○网络层(IP)和链路层(以太网)帧也被分段成有限尺寸的数据块。由TCPHW端接的连接和以软件堆栈端接的其他连接能够容易地利用朝向网络的同一多信道接口。
-分组的同时协议处理
○将客户端和网络有效载荷段串行化简化了用于多个连接的同时协议处理。通过使用过采样技术以时间复用方式来处理属于不同连接的各段。
○通过实现硬件支持以节省处理状态，能够消除情境切换开销。该设计确保处理功率在任何时间立即可用于每个接收分组。
○由于每个段和分组事件被立即处理，所以避免了事件节流和关联的等待时间。
-对数据参考而不是数据本身起作用
○TCP端点经由TCP序列号进行通信，该TCP序列号能够容易地从数据段长度指示符得到；对于TCP功能而言不需要靠其自己来对有效载荷字节进行计数。
○重传和重新排序缓冲器存储数据参考而不是数据值。例如，对128或256字节尺寸的段使用8字节描述符将数据存储的量减少至达到1／32。这使得能够使用内部FPGA RAM来实现用于多个TCP实例的套接字缓冲器，这节省了相当可观的处理性能和功率。
○利用数据参考而不是数据值的传输，大大地降低了接口上的位触发率。对于具有高引脚容量的外部接口而言尤其如此。
-与网络层的隔离
○将TCP功能与UDP、IP和ARP功能隔离。
○TCP实现变得更加轻质并避免了朝向链路层的分组复用的多个级。这简化了硬件和软件堆栈的共存。
附图说明
下文参考附图来更详细地描述本发明的优选实施例。本发明不一定包括下文所讨论 的所有特征和优点或参考优选实施例所描述的特征的组合。而是，本发明也可以仅仅包括以任何期望的组合所描述的特征中的一个或多个所选的特征。附图示出：
图1从现有技术获知的以硬件解决方案的标准TCP，
图2根据本发明的以硬件解决方案的TCP，
图3在根据本发明的解决方案中实现的以硬件部件的集成TCP
图4重传缓冲器的逻辑结构的实施例，
图5重新排序缓冲器的逻辑结构的实施例，
图6与硬件数据平面(硬件处理器)相结合的根据本发明的以硬件解决方案的TCP，以及
图7 TCP报头的格式。
具体实施方式
图1示出了从现有技术获知的按照硬件解决方案的标准TCP。特别地，示出了具有硬件部件2中的独立TCP的嵌入式采集设备1的系统概览。这种解决方案能够被实现为ASIC或FPGA IP。已知解决方案提供了以硬件的完整而单片的TCP／IP堆栈实施方式。此类实施方式通常示出朝向包括地址解析协议(ARP)的链路层网络的TCP和IP功能的紧密集成。其提供朝向客户端层的简单流送数据接口和朝向连接管理的类似于套接字的控制接口。然而，客户端层数据按值通过这些部件，亦即处理实际原始数据。为了处理合理数目的TCP连接，以硬件实施方式的独立TCP要求足够的私有数据存储(例如，套接字缓冲器3)和用于重传和重新排序缓冲器的对应缓冲器管理。由于数据存储3和缓冲器管理在外部是不可访问的，所以任何服务感知客户端层(例如，以太网上的XCP)必须实现其自己的缓冲方案。这导致增加的存储器需求。高的位触发率导致高的系统功耗。TCP、IP和ARP到单片部件中的紧密集成使基于硬件和基于软件的分组业务量的复用和解复用变得复杂。
在图1中，参考标号4指示客户端层复用器／解复用器，并且参考标号5指示分组复用器／解复用器。参考标号6指示硬件部件中的TCP与用于TCP的客户端层复用器／解复用器4中的一个之间的高吞吐量服务，并且参考标号7指示硬件部件2中的TCP与用于UDP的客户端层复用器／解复用器中的一个之间的低等待时间服务。
在图2中示出了根据本发明的解决方案的优选实施例。其实现了吉比特以太网链路上的线速TCP吞吐量并克服了与小型嵌入式系统相关联的特定限制。提出的TCP协议端接完全是以硬件实现的，因此将其称为TCPHW(以硬件的TCP)。该设计是基于以下基本思想和范例：
-客户端层有效载荷的分段
-网络层有效载荷的分段
-分组的同时协议处理
-对数据参考而不是数据本身进行操作
-来自UDP、IP和ARP功能的与网络层的隔离。
在图2中，参考标号4指示客户端层复用器／解复用器，并且参考标号11指示多层复用器／解复用器。由参考标号10来指定根据本发明的TCPHW部件(嵌入式采集设备)。参考标号6指示TCPHW部件10与客户端层复用器／解复用器4之间的高吞吐量服务，并且参考标号7指示汽车协议数据块与多层复用器／解复用器11之间的低等待时间服务。参考标号12指示中央缓冲器，其跨越所有通信层被共用并用于存储实际原始数据。本发明的中央缓冲器12替换图1的现有技术中的套接字缓冲器3和多个客户端缓冲器。本发明的TCPHW部件10仅操纵和处理对存储在中央缓冲器12中的数据的参考而不是实际原始数据。将该实际原始数据在IP／UDP与以太网媒体接入块与中央缓冲器12之间直接交换而不曾到达TCPHW部件10。图2的功能块之间的虚线指示按引用具有低触发率的接口。功能块之间的连续线指示按值具有低触发率的接口。最后，功能块之间的粗线指示按值具有高触发率的接口。
本发明通过将基于软件的协议实施方式的从前范例朝着并行化的基于硬件的传输功能的后续实施方式进行改变来解决现有技术问题。本发明描述了用于将轻质、可缩放且高性能的纯基于硬件的TCP部件集成到甚至支持汽车以太网的ECU8中的方法和原理。这些原理和方法是与市场上的以硬件解决方案的少数可用、重质TCP(它们中没有一个满足嵌入式汽车设备的特殊要求)的关键差别。
传输控制协议(TCP)满足用于嵌入式ECU接口设备与运行测量应用软件工具9、例如来自ETAS GmbH的INCA的成品个人计算机(PC)之间的测量、校准和诊断(MCD)数据的可靠传输的客户要求。
在现有技术中，由底层操作系统软件来提供TCP协议功能，该底层操作系统软件是来自Research ln Motion公司(RIM)的或PC内的Microsoft 的嵌入式设备内的Embedded Linux。
用于下一代汽车ECU8的测量应用请求至少30M字节／s或者甚至更高的测量数据传输速率。要求低等待时间和低抖动原型应用共存。
已经发现数据吞吐量中相对于当前解决方案的达到5至10倍的此类增加只能通过从软件完全去除帧速率感知并通过以硬件实现协议堆栈来实现。
以硬件解决方案的可用TCP已经被调查具有以下结果：
-来自韩国WIZNET的唯一现有ASIC解决方案(最大12.5Mbyts／秒)既不支持也不具有用于吉比特以太网的路线图(roadmap)且一直缺少第二源。
-以硬件解决方案的所有现有基于FPGA的TCP是要求TCP私有数据缓冲的独立的实施方式，这增加了相当可观的复杂性、成本和功耗。它们中没有一个提供了用于在客户端或网络侧上的服务复用的扩展支持。所支持连接的量过高或过低。某些实施方式一直缺少特征或者甚至是不服从标准的。不能控制可缩放性。
本发明通过植入以下特征中的一个或多个来克服这些限制：
-使用与客户端和网络层侧复用器的共享单个数据缓冲器，降低功耗和成本。
-提供达到125Mbyts／秒的线速性能。
-通过对数据指针而不是原始数据进行操作进一步减少了功耗，这将系统的触发率减小至达到1／16。
-提供了用于较高层(客户端侧)协议与较低层(网络侧)协议之间的以硬件解决方案的TCP的无缝集成的手段。
-不增加等待时间或针对原型应用的抖动。
-允许基于硬件和软件的协议堆栈的共存。
-可控可缩放性。
本发明集中于能够实现以硬件实施方式的最优TCP的集成方法和原理。TCP功能的内部构件是在外部开发的，并且因此不是本发明的一部分。
在图3中示出了硬件(TCPHW)部件10中的TCP。部件10执行服从标准的TCP协议操作。其使用下面的良好定义的接口连接到数据平面的客户端层20和网络层21并连接到控制平面：
-客户端层接口27
-网络层接口28
-控制接口29
-描述符库接口30
这些接口由以下主要构建块所服务：
-具有重传缓冲器23的TCP发送器22
-具有重新排序缓冲器25的TCP接收器24，以及
-控制26
构建块由以下内部接口所互连：
-命令／状态接口cmdstat
-TCP连接接口tcpcon。
描述符是用于传输和存储对外部数据缓冲器(例如中央缓冲器12)的参考的容器。每个描述符描述有限尺寸的单个客户端或网络层数据段。其承载以下信息：
-缓冲器索引
○到外部数据缓冲器的用户定义索引。TCP透明地传输此信息。
-段的长度
○包含在此段中的有效数据的长度。TCP使用此信息来计算TCP序列号。
-段内偏移
○指向缓冲器内的第一有效的有效载荷的偏移。TCP透明地传输此信息。
-扩展字的长度
○用户定义扩展字的长度。TCP透明地传输此信息。
-扩展字
○客户端或网络层定义扩展字。TCP透明地传输此信息。
在下文中，详细地描述了外部接口。
客户端层接口27是将TCPHW10的n个TCP功能(连接)与客户端层相连接的双向多信道接口。其包括客户端层传送接口27.1和客户端层接收接口27.2。接口27以描述符的形式将客户端有效载荷载送至有限尺寸的数据段。每个信道表示独立操作的TCP连接并基于每个段与其他信道交织。
客户端层接口27是主／从接口。TCPHW10是从件。
TCP发送器22被允许基于每个信道从客户端层接收接口27.2对压业务量进行反压(backpressure)。反压可能由于不同的原因而变得活动：
-近端发送器的传送窗口关闭，因为由于丢失的帧而未接收到确认。
-远端接收器关闭TCP窗口，因为接收数据未被远端客户端层所处理。
-TCP连接由于与以太网外出接口上的其他服务或连接的竞争而减慢。
-TCP连接降低其内部处理速度。
TCP接收器24必须通过不清空其重新排序缓冲器25并减小向远端TCP发送器通告的接收窗口尺寸来遵守由客户端层所主张的反压。
网络层接口28是将TCPHW10的n个TCP功能(连接)与网络层的IP和以太网接 口相连接的双向多信道接口。其包括网络层传送接口28.1和网络层接收接口28.2。接口28按引用进行操作，将以描述符形式的TCP段有效载荷载送至有限尺寸的数据段。每个信道表示独立操作的TCP连接且基于每个段与其他信道交织。TCP业务量按IP地址和端口号以及到信道的连接映射的分段和分类是在TCPHW部件10外面完成的。
要注意的是，TCPHW10将从客户端层(通过客户端层接口27)接收到的各段在没有任何改变(亦即不对其进行处理)的情况下传递至网络层(通过网络层接口28)。
将TCP段的有效载荷按引用传输。TCP段的报头(TCP协议报头)由TCP协议功能生成或消耗且必须按值传输。
网络层接口28是主／从接口，其中TCPHW10充当从件。要注意的是，这与独立实施方式(参见图1)不同，其中，IP层被紧密地联系到TCP层并充当朝向链路层MAC从件的主件。
TCP发送器22必须基于每个信道遵守由网络层所主张的反压。
TCP接收器24被允许每个信道或通常针对所有信道主张朝向网络层的反压。为了避免多个流量控制机制(具有以太网PAUSE帧的链路层流量控制、网络层接口反压和TCP端对端流量控制)之间的干扰，推荐不依赖于网络层接收接口28.2反压。TCPHW10必须足够快以便以线速接受来自网络层接口28的任何数据。
控制接口29是到软件的存储器映射寄存器接口。其提供以下服务：
-激活／去激活(全局)
○软件将完整的TCPHW10全局地激活或去激活。默认值：去激活。
-重置(全局)
○软件将运行中的TCPHW10重置成其上电状态。所有寄存器被加载有其默认值。
-本地TCP端口配置(每连接)
○针对给定链接设置本地TCP／IP端口。
-远程TCP端口配置(每连接)
○主动打开(客户端)：设置远程TCP端口号；
○被动打开(服务器)：获得远程TCP端口号。
-向TCP协议引擎的命令(每连接)
○软件向TCPHW发送以下命令中的一个：
·“被动打开”：将TCP状态机置于LISTEN状态中
·“主动打开”：将TCP状态机置于SYN_SENT状态中
·“关闭”：本地关闭连接；导致向FIN_WAIT1、CLOSE_WAIT或LAST_ACK的过渡
·“删除Tcb”：立即将连接重置并将本地TCP状态机转移至CLOSED状态。如果连接尚未处于CLOSED或TIME_WAIT状态，则此动作还向远程主机发送TCP_RST控制。
○明确地向软件确认命令。
-来自TCP协议引擎的状态(每连接)
○软件读取用于每个连接的当前状态。可能状态是：CLOSED、LISTEN、SYN_RCVD、SYN_SENT、ESTABLISHED、CLOSE_WAIT、LAST_ACK、FIN_WAIT1、FIN_WAIT2、CLOSING、TIME_WAIT。
-最大发送段尺寸(每连接)
○软件设置每连接的TCP发送段的最大尺寸。默认值：356字节。
-最大接收段尺寸(每连接)
○软件设置每连接的TCP接收段的最大尺寸。将此值在连接建立期间向远端通告。默认值：1480字节。
-启用／禁用Nagle算法(每连接)、
○软件在给定连接上禁用Nagle算法。默认值：启用。
-配置延迟确认算法(每连接)
○两个值被软件用来控制延迟确认算法：
·确认计数(每连接)定义在发送即时确认之前必须已经接收到的段数。
·最大延迟(每连接)定义发送器必须等待确认的最大延迟。
-通知和中断
○TCPHW使用中断向软件发送以下异步通知：
·由于远程主机控制而改变的TCP状态
·由于定时器事件而改变的TCP状态
·远程TCP发送FIN
·远程TCP发送RST
·缓慢重传定时器引起的重传
·快速重传被触发。
缓冲器描述符接口30(或描述符库接口)：TCP发送器22必须存储描述符直至对应段已被远端接收器所确认。一旦已经接收到确认，则TCP发送器22经由接口30向外部描 述符库返回与已确认段相关联的描述符(参考)。
另一方面，TCP接收器24不可向客户端层输送任何TCP内容两次。因此，必须通过将关联描述符返回至外部描述符库来释放每个复制的接收TCP段。
要注意的是，TCP接收器24和TCP发送器22都不曾从该库分配描述符。
在任何情况下，当连接被近端或远端所关闭时，与该连接相关联的所有描述符必须被返回至外部描述符库。
缓冲器描述符接口30是简单的同步握手接口，其提供单个服务“自由缓冲器”，具有两个关联参数：缓冲器库和该库内的缓冲器索引。
TCPHW部件10由三个主构建块组成：
-TCP发送器22和重传缓冲器23，
-TCP接收器24和重新排序缓冲器25，以及
-控制26。
下文给出这些构建块的短黑框描述。这些构建块的详细内部设计不在本发明的范围内。然而，定义了外部接口27-30，并且上文已讨论了用于实现的基本方针。
TCP发送器22和重传缓冲器23：TCP发送器22根据IETF（互联网工程任务组）标准来执行用于多个连接的标准TCP协议处理。连接同时地运行。TCP发送器22保持用于每个连接的重传缓冲器23。此缓冲器23被设计成存储TCP段。每个TCP段由对位于外部数据存储器（例如中央缓冲器12）中的数据缓冲器的参考列表组成，该外部数据存储器（例如中央缓冲器12）不是TCPHW 10的一部分。这些参考源自于客户端层且被封装在如上所描述的描述符结构中。
如图4中所示的重传缓冲器23具有三个基本区：
—自由缓冲器40（用连续线加阴影），其尚未被客户端层填充，
—已占用缓冲器41（带点的），TCP段已被发送并等待由远端TCP接收器进行确认。这些TCP段被保持直至重传或被确认。TCP发送器变量expectedSN标记此区的开始。将ExpectedSN用每个接收到的新确认序列号更新。已确认TCP段将其色彩从“带点的”改变成“用连续线加阴影”并变为自由缓冲器。必须使用描述符库接口将与TCP段相关联的所有参考尽可能快地返回至外部描述符库以用于稍后重新使用。
—已占用缓冲器42（用虚线加阴影），具有被允许发送的数据（如果可用的话）。此区的开始由TCP发送器变量nextSN来标记。NextSN在已经将TCP段朝着网络层发送之后增量。TCP段的色彩从“用虚线加阴影”改变成“带点的”。属于对应TCP段的所有参考现在为TCPHW所拥有，直至其被确认并释放。
图4示出了重传缓冲器23的逻辑结构。缓冲器23条目由TCP序列号编所索引。TCP发送器22通过添加在来自客户端层的描述符内所接收到的长度指示符直至达到或几乎达到TCP段的最大段尺寸MMS来构造序列号。详细行为取决于Nagle算法设置。如果此算法被开启，则如上所描述地收集数据。如果其被关闭，则TCP发送器根据其速度可以或可以不将客户端数据收集到TCP段中。
要注意的是，也许不可能最佳地填充TCP段，因为添加下一接收客户端层段Si的长度可能超过最大段尺寸MMS。然而，客户端层可以将段Si虚拟地分成子段Si1和Si2。两个子段都承载相同的缓冲器索引，但是使用到同一外部数据缓冲器（例如中央缓冲器12）中的不同偏移。
重传缓冲器23的物理尺寸必须足够大以保持用于可用TCP窗口尺寸的充足的数据参考，该可用TCP窗口尺寸从0至min（cwnd、rwnd）的范围变动，其中，cwnd是TCP拥挤窗口，并且rwnd表示从远端TCP接收器通告的接收窗口尺寸。
假设具有低误码率的无拥挤、小型局域网，要支持的最小重传缓冲器尺寸由相对小的往返时间RTT和TCP连接的期望保持吞吐量R所支配：
示例：
其中R=（30至125）M字节/s，RTT=（0.5至1）ms，必定支持Beff=（15至125）k字节的缓冲器尺寸。
对物理描述符存储器的需求取决于TCP层的最大段尺寸mss和客户端层的最小段长度msl。
其中，k是描述符的尺寸。注意到，k的值从TCP段到TCP段不同。分段由客户端层所执行。
示例：
其中mss=1460 字节，msl=（64至256）字节且k=64位，用于参考的物理存储器对于有效缓冲器尺寸的以上计算范围而言从480至16000字节的范围变动。能够实现达到1/24的相当可观的减小。
TCP接收器24和重新排序缓冲器25：TCP接收器24根据IETF标准来执行用于多个连接的标准TCP协议处理。连接同时地运行。TCP接收器24保持用于每个连接的重新排序缓冲器25。此缓冲器被设计成存储TCP段。每个TCP段由对位于外部数据存储器（例如中央缓冲器12）中的数据缓冲器的参考列表组成，该外部数据存储器（例如中央缓冲器12）不是TCPHW10的一部分。这些参考源自于网络层且被封装在如上所描述的描述符结构中。
图5中所示的重新排序缓冲器25具有三个基本区：
-自由缓冲器50(用连续线加阴影)，其超过定义的接收套接字缓冲器尺寸且其通常将不被使用。
-已占用缓冲器51(带点的)，具有已接收的TCP段。数据尚未被客户端层消耗。此缓冲器51包含等待由客户端进行消耗的段。这些TCP段被保持直至重新排序完成。读指针oldSN标记此区51的开始。其在客户端层读取数据时前进，将段色彩改变成“用连续线加阴影”。
-自由缓冲器52(用虚线加阴影)，用以从网络接收新数据。写指针newSN标记此区的开始。其在从网络层接收到TCP段时增量，将段色彩从“用点线加阴影”改变成“带点的”。
帧的记录在“带点的”区中发生。只有当在当前和下一可能位置之间不存在遗漏序列号时，读指针oldSN才前进。
图5示出了重新排序缓冲器25的逻辑结构。缓冲器25条目由TCP序列号所寻址。该序列号在按值传输的TCP报头中被接收。
在进入TCP接收器之前，TCP段被分成有限尺寸的数据块。对对应外部数据存储器(例如中央缓冲器12)的参考被封装在描述符中。
重新排序缓冲器25的尺寸必须足够大以存储与最大接收窗口尺寸(接收套接字缓冲器尺寸)匹配的参考。接收窗口尺寸是“用虚线加阴影的”区的尺寸。
假设用于达到例如64位的128或512个描述符的TCT端接网络业务量的(16至64)k字节的接收窗口(套接字缓冲器)尺寸和128字节的典型段长度，每个必须被存储在重新排序缓冲器25中，其导致1至4k字节物理描述符存储空间。
控制构建块提供到软件的基于寄存器的编程接口。软件控制的寄存器输出TCP发送器和TCP接收器功能中的控制特定功能，例如重置、输出连接的发起或输入连接的通知和错误信令。
还提供了用以从TCPHW数据平面功能(TCP发送器和TCP接收器)收集统计值的接口。为了在完全相同的时间捕捉一致的一组统计值，软件首先通过设置适当的寄存器条目来发起捕捉循环。控制功能将此命令作为捕捉脉冲分布到数据平面功能中。数据平面功能使用此捕捉脉冲将运行中的计数器值捕捉到经由控制功能对软件可见的对应阴影寄存器中。
内部接口包括命令状态接口cmdstat和TCP连接接口tcpcon。命令状态接口cmdstat在控制功能的控制寄存器与TCP发送器和接收器之间载送命令和状态信息。其还提供如上所描述的用于捕捉一致的一组统计值的手段。TCP连接接口tcpcon载送所有本地发送器／接收器信息：
-从接收器到发送器的接收确认序列号
-从接收器到发送器的接收窗口尺寸通告
-实现涉及TCP发送器和TCP接收器两者的分布式TCP连接状态机所需的信息。
图6示出了TCPHW部件10如何在TCP发送方向上与多层硬件数据平面(数据处理器)相互作用。多层硬件数据平面在图2中所示的TCPHW部件10上面和下面执行客户端侧和网络侧复用功能。图2的客户端侧复用是在第一处理路径(路径1)中完成的且图2的多层复用功能是在第二处理路径(路径2)中完成的。
在TCP处理之前将实际客户端数据EARLY写入中央缓冲器12中并在TCP处理之后从中央缓冲器12读取LATE。
对指针(=描述符)而不是对数据本身执行复用和TCP协议处理。在图6中，参考标号60指定应用节点。参考标号61指示ECU接口模块和传输节点且参考标号62指示模拟节点。此外，在图6中，具有连续线的箭头指示数据传输，例如每个时间间隔T128字节，例如128字节／0.2μs=640M字节／s。具有虚线的箭头指示指针处理，例如每个时间间隔T(8…10)个字节，例如8字节／0.2μs=40M字节／s。这导致处理速率降低至1／16。
最后，我们提出了本发明所基于的一列关键思想。根据本发明的TCPHW包括这些关键思想中的一个或多个。
-跨越所有通信层的数据缓冲器的共用
○其他已知解决方案实现用于TCP的专用缓冲器管理
○节省成本和功耗
-TCP传输层与网络层(IP)的隔离
○其他已知解决方案将以HW的TCP紧密地绑定于网络(IP)层和链路(以太网)层。
○启用／简化硬件和软件协议堆栈的共存
○启用／简化在公共网络层的顶部上的不同传输层的共存
-对数据的参考而不是原始数据本身的操作
○其他已知解决方案随每个数据字节触发
○将逻辑触发率减小至达到1／16(随数据段触发)
-客户端层和网络层帧的分段
○其他已知解决方案对较大数据块(帧)进行操作，导致较高的抖动非TCP实时业务量
○系统抖动的减少
-TCP重传和重新排序缓冲器通过存储对已传输数据的参考而不是数据本身而缩小
○其他已知解决方案存储原始数据
○通过更有效地利用专用资源来节省存储器
-合作(串行化)接口
○简化多个实例的合作实现
-由多个协议层所使用的外部描述符库的使用
○通过与其他功能共享资源来节省存储器
-基于长度指示符而不是对数据长度进行计数的序列号管理
○对于客户端协议实现的较高的透明度
-用于最佳TCP段利用的可选客户端层子分段。

Claims (12)

1.一种用于在通信系统的应用层和/或传输层中在任何两个设备之间传送数据的方法，其中，根据传输控制协议TCP来执行数据传输，以及其中所述通信系统进一步包括中央存储装置（12）和TCP协议操作块（10），其特征在于，要传送的数据被缓冲在中央存储装置（12）中，并且TCP协议操作块（10）处理对存储在中央存储装置（12）中的已传输数据的参考而不是数据本身，其中所述TCP协议操作块（10）不处理实际原始数据以及其中所述TCP协议操作块（10）包括重传缓冲器（23），并且将对已传输数据的参考而不是数据本身存储在重传缓冲器（23）中，其中所述重传缓冲器（23）存储TCP段，以及其中每个TCP段由对位于所述中央存储装置（12）中的数据缓冲器的参考列表组成。
2.根据权利要求1所述的方法，其特征在于在通信系统中的汽车电子控制单元（8）与在外部个人计算机上运行的汽车开发软件工具（9）之间传送测量、校准和诊断数据。
3.根据权利要求1或2所述的方法，其特征在于跨越所有通信层使用中央存储装置（12）。
4.根据权利要求1或2所述的方法，其特征在于以数据帧来传送数据，并且应用层帧和网络层帧在传送之前被分段成较小数据块。
5.根据权利要求1或2所述的方法，其特征在于TCP协议操作块（10）包括重新排序缓冲器（25），并且将对已传输数据的参考而不是数据本身存储在重新排序缓冲器（25）中。
6.一种适合于在通信系统的应用层和/或传输层中在任何两个设备之间传送数据的通信系统，其中，根据传输控制协议TCP来执行数据传输，以及其中所述通信系统进一步包括中央存储装置（12）和TCP协议操作块（10），其特征在于该通信系统包括用于缓冲要传送的数据的中央存储装置（12）和适合于处理对存储在中央存储装置（12）中的已传输数据的参考而不是数据本身的TCP协议操作块（10），其中所述TCP协议操作块（10）不处理实际原始数据以及其中所述TCP协议操作块（10）包括重传缓冲器（23），并且将对已传输数据的参考而不是数据本身存储在重传缓冲器（23）中，其中所述重传缓冲器（23）存储TCP段，以及其中每个TCP段由对位于所述中央存储装置（12）中的数据缓冲器的参考列表组成。
7.根据权利要求6所述的通信系统，其特征在于在通信系统中的汽车电子控制单元（8）与在外部个人计算机上运行的汽车开发软件工具（9）之间传送测量、校准和诊断数据。
8.根据权利要求7所述的通信系统，其特征在于所述通信系统包括位于所述汽车电子控制单元（8）与所述汽车开发软件工具（9）之间的嵌入式采集设备（1）且所述TCP协议操作块（10）是所述嵌入式采集设备（1）的一部分。
9.根据权利要求7或8所述的通信系统，其特征在于通信系统包括适合于执行权利要求3至5中的任一项所述的方法的装置。
10.一种位于通信系统的任何两个设备之间的嵌入式采集设备（1），在所述两个设备之间，在通信系统的应用层和/或传输层中传送数据，其中，所述嵌入式采集设备（1）适合于根据传输控制协议TCP来执行数据传输，其特征在于所述嵌入式采集设备（1）包括适合于处理对缓冲在通信系统的中央存储装置（12）中的要传送的数据的参考而不是数据本身的TCP协议操作块（10），其中所述TCP协议操作块（10）不处理实际原始数据以及其中所述TCP协议操作块（10）包括重传缓冲器（23），并且将对已传输数据的参考而不是数据本身存储在重传缓冲器（23）中，其中所述重传缓冲器（23）存储TCP段，以及其中每个TCP段由对位于所述中央存储装置（12）中的数据缓冲器的参考列表组成。
11.根据权利要求10所述的嵌入式采集设备（1），其特征在于在通信系统中传送校准和诊断数据，并且所述嵌入式采集设备（1）位于汽车电子控制单元（8）与在外部个人计算机上运行的汽车开发软件工具（9）之间。
12.根据权利要求10或11所述的嵌入式采集设备（1），其特征在于所述嵌入式采集设备（1）包括用于执行权利要求3至5中的任一项所述的方法的装置。
CN201310481321.3A 2012-10-16 2013-10-15 用于具有tcp加速的嵌入式汽车采集设备的分布式测量装置 Active CN103731409B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP12188660.0A EP2723031B1 (en) 2012-10-16 2012-10-16 Distributed measurement arrangement for an embedded automotive acquisition device with tcp acceleration
EP12188660.0 2012-10-16

Publications (2)

Publication Number Publication Date
CN103731409A CN103731409A (zh) 2014-04-16
CN103731409B true CN103731409B (zh) 2019-10-15

Family

ID=47189720

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201310481321.3A Active CN103731409B (zh) 2012-10-16 2013-10-15 用于具有tcp加速的嵌入式汽车采集设备的分布式测量装置

Country Status (7)

Country Link
US (1) US10440157B2 (zh)
EP (1) EP2723031B1 (zh)
KR (1) KR20140048815A (zh)
CN (1) CN103731409B (zh)
FR (1) FR2996976B1 (zh)
IT (1) ITMI20131676A1 (zh)
RU (1) RU2013145968A (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101536141B1 (ko) * 2014-02-13 2015-07-13 현대자동차주식회사 이더넷과 can 통신 간의 신호 변환을 제공하는 차량용 장치 및 그 제어방법
US10630749B2 (en) 2015-08-14 2020-04-21 Cisco Technology, Inc. Timely delivery of real-time media problem when TCP must be used
US9854070B2 (en) 2015-11-13 2017-12-26 International Business Machines Corporation Transmission control protocol (TCP) data handling
US10320911B2 (en) * 2017-07-11 2019-06-11 GM Global Technology Operations LLC Vehicle network implementing XCP protocol policy and method
CN108521416B (zh) * 2018-03-30 2021-02-02 上海仁童电子科技有限公司 一种ecn板卡
CN111464411B (zh) * 2020-03-31 2022-09-20 潍柴动力股份有限公司 车载终端采集数据的配置方法及装置
US11799986B2 (en) * 2020-09-22 2023-10-24 Apple Inc. Methods and apparatus for thread level execution in non-kernel space
CN113242253B (zh) * 2021-05-21 2023-05-12 南京艾科朗克信息科技有限公司 一种证券行情侦听方式下的快速处理方法
KR20240030757A (ko) * 2022-08-31 2024-03-07 삼성전자주식회사 셀룰러 통신 시스템에서 응용 성능을 위한 응용 계층 정보/전송 계층 정보 전달 방법 및 장치

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101783941A (zh) * 2009-09-15 2010-07-21 上海海事大学 一种基于ip网络的实时视频传输方法
CN102098734A (zh) * 2009-12-15 2011-06-15 英特尔公司 用于管理不同种类业务流的技术

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI109508B (fi) * 1999-09-28 2002-08-15 Nokia Corp Menetelmä Abis-rajapinnan transmissiokanavien allokoimiseksi pakettisolukkoradioverkossa ja pakettisolukkoradioverkon verkko-osa
US7313600B1 (en) * 2000-11-30 2007-12-25 Cisco Technology, Inc. Arrangement for emulating an unlimited number of IP devices without assignment of IP addresses
KR20030080443A (ko) * 2002-04-08 2003-10-17 (주) 위즈네트 하드웨어 프로토콜 프로세싱 로직으로 구현된 인터넷 통신프로토콜 장치 및 상기 장치를 통한 데이터 병렬 처리 방법
US7515612B1 (en) * 2002-07-19 2009-04-07 Qlogic, Corporation Method and system for processing network data packets
US20040198466A1 (en) * 2003-01-10 2004-10-07 James Walby Telematics device and method of operation
US7185209B2 (en) * 2003-05-28 2007-02-27 Microsoft Corporation End-to-end reliable messaging with complete acknowledgement
US7200695B2 (en) * 2003-09-15 2007-04-03 Intel Corporation Method, system, and program for processing packets utilizing descriptors
US7643480B2 (en) * 2004-01-22 2010-01-05 Hain-Ching Liu Method and system for reliably and efficiently transporting data over a network
US7818563B1 (en) * 2004-06-04 2010-10-19 Advanced Micro Devices, Inc. Method to maximize hardware utilization in flow-thru IPsec processing
US7752670B2 (en) * 2004-09-23 2010-07-06 Xiangrong Cai Detecting an attack of a network connection
US7770088B2 (en) * 2005-12-02 2010-08-03 Intel Corporation Techniques to transmit network protocol units
US20070140281A1 (en) * 2005-12-16 2007-06-21 Elite Silicon Technology, Inc. Network communication apparatus with shared buffers
US20080256271A1 (en) * 2006-12-12 2008-10-16 Breed Paul T Methods and apparatus for reducing storage usage in devices
WO2008073493A2 (en) * 2006-12-12 2008-06-19 Netburner, Inc. Methods and apparatus for reducing storage usage in devices
WO2008076017A1 (en) * 2006-12-18 2008-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Scheduling and queue management with adaptive queue latency
US7593331B2 (en) * 2007-01-17 2009-09-22 Cisco Technology, Inc. Enhancing transmission reliability of monitored data
US20080256323A1 (en) * 2007-04-09 2008-10-16 Hewlett-Packard Development Company, L.P. Reconfiguring a Storage Area Network
US20080263171A1 (en) * 2007-04-19 2008-10-23 Alacritech, Inc. Peripheral device that DMAS the same data to different locations in a computer
JP4623156B2 (ja) * 2008-07-25 2011-02-02 トヨタ自動車株式会社 車両情報記録システム、車両情報記録装置、車両情報記録方法
US20100183024A1 (en) * 2009-01-21 2010-07-22 Brocade Communications Systems, Inc Simplified rdma over ethernet and fibre channel
EP2287691A1 (de) * 2009-08-11 2011-02-23 Deutsche Telekom AG Vorrichtung zum Zugriff auf elektronische Fahrzeugkomponenten
JP5362668B2 (ja) * 2010-09-16 2013-12-11 日立オートモティブシステムズ株式会社 車内データ中継装置
US9203728B2 (en) * 2011-03-09 2015-12-01 lxia Metadata capture for testing TCP connections
US20140237156A1 (en) * 2012-10-25 2014-08-21 Plx Technology, Inc. Multi-path id routing in a pcie express fabric environment

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101783941A (zh) * 2009-09-15 2010-07-21 上海海事大学 一种基于ip网络的实时视频传输方法
CN102098734A (zh) * 2009-12-15 2011-06-15 英特尔公司 用于管理不同种类业务流的技术

Also Published As

Publication number Publication date
ITMI20131676A1 (it) 2014-04-17
FR2996976A1 (fr) 2014-04-18
CN103731409A (zh) 2014-04-16
US20140108603A1 (en) 2014-04-17
EP2723031B1 (en) 2019-07-24
EP2723031A1 (en) 2014-04-23
KR20140048815A (ko) 2014-04-24
FR2996976B1 (fr) 2017-02-24
US10440157B2 (en) 2019-10-08
RU2013145968A (ru) 2015-04-20

Similar Documents

Publication Publication Date Title
CN103731409B (zh) 用于具有tcp加速的嵌入式汽车采集设备的分布式测量装置
US10129153B2 (en) In-line network accelerator
US7389462B1 (en) System and methods for high rate hardware-accelerated network protocol processing
US7869355B2 (en) Network receive interface for high bandwidth hardware-accelerated packet processing
US7817634B2 (en) Network with a constrained usage model supporting remote direct memory access
EP3503507B1 (en) Network interface device
McAuley Protocol design for high speed networks
US10455061B2 (en) Lightweight transport protocol
Rizzo Revisiting network I/O APIs: the netmap framework
US11394664B2 (en) Network interface device
CN103873550A (zh) 用于ecu和/或测量设备之间的数据传输的方法
CN102647370B (zh) WiFi网络和ZigBee网络之间的通信方法
CN110061923A (zh) 流量控制方法、装置、交换机、发送端服务器及介质
CN110120854A (zh) 传输数据的方法和装置
EP3563535B1 (en) Transmission of messages by acceleration components configured to accelerate a service
JPWO2010032533A1 (ja) ネットワークプロトコル処理システム、及びネットワークプロトコル処理方法
US20080040494A1 (en) Partitioning a Transmission Control Protocol (TCP) Control Block (TCB)
Wang et al. An Optimized RDMA QP Communication Mechanism for Hyperscale AI Infrastructure

Legal Events

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