基于驱动程序的协议栈设计

基于驱动程序的协议栈设计，相比于传统的基于任务的协议栈设计来说有两点好处：(1)效率更高；(2)对于有多个协议栈的系统来说，有更大的兼容性。
1 基于任务的方式
　　在我们比较两种设计方式的技术细节之前，我们必须了解它们。传统的设计方式包括将协议栈置于实时操作系统或内核之上，但是大多数实时操作系统不提供网络互连的框架。所以，协议栈的设计者们不得不利用实时操作系统提供的机制――Task。图1说明了如何利用任务来实现一个三层间通信的协议。每一层被作为一个单独的任务，外加任务间通信机制负责传送数据和控制包上下通过协议栈，程序设计者负责定义层与层之间的接口和一个应用程序接口(API)，以利于应用程序员传送和接收数据。

在这里存在几个效率不高的来源：首先，正如图1中点线所说明的，当包在应用程序、上层的通信协议，以及网络接口的设备驱动程序之间交换时，下层的操作系统正忙于上下文切换，每一次实时操作系统挂起其中一个任务，恢复执行另一个任务，时间都浪费在存取任务上下文中，考虑到每一个包无论是发还是收，都要通过协议栈的每一层，上下文切换的确造成了巨大的浪费。另外，当数据和控制包在应用程序任务和网络接口之间流动时，包含此类信息的缓冲区必然重复在任务间通信队列加入或删除。然而，这个系统开销是很大的，这本身是由于系统在队列操作时必然包括需与中断和上下文切换隔离的临界区。因此，不仅时间浪费于队列操作，而且整个系统对一些重要的事件例如中断的响应变得延迟。
2 基于驱动程序的方法
　　另外一种选择是将协议栈各层置于实时操作系统之中，图2说明了基于此种方案，同样的三层间通信协议是如何实施的。两者之间的显著区别在于：各个协议层是作为驱动程序模块，而不是任务来实现的。

另外一个改变在于：协议栈之上还有一个网络服务模块。加入这个模块的目的在于将与协议无关的网络特性抽象化。也就是说，它将应用程序设计者用来在协议栈间收发数据的应用程序接口(API)标准化，例如：你的嵌入式系统可能需要同时支持基于调制解调器接口的PPP连到一台远程计算机和一个红外接口用来与本地计算机通信。然而程序设计者不必为两个事件各自编程，它只需用网络服务模块提供API与其它计算机进行通信，唯一的区别在于通过哪个网络接口而已。
　　基于驱动程序方式的一个显著优点就在于上下文切换的次数仅仅是基于控制台应用程序的函数，并不基于协议层的数量。这样一来就可以减少实时操作系统保存和恢复任务上下文的次数，因而空出时间作更有意义的事，例如执行应用程序代码。
　　另一个好处在于，数据和控制信息更简单的在层与层之间传输，因为所有的协议层都处于同一个上下文中，所以相关的数据结构自动地为上下层所接受，结果你不必把他们在任务间队列中传送，由此产生的是，同时也避免了那些临界区系统由此可改进中断和优先级任务的响应时间。
3 缓冲区拷贝
　　缓冲区拷贝效率不高的第一个潜在因素在于：当数据在层与层之间传输时，数据缓冲区的分配、拷贝和释放，这与协议栈的结构无关，仅与缓冲区本身的结构有关。