uIP嵌入式TCP/IP栈参考手册：设计与API

5星 · 超过95%的资源需积分: 9 170 浏览量更新于2024-07-23 收藏 1.36MB PDF 举报

uIP Reference Manual 是一份专注于嵌入式TCP/IP协议栈的详细文档，由Adam Dunkels编撰，发布于2006年6月。这份手册提供了对uIP 1.0版本的深入介绍和详尽指南，uIP是一种轻量级、高效的网络协议栈，特别适合资源受限的嵌入式系统。 **1. The uIP TCP/IP Stack** - **1.1 Introduction**: uIP 强调了其设计目标，即提供一个小型、高效的协议栈，以适应嵌入式设备的内存限制。它旨在简化网络编程，使开发者能够快速实现TCP/IP功能。 - **1.2 TCP/IP Communication**: uIP 支持TCP/IP通信协议，包括TCP（传输控制协议）和IP（网际协议），以及UDP（用户数据报协议）。它提供了基本的连接和数据传输机制，但可能不包含完整的协议实现细节。 - **1.3 Main Control Loop**: 核心部分是uIP的控制循环，它管理着网络数据包的接收、处理和发送，确保网络功能的正常运行。 - **1.4 Architecture-Specific Functions**: 根据硬件和平台的特性，uIP可能包含特定架构的优化，如内存管理和中断处理，以适应不同的嵌入式设备。 - **1.5 Memory Management**: 对内存的有效管理至关重要，uIP在设计时考虑了内存利用率，以减少对资源的需求。 - **1.6 Application Programming Interface (API)**: 提供了一套易于使用的API，使得开发人员可以轻松地与uIP交互，创建网络应用程序。 - **1.7 Examples**: 手册中提供了示例代码，帮助读者理解如何在实际项目中集成和使用uIP。 - **1.8 Protocol Implementations**: uIP可能并未实现所有的TCP/IP协议细节，而是专注于提供核心功能，比如数据包解析和封装。 - **1.9 Performance**: uIP着重于低功耗和快速响应，这对于嵌入式环境尤其关键。性能测试和优化指南也在手册中。 **2. uIP 1.0 Module Index and Hierarchical Index** 这部分包含了uIP模块的详细索引，如模块分类、类层次结构和数据结构索引，方便查找和理解协议栈的组成部分。 **3. Data Structure Index**: 描述了uIP中使用的数据结构及其功能，如缓冲区、计数器和状态机等，这些都是实现网络功能的基础。 **4. File Index**: 列出了uIP相关的源代码文件，有助于开发者定位和理解具体实现。 **5. Module Documentation**: 详述了uIP的各个功能模块，如Protothreads（轻量级线程）、应用程序接口、配置和初始化函数、设备驱动程序接口以及应用级别的API。 **6. Specific Topics**: - **Protothreads**: 一种特殊的并发模型，适合嵌入式系统的资源限制。 - **Applications**: 提供针对不同应用场景的示例和指导。 - **Configuration functions**: 如设置网络参数，以适应特定网络环境。 - **Initialization functions**: 初始化和配置uIP以开始网络操作。 - **Device driver functions**: 与硬件设备交互，如串口或网络接口控制器。 - **Application functions**: 开发者可以利用的高级功能和扩展点。 - **Conversion functions**: 转换数据格式或处理网络数据包。 - **Driver-specific variables**: 驱动程序中使用的变量，反映硬件特定需求。 - **The uIP TCP/IP stack architecture**: 详细的协议栈结构和工作原理。 - **Architecture-specific uIP functions**: 特定硬件平台的优化实现。 - **uIP Address Resolution Protocol**: 解决IP地址自动获取的功能，如DHCP或静态配置。 - **Configuration**: 如设置DNS服务器和IP地址等网络配置选项。通过阅读这份uIP Reference Manual，开发者可以深入了解如何在嵌入式设备上实现高效、低资源消耗的TCP/IP通信，并掌握如何配置、使用和调试这个轻量级的协议栈。

10 The uIP TCP/IP stack

1.7.4 Utilizing TCP Flow Control

This example shows a simple application that connects to a host, sends an HTTP request for a ﬁle and

downloads it to a slow device such a disk drive. This shows how to use the ﬂow control functions of uIP.

void example4_init(void) {

u16_t ipaddr[2];

uip_ipaddr(ipaddr, 192,168,0,1);

uip_connect(ipaddr, HTONS(80));

}

void example4_app(void) {

if(uip_connected() || uip_rexmit()) {

uip_send("GET /file HTTP/1.0\r\nServer:192.186.0.1\r\n\r\n",

48);

return;

}

if(uip_newdata()) {

device_enqueue(uip_appdata, uip_datalen());

if(device_queue_full()) {

uip_stop();

}

if(uip_poll() && uip_stopped()) {

if(!device_queue_full()) {

uip_restart();

}

When the connection has been established, an HTTP request is sent to the server. Since this is the only

data that is sent, the application knows that if it needs to retransmit any data, it is that request that should

be retransmitted. It is therefore possible to combine these two events as is done in the example.

When the application receives new data from the remote host, it sends this data to the device by using

the function device_enqueue(). It is important to note that this example assumes that this function copies

the data into its own buffers. The data in the uip_appdata buffer will be overwritten by the next incoming

packet.

If the device’s queue is full, the application stops the data from the remote host by calling the uIP function

uip_stop(). The application can then be sure that it will not receive any new data until uip_restart() is called.

The application polling event is used to check if the device’s queue is no longer full and if so, the data ﬂow

is restarted with uip_restart().

1.7.5 A Simple Web Server

This example shows a very simple ﬁle server application that listens to two ports and uses the port number

to determine which ﬁle to send. If the ﬁles are properly formatted, this simple application can be used as a

web server with static pages. The implementation follows.

struct example5_state {

char

dataptr;

unsigned int dataleft;

};

void example5_init(void) {

uip_listen(HTONS(80));

uip_listen(HTONS(81));

Generated on Mon Jun 12 10:23:20 2006 for uIP 1.0 by Doxygen

1.7 Examples 11

}

void example5_app(void) {

struct example5_state

s = (struct example5_state)uip_conn->appstate;

if(uip_connected()) {

switch(uip_conn->lport) {

case HTONS(80):

s->dataptr = data_port_80;

s->dataleft = datalen_port_80;

break;

case HTONS(81):

s->dataptr = data_port_81;

s->dataleft = datalen_port_81;

break;

}

uip_send(s->dataptr, s->dataleft);

return;

}

if(uip_acked()) {

if(s->dataleft < uip_mss()) {

uip_close();

return;

}

s->dataptr += uip_conn->len;

s->dataleft -= uip_conn->len;

uip_send(s->dataptr, s->dataleft);

}

The application state consists of a pointer to the data that should be sent and the size of the data that is left

to send. When a remote host connects to the application, the local port number is used to determine which

ﬁle to send. The ﬁrst chunk of data is sent using

uip_send(). uIP makes sure that no more than MSS bytes

of data is actually sent, even though s->dataleft may be larger than the MSS.

The application is driven by incoming acknowledgments. When data has been acknowledged, new data

can be sent. If there is no more data to send, the connection is closed using uip_close().

1.7.6 Structured Application Program Design

When writing larger programs using uIP it is useful to be able to utilize the uIP API in a structured way.

The following example provides a structured design that has showed itself to be useful for writing larger

protocol implementations than the previous examples showed here. The program is divided into an uIP

event handler function that calls seven application handler functions that process new data, act on acknowl-

edged data, send new data, deal with connection establishment or closure events and handle errors. The

functions are called newdata(), acked(), senddata(), connected(), closed(), aborted(), and timedout(), and

needs to be written speciﬁcally for the protocol that is being implemented.

The uIP event handler function is shown below.

void example6_app(void) {

if(uip_aborted()) {

aborted();

}

if(uip_timedout()) {

timedout();

}

if(uip_closed()) {

closed();

}

Generated on Mon Jun 12 10:23:20 2006 for uIP 1.0 by Doxygen

1.7 Examples 13

s->textlen -= uip_conn->len;

s->textptr += uip_conn->len;

if(s->textlen == 0) {

switch(s->state) {

case STATE_HELLO:

s->state = STATE_WORLD;

s->textptr = "world!\n";

s->textlen = 7;

break;

case STATE_WORLD:

uip_close();

break;

}

static void senddata(void) {

struct example6_state

s = (struct example6_state

)uip_conn->appstate;

if(s->textlen > 0) {

uip_send(s->textptr, s->textlen);

}

The application state consists of a "state" variable, a "textptr" pointer to a text message and the "textlen"

length of the text message. The "state" variable can be either "STATE_WAITING", meaning that the

application is waiting for data to arrive from the network, "STATE_HELLO", in which the application is

sending the "Hello" part of the message, or "STATE_WORLD", in which the application is sending the

"world!" message.

The application does not handle errors or connection closing events, and therefore the aborted(), timedout()

and closed() functions are implemented as empty functions.

The connected() function will be called when a connection has been established, and in this case sets the

"state" variable to be "STATE_WAITING" and the "textlen" variable to be zero, indicating that there is no

message to be sent out.

When new data arrives from the network, the newdata() function will be called by the event handler func-

tion. The newdata() function will check if the connection is in the "STATE_WAITING" state, and if so

switches to the "STATE_HELLO" state and registers a 6 byte long "Hello " message with the connection.

This message will later be sent out by the senddata() function.

The acked() function is called whenever data that previously was sent has been acknowleged by the receiv-

ing host. This acked() function ﬁrst reduces the amount of data that is left to send, by subtracting the length

of the previously sent data (obtained from "uip_conn → len") from the "textlen" variable, and also adjusts

the "textptr" pointer accordingly. It then checks if the "textlen" variable now is zero, which indicates that all

data now has been successfully received, and if so changes application state. If the application was in the

"STATE_HELLO" state, it switches state to "STATE_WORLD" and sets up a 7 byte "world!\n" message

to be sent. If the application was in the "STATE_WORLD" state, it closes the connection.

Finally, the senddata() function takes care of actually sending the data that is to be sent. It is called by

the event handler function when new data has been received, when data has been acknowledged, when

a new connection has been established, when the connection is polled because of inactivity, or when a

retransmission should be made. The purpose of the senddata() function is to optionally format the data that

is to be sent, and to call the

uip_send() function to actually send out the data. In this particular example,

the function simply calls

uip_send() with the appropriate arguments if data is to be sent, after checking if

data should be sent out or not as indicated by the "textlen" variable.

It is important to note that the senddata() function never should affect the application state; this should only

be done in the acked() and newdata() functions.

Generated on Mon Jun 12 10:23:20 2006 for uIP 1.0 by Doxygen

14 The uIP TCP/IP stack

1.8 Protocol Implementations

The protocols in the TCP/IP protocol suite are designed in a layered fashion where each protocol performs

a speciﬁc function and the interactions between the protocol layers are strictly deﬁned. While the layered

approach is a good way to design protocols, it is not always the best way to implement them. In uIP, the

protocol implementations are tightly coupled in order to save code space.

This section gives detailed information on the speciﬁc protocol implementations in uIP.

1.8.1 IP — Internet Protocol

When incoming packets are processed by uIP, the IP layer is the ﬁrst protocol that examines the packet.

The IP layer does a few simple checks such as if the destination IP address of the incoming packet matches

any of the local IP address and veriﬁes the IP header checksum. Since there are no IP options that are

strictly required and because they are very uncommon, any IP options in received packets are dropped.

1.8.1.1 IP Fragment Reassembly

IP fragment reassembly is implemented using a separate buffer that holds the packet to be reassembled. An

incoming fragment is copied into the right place in the buffer and a bit map is used to keep track of which

fragments have been received. Because the ﬁrst byte of an IP fragment is aligned on an 8-byte boundary,

the bit map requires a small amount of memory. When all fragments have been reassembled, the resulting

IP packet is passed to the transport layer. If all fragments have not been received within a speciﬁed time

frame, the packet is dropped.

The current implementation only has a single buffer for holding packets to be reassembled, and therefore

does not support simultaneous reassembly of more than one packet. Since fragmented packets are uncom-

mon, this ought to be a reasonable decision. Extending the implementation to support multiple buffers

would be straightforward, however.

1.8.1.2 Broadcasts and Multicasts

IP has the ability to broadcast and multicast packets on the local network. Such packets are addressed

to special broadcast and multicast addresses. Broadcast is used heavily in many UDP based protocols

such as the Microsoft Windows ﬁle-sharing SMB protocol. Multicast is primarily used in protocols used

for multimedia distribution such as RTP. TCP is a point-to-point protocol and does not use broadcast or

multicast packets. uIP current supports broadcast packets as well as sending multicast packets. Joining

multicast groups (IGMP) and receiving non-local multicast packets is not currently supported.

1.8.2 ICMP — Internet Control Message Protocol

The ICMP protocol is used for reporting soft error conditions and for querying host parameters. Its main

use is, however, the echo mechanism which is used by the "ping" program.

The ICMP implementation in uIP is very simple as itis restricted to only implement ICMP echo messages.

Replies to echo messages are constructed by simply swapping the source and destination IP addresses of

incoming echo requests and rewriting the ICMP header with the Echo-Reply message type. The ICMP

checksum is adjusted using standard techniques (see RFC1624).

Since only the ICMP echo message is implemented, there is no support for Path MTU discovery or ICMP

redirect messages. Neither of these is strictly required for interoperability; they are performance enhance-

ment mechanisms.

Generated on Mon Jun 12 10:23:20 2006 for uIP 1.0 by Doxygen

剩余260页未读，继续阅读

飞翔的码流

粉丝: 6

uIP嵌入式TCP/IP栈参考手册：设计与API

uIP技术手册（1.0版本的）

UIP协议的中文介绍

uIP学习资料（全）

uIP 0.9 参考手册中文版

uIP参考手册中文文档

uIP 1.0参考手册：嵌入式TCP/IP栈详解

uIP0.9中文手册.pdf

STM32参考资料uIP学习资料uIP学习

uIP TCPIP协议栈代码及手册.zip

uip.rar_uIP0.9_uip_uip keil_uip-1.0_uip接口

最新资源