基于IPde物联网架构

Please download to get full document.

View again

of 2
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Categories
Published
基于IPde物联网架构
  13.4.1 IP 分段重组  uIP 通过将重组的数据包存入单独的缓冲区来实现 IP 分段重组。输入分段复制到缓冲区中正确区域,并用一个位图来记录接收到的分段。由于 IP 分段的首字节在 8 字节处对齐,所以位图仅需要少量内存。当所有的分段都被重组完毕时,生成的 IP 数据包传递给传输层,如果在指定的时间范围内,分段没有被全部接收,数据包将被丢弃。  uIP 为将重组的数据包分配到一个单独的缓冲区。为了免于被其它数据包改写,该缓存区与用于 uIP 测试数据包缓冲区相互分离。由于 uIP 仅为重组分段分配一个单独的缓冲区,所以 uIP 不支持多个数据包的同时重组。采用这个设计决策的原因是:在当今网络中, IP 分段相对而言不太普遍。  13.4.2 TCP uIP 中的 TCP 实现设计得尽可能简单但是没有丢弃任何必要的 TCP 机制。 TCP 的一些机制意图提供高的吞吐量,这些机制在仅有少来那个待发送数据的系统中并不是必须的。因此, uIP 作出了一个权衡:内存效率比高数据吞吐量更为重要。如果系统要求高数据吞吐量,则 uIP 不是一个适合的选择。  uIP 中的 TCP 实现是由数据包输入和周期处理驱动开始的。 TCP 分析输入数据包,判断数据包是否包含待传送给应用程序的数据,并判断应用程序是否被应用函数所调用。如果输入数据包确认先前发送过数据,连接状态即可被更新。应用程序也被告知允许发送新数据。  TCP 允许连接监听输入连接请求。在 uIP 中,监听连接由 16 位端口号识别。根据监听连接列表,也可以检查输入连接请求。该监听列表是动态的,可以由系统的应用程序改动。  1.   滑动窗口   在发送数据时,大多数的 TCP 实现都会使用滑动窗口机制,多数据分段可连接发送而不必对每一个分段都进行确认,这种做法旨在提供高的吞吐量,因为如果接收方不对接收的数据包进行确认,收发两方之间的整个网络通道就会充满数据包。   滑动窗口机制的实现使用了大量 32 位加减法,这是因为 TCP 中使用 32 位序列号。在很多 8 位以及 16 位微控制器的代码长度方面, 32 位算法是非常昂贵的,所以 uIP 并不实现滑动窗口机制,并且, uIP 不对发送的数据包进行缓存。对于那些不缓存发送数据包的滑动窗口而言,其实现必须得到复杂的应用层支持。反之,在任何特定的时间里, uIP 仅允许每个连接中的一个 TCP 分段不必得到确认。   有必要指出的是,即使大多数 TCP 实现都采用了滑动窗口算法,但是它并不是 TCP 规范中必需的内存。无论如何,移除滑动窗口机制并不影响互操作性和标准一致性。  2. 重传和 RTT 估值   重传由周期性 TCP 定时器驱动。每当周期性定时器被调用时,每个连接的重传定时器的值将减一。如果定时器的值减为零,重传即可开始。   为了给超时重传找到合适的值, TCP 要不断估计每个现有连接当前的 RTT 值。使用 TCP 周期性定时器,就可以对 uIP 中 RTT 进行估值。每次触发周期性定时器时,他都会为网络中包含未确认数据的连接增加一个计数器。当接收到一个确认时,计数器的当前值都作为 RTT 的一个样值。该样值与 Van Jacobson 的标准 TCP RTT 估值函数一起使用。此函数用于计算 RTT 估值。 Kan 算法和 Partridge 算法被使用以保证重传对估值的准确性没有影响。  3 .流量控制  TCP 流量控制机制的目的是允许内存空间差距很大的主机间的相互通信。在每个 TCP 分段中,分段的发送方都会注明其可用缓存空间的大小。 TCP 发送方不得发送比接收方注明的缓存空间更多的数据。   在 uIP 中,应用程序不得发送比接收主机缓存量更多的数据。应用程序也不得发送比接收主机允许发送的字节数更多的数据。如果远端主机不能接收任何数据,协议栈将会启动零窗口  探测( zero-window probing )机制。  4. 拥塞控制   拥塞控制机制限制了网络中同时传输的 TCP 分段的数目。从一开始,用于拥塞控制的实现算法就设计得很简单以便于实现。该算法的执行仅仅需要几行代码即可。   由于 uIP 在每个连接中仅处理一个执行中的 TCP 分段,同时分段的数量也不能进一步被限制,因此 TCP 拥塞控制机制则是不必要的。  5. 紧急数据  TCP 紧急数据机制提供了应用程序的通报机制。应用程序适用该机制来标记其中紧急程度高于正常数据的部分数据流。由数据接收方的应用程序来界定数据是否属于紧急数据。   在很多 TCP 实现中,包括 BSD 实现,紧急数据功能提高了实现的复杂性,因为需要基于同步的 API 来实现非同步的通报机制。而 uIP 已经适用了异步的基于事件的 API ,所以紧急数据功能的实现并没有导致复杂性的增加。  13.4.3 校验和计算  TCP 协议和 IP 协议实现 IP 和 TCP 数据包的数据和报头部分的校验功能。由于校验和的计算是基于每个收发数据包的所有字节,所以提高计算校验和函数的效率非常重要。在大多数情况下,这就意味着,校验和计算要为运行在 uIP 协议栈上的特定体系结构做出精细的调整。由于 uIP  包含一个通用校验和函数,所以它特定与体系结构的两个函数 uip_ipchksum  和 uip_tepchksum() 的实现也是开放的。这些函数中的校验和计算可以采用高度优化的汇编语言编写而不使用通用的 C 语言代码。  13.5 内存占用空间   比起用于通用计算机的现有 IP 协议栈, uIP 的内存占用空间非常小。 Linux 操作系统的 IP 协议栈需要几十万字节的内存。而对于在智能物件中适用的内存受限的微控制器来说,这样的 IP 协议栈并不适合。  uIP 的代码占用空间为几千字节,而内存占空间大小小于 2KB 。 IPv6 的代码占用空间  __ __IPv4 。表 13.1 列出了 uIPv6 的不同功能所用的代码占用空间和内存占用空间的详细情况。占用空间有 Atmel ATmega128 处理计算,代码有 gcc C 编译器编译。  
Similar documents
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks