TCPIP协议栈lwip的移植

TCP/IP协议栈lwip的移植

新建几个头文件

Include/lwipopts.h

Include/arch/cc.h

Include/arch/perf.h

Include/arch/sys_arch.h

除头文件外还需要添加一个C文件:sys_arch.c。说明在doc/sys_arch.txt中。

修改netif/Ethernetif.c。

结构对齐的几个宏

对于一个结构下载下来的LWIP的通用定义如下:

PACK_STRUCT_BEGIN

struct icmp_echo_hdr {

PACK_STRUCT_FIELD(u8_t type);

PACK_STRUCT_FIELD(u8_t code);

PACK_STRUCT_FIELD(u16_t chksum);

PACK_STRUCT_FIELD(u16_t id);

PACK_STRUCT_FIELD(u16_t seqno);

} PACK_STRUCT_STRUCT;

PACK_STRUCT_EN

#define PACK_STRUCT_FIELD(x)

这个宏是为了字节序的转换,由于是用的小端,就不用转换了直接定义为

#define PACK_STRUCT_FIELD(x) x

#define PACK_STRUCT_STRUCT

#define PACK_STRUCT_BEGIN

#define PACK_STRUCT_END

以上三个宏都是为了做结构体对齐用:

对于gcc的编译器在结构体后跟个关键字就ok

struct ip_hdr {

} ;__attribute__ ((__packed__))

因此可以定义为

#define PACK_STRUCT_STRUCT __attribute__ ((__packed__))

#define PACK_STRUCT_BEGIN

#define PACK_STRUCT_END

对于vc的编译器就郁闷了,vc做结构体对齐是这样做的

#pragma pack(1) //结构体按照1字节对齐

struct ip_hdr {

} ;

#pragma pack() //结构体按照编译器默认值对齐

但是VC的编译器不允许将预处理做为宏,也就是不允许这种宏替代#define PACK_STRUCT_BEGIN #pragma pack(1)

所以想靠宏替换来完成字节对齐是不行了,于是就动了大工夫做了如下处理#ifdef WIN32

#define PACK_STRUCT_STRUCT

#define PACK_STRUCT_BEGIN

#define PACK_STRUCT_END

#else

#define PACK_STRUCT_STRUCT __attribute__ ((__packed__))

#define PACK_STRUCT_BEGIN

#define PACK_STRUCT_END

endif

PACK_STRUCT_BEGIN

#ifdef WIN32

#pragma pack(1)

#endif

struct icmp_echo_hdr {

PACK_STRUCT_FIELD(u8_t type);

PACK_STRUCT_FIELD(u8_t code);

PACK_STRUCT_FIELD(u16_t chksum);

PACK_STRUCT_FIELD(u16_t id);

PACK_STRUCT_FIELD(u16_t seqno);

} PACK_STRUCT_STRUCT;

#ifdef WIN32

#pragma pack()

#endif

PACK_STRUCT_END

这样一改在VC下和GCC都可以了,不过每个结构上都要修改一下,这个是黑郁闷黑郁闷啊

“轻量级”保护

"lightweight" synchronization mechanisms -

SYS_ARCH_DECL_PROTECT(x) - declare a protection state variable.

SYS_ARCH_PROTECT(x) - enterprotection mode.

SYS_ARCH_UNPROTECT(x) - leaveprotection mode.

这三个宏定义一个快速的“保护”和“解除保护”操作。例如进入保护可以是屏蔽中断或

使用一个信号量或mutex。注意:进入保护后还允许再次进入保护,旧的保护标志通

过lev返回,退出保护时再恢复。

如果没有定义这三个宏,Sys.h中有一段代码进行了判断。

#ifndef SYS_ARCH_PROTECT

如果没有定义SYS_ARCH_PROTECT,那么可以在lwipopts.h中定义宏SYS_LIGHTWEIGHT_PROT,并在sys_arch.c中定义函数sys_arch_protect()和sys_arch_unprotect(lev)

#if SYS_LIGHTWEIGHT_PROT

#define SYS_ARCH_DECL_PROTECT(lev) sys_prot_t lev

/** SYS_ARCH_PROTECT

* Perform a "fast" protect. This could be implemented by

* disabling interrupts for an embedded system or by using a semaphore or

* mutex. The implementation should allow calling SYS_ARCH_PROTECT when * already protected. The old protection level is returned in the variable

* "lev". This macro will default to calling the sys_arch_protect() function

* which should be implemented in sys_arch.c. If a particular port needs a

* different implementation, then this macro may be defined in sys_arch.h

*/

#define SYS_ARCH_PROTECT(lev) lev = sys_arch_protect()

/** SYS_ARCH_UNPROTECT

* Perform a "fast" set of the protection level to "lev". This could be

* implemented by setting the interrupt level to "lev" within the MACRO or by

* using a semaphore or mutex. This macro will default to calling the

* sys_arch_unprotect() function which should be implemented in

* sys_arch.c. If a particular port needs a different implementation, then

* this macro may be defined in sys_arch.h

*/

#define SYS_ARCH_UNPROTECT(lev) sys_arch_unprotect(lev)

sys_prot_t sys_arch_protect(void);

void sys_arch_unprotect(sys_prot_t pval);

#else

#define SYS_ARCH_DECL_PROTECT(lev)

#define SYS_ARCH_PROTECT(lev)

#define SYS_ARCH_UNPROTECT(lev)

#endif /* SYS_LIGHTWEIGHT_PROT */

#endif /* SYS_ARCH_PROTECT */

LWIP_COMPAT_MUTEX

定义此宏表示用信号量来代替mutex。

Init.c

不定义NO_SYS和“#define NO_SYS0”的效果是一样的。

下面这些宏对代码有影响:LWIP_SOCKET

LWIP_ARP

LWIP_RAW

LWIP_UDP

LWIP_TCP

LWIP_SNMP

LWIP_AUTOIP

LWIP_IGMP

LWIP_DNS

LWIP_TIMERS

void

lwip_init(void)

{

/* Sanity check user-configurable values */ lwip_sanity_check();

/* Modules initialization */

stats_init();

#if !NO_SYS

sys_init();

#endif /* !NO_SYS */

mem_init();

memp_init();

pbuf_init();

netif_init();

#if LWIP_SOCKET

lwip_socket_init();

#endif /* LWIP_SOCKET */

ip_init();

#if LWIP_ARP

etharp_init();

#endif /* LWIP_ARP */

#if LWIP_RAW

raw_init();

#endif /* LWIP_RAW */

#if LWIP_UDP

udp_init();

#endif /* LWIP_UDP */

#if LWIP_TCP

tcp_init();

#endif /* LWIP_TCP */

#if LWIP_SNMP

snmp_init();

#endif /* LWIP_SNMP */

#if LWIP_AUTOIP

autoip_init();

#endif /* LWIP_AUTOIP */

#if LWIP_IGMP

igmp_init();

#endif /* LWIP_IGMP */

#if LWIP_DNS

dns_init();

#endif /* LWIP_DNS */

#if LWIP_TIMERS

sys_timeouts_init();

#endif /* LWIP_TIMERS */

}

netif_add函数

它添加一个网络接口到lwip,一个网卡应该是一个网络接口。本地回环也是一个网络接口,它已经在tcpip_init中的lwip_init调用netif_init被添加。

/**

* Add a network interface to the list of lwIP netifs.

*

* @param netif a pre-allocated netif structure

* @param ipaddr IP address for the new netif

* @param netmask network mask for the new netif

* @param gw default gateway IP address for the new netif

* @param state opaque data passed to the new netif

* @param init callback function that initializes the interface

* @param input callback function that is called to pass

* ingress packets up in the protocol layer stack.

*

* @return netif, or NULL if failed.

*/

struct netif *

netif_add(struct netif *netif, ip_addr_t *ipaddr, ip_addr_t *netmask,

ip_addr_t *gw, void *state, netif_init_fn init, netif_input_fn input)

Struct net_if

在初始化用netif_add添加到lwip中。

/** Generic data structure used for all lwIP network interfaces.

* The following fields should be filled in by the initialization

* function for the device driver: hwaddr_len, hwaddr[], mtu, flags */

struct netif {

/** pointer to next in linked list */

struct netif *next;

/** IP address configuration in network byte order */

ip_addr_t ip_addr;

ip_addr_t netmask;

ip_addr_t gw;

/** This function is called by the network device driver

* to pass a packet up the TCP/IP stack. */

netif_input_fn input; // 网卡数据接收函数,自定义设置

/** This function is called by the IP module when it wants

* to send a packet on the interface. This function typically

* first resolves the hardware address, then sends the packet. */

netif_output_fn output; //发送无连接的数据包,如广播包,多播包,最终还

是调用下面的linkoutput函数。固定设置为etharp_output。

/** This function is called by the ARP module when it wants

* to send a packet on the interface. This function outputs

* the pbuf as-is on the link medium. */

netif_linkoutput_fn linkoutput; //发送有连接的数据包,已经包含MAC,类型等数据。

#if LWIP_NETIF_STATUS_CALLBACK

/** This function is called when the netif state is set to up or down

*/

netif_status_callback_fn status_callback;

#endif /* LWIP_NETIF_STATUS_CALLBACK */

#if LWIP_NETIF_LINK_CALLBACK

/** This function is called when the netif link is set to up or down

*/

netif_status_callback_fn link_callback;

#endif /* LWIP_NETIF_LINK_CALLBACK */

/** This field can be set by the device driver and could point

* to state information for the device. */

void *state; //一般设置为网卡的私有数据,如netif->state = ethernetif;

#if LWIP_DHCP

/** the DHCP client state information for this netif */

struct dhcp *dhcp;

#endif /* LWIP_DHCP */

#if LWIP_AUTOIP

/** the AutoIP client state information for this netif */

struct autoip *autoip;

#endif

#if LWIP_NETIF_HOSTNAME

/* the hostname for this netif, NULL is a valid value */

char* hostname;

#endif /* LWIP_NETIF_HOSTNAME */

/** maximum transfer unit (in bytes) */

u16_t mtu;

/** number of bytes used in hwaddr */

u8_t hwaddr_len;

/** link level hardware address of this interface */

u8_t hwaddr[NETIF_MAX_HWADDR_LEN];

/** flags (see NETIF_FLAG_ above) */

u8_t flags;

/** descriptive abbreviation */

char name[2];

/** number of this interface */

u8_t num;

#if LWIP_SNMP

/** link type (from "snmp_ifType" enum from snmp.h) */

u8_t link_type;

/** (estimate) link speed */

u32_t link_speed;

/** timestamp at last change made (up/down) */

u32_t ts;

/** counters */

u32_t ifinoctets;

u32_t ifinucastpkts;

u32_t ifinnucastpkts;

u32_t ifindiscards;

u32_t ifoutoctets;

u32_t ifoutucastpkts;

u32_t ifoutnucastpkts;

u32_t ifoutdiscards;

#endif /* LWIP_SNMP */

#if LWIP_IGMP

/** This function could be called to add or delete a entry in the multicast filter table of the ethernet MAC.*/

netif_igmp_mac_filter_fn igmp_mac_filter;

#endif /* LWIP_IGMP */

#if LWIP_NETIF_HWADDRHINT

u8_t *addr_hint;

#endif /* LWIP_NETIF_HWADDRHINT */

#if ENABLE_LOOPBACK

/* List of packets to be queued for ourselves. */

struct pbuf *loop_first;

struct pbuf *loop_last;

#if LWIP_LOOPBACK_MAX_PBUFS

u16_t loop_cnt_current;

#endif /* LWIP_LOOPBACK_MAX_PBUFS */

#endif /* ENABLE_LOOPBACK */

};

struct pbuf

一个网络包可能由多个pbuf组成,字段tot_len指定这个网络包的大小,字段len 是当前pbuf包含数据的大小。

判断一个网络包的最后一个包不能以next字段等于空来判断,它可能不为空,下一个pbuf为下一个网络包的内容。应该计算tot_len来判断一个包的结束。

struct pbuf {

/** next pbuf in singly linked pbuf chain */

struct pbuf *next; //下一个pbuf

/** pointer to the actual data in the buffer */

void *payload; // 当前结构数据内容

/**

* total length of this buffer and all next buffers in chain

* belonging to the same packet.

*

* For non-queue packet chains this is the invariant:

* p->tot_len == p->len + (p->next? p->next->tot_len: 0)

*/

u16_t tot_len;

/** length of this buffer */

u16_t len;

/** pbuf_type as u8_t instead of enum to save space */

u8_t /*pbuf_type*/ type;

/** misc flags */

u8_t flags;

/**

* the reference count always equals the number of pointers

* that refer to this pbuf. This can be pointers from an application,

* the stack itself, or pbuf->next pointers from a chain.

*/

u16_t ref;

};

Ethernetif.c

它是你要移植的网卡驱动程序与lwip连接的文件。源代码提供了一个模板。

struct ethernetif结构

它是网卡私有数据结构

struct ethernetif {

struct eth_addr *ethaddr;

/* Add whatever per-interface state that is needed here. */在这里添加自定义的数据

};

ethernetif_input

网卡有数据时应该调用这个函数。过程大致如下:网卡读任务中断处理

(1)信号量pend(等待数据到来中断)

(2)pend成功,调用ethernetif_input

(3)回到步骤1. 如果有中断表明数据包到达,给“网卡读任务”发送信号量。

ethernetif_input做的工作有:

(1)调用low_level_input读取数据包

(2)判断数据包的以太网类型并调用netif->input。netif->input是在协议栈初始化添加的。如netif_add(mLocalNetif, &ipaddr, &netmask, &gw, NULL,ethernetif_init, tcpip_input),那么它是tcpip_input,tcpip_input做的工作发送消息给tcpip主线线程,它把数据包交给上层处理。

/**

* This function should be called when a packet is ready to be read

* from the interface. It uses the function low_level_input() that

* should handle the actual reception of bytes from the network

* interface. Then the type of the received packet is determined and

* the appropriate input function is called.

*

* @param netif the lwip network interface structure for this ethernetif

*/

static void

ethernetif_input(struct netif *netif)

{

struct ethernetif *ethernetif;

struct eth_hdr *ethhdr;

struct pbuf *p;

ethernetif = netif->state;

/* move received packet into a new pbuf */

p = low_level_input(netif);

/* no packet could be read, silently ignore this */

if (p == NULL) return;

/* points to packet payload, which starts with an Ethernet header */

ethhdr = p->payload;

switch (htons(ethhdr->type)) {

/* IP or ARP packet? */

case ETHTYPE_IP:

case ETHTYPE_ARP:

#if PPPOE_SUPPORT

/* PPPoE packet? */

case ETHTYPE_PPPOEDISC:

case ETHTYPE_PPPOE:

#endif /* PPPOE_SUPPORT */

/* full packet send to tcpip_thread to process */

if (netif->input(p, netif)!=ERR_OK)

{ LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error\n"));

pbuf_free(p);

p = NULL;

}

break;

default:

pbuf_free(p);

p = NULL;

break;

}

ethernetif_init

在初始化协议栈时,netif_add(mLocalNetif,&ipaddr, &netmask, &gw, NULL, ethernetif_init, tcpip_input)。

ethernetif_init做的工作:

(1)初始化struct ethernetif

(2)初始化struct net_if

(3)调用硬件初始化low_level_init(netif);

/**

* Should be called at the beginning of the program to set up the

* network interface. It calls the function low_level_init() to do the

* actual setup of the hardware.

*

* This function should be passed as a parameter to netif_add().

* @param netif the lwip network interface structure for this ethernetif

* @return ERR_OK if the loopif is initialized

* ERR_MEM if private data couldn't be allocated

* any other err_t on error

*/

err_t

ethernetif_init(struct netif *netif)

{

struct ethernetif *ethernetif;

LWIP_ASSERT("netif != NULL", (netif != NULL));

ethernetif = mem_malloc(sizeof(struct ethernetif));

if (ethernetif == NULL) {

LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_init: out of memory\n"));

return ERR_MEM;

}

#if LWIP_NETIF_HOSTNAME

/* Initialize interface hostname */

netif->hostname = "lwip";

#endif /* LWIP_NETIF_HOSTNAME */

/*

* Initialize the snmp variables and counters inside the struct netif.

* The last argument should be replaced with your link speed, in units

* of bits per second.

*/

NETIF_INIT_SNMP(netif, snmp_ifType_ethernet_csmacd,

LINK_SPEED_OF_YOUR_NETIF_IN_BPS);

netif->state = ethernetif;

netif->name[0] = IFNAME0;

netif->name[1] = IFNAME1;

/* We directly use etharp_output() here to save a function call.

* You can instead declare your own function an call etharp_output()

* from it if you have to do some checks before sending (e.g. if link

* is available...) */

netif->output = etharp_output;

netif->linkoutput = low_level_output;

ethernetif->ethaddr = (struct eth_addr *)&(netif->hwaddr[0]);

/* initialize the hardware */

low_level_init(netif);

return ERR_OK;

}

low_level_init

它是网卡硬件初始化的代码。它被ethernetif_init调用。

/**

* In this function, the hardware should be initialized.

* Called from ethernetif_init().

*

* @param netif the already initialized lwip network interface structure * for this ethernetif

*/

static void

low_level_init(struct netif *netif)

{

struct ethernetif *ethernetif = netif->state;

/* set MAC hardware address length */

netif->hwaddr_len = ETHARP_HWADDR_LEN;

/* set MAC hardware address */

netif->hwaddr[0] = 0x00;

netif->hwaddr[1] = 0x50;

netif->hwaddr[2] = 0x50;

netif->hwaddr[3] = 0x50;

netif->hwaddr[4] = 0x50;

netif->hwaddr[5] = 0x01;

/* maximum transfer unit */

netif->mtu = 1500;

/* device capabilities */

/* don't set NETIF_FLAG_ETHARP if this device is not an ethernet one */ netif->flags = NETIF_FLAG_BROADCAST | NETIF_FLAG_ETHARP | NETIF_FLAG_LINK_UP;

/* Do whatever else is needed to initialize interface. */

}

low_level_output

它是实现网卡发送数据的函数。

它发送链表structpbuf中的所有数据。

在代码:

netif->linkoutput = low_level_output;

中,low_level_output被赋于netif->linkoutput。

/**

* This function should do the actual transmission of the packet. The packet is * contained in the pbuf that is passed to the function. This pbuf

* might be chained.

*

* @param netif the lwip network interface structure for this ethernetif

* @param p the MAC packet to send (e.g. IP packet including MAC addresses and type)

* @return ERR_OK if the packet could be sent

* an err_t value if the packet couldn't be sent

*

* @note Returning ERR_MEM here if a DMA queue of your MAC is full can lead to

* strange results. You might consider waiting for space in the DMA queue * to become availale since the stack doesn't retry to send a packet

* dropped because of memory failure (except for the TCP timers).

*/

static err_t

low_level_output(struct netif *netif, struct pbuf *p)

{

struct ethernetif *ethernetif = netif->state;

struct pbuf *q;

initiate transfer();

#if ETH_PAD_SIZE

pbuf_header(p, -ETH_PAD_SIZE); /* drop the padding word */

#endif

for(q = p; q != NULL; q = q->next) {

/* Send the data from the pbuf to the interface, one pbuf at a

time. The size of the data in each pbuf is kept in the ->len

variable. */

send data from(q->payload, q->len);

}

signal that packet should be sent();

#if ETH_PAD_SIZE

pbuf_header(p, ETH_PAD_SIZE); /* reclaim the padding word */

#endif

LINK_STATS_INC(link.xmit);

CycloneTCP协议栈移植与使用简介

Arda Technology Arda Tech P.F.FU 2014-12-19 Ver 0.1 #elif defined(USE_XXXXXX) #include "os_port_xxxxxx.h"

NicType type;//控制器类型。0:以太网接口,1:PPP接口,2:6LowPan接口 NicInit init;//控制器初始化函数指针 NicTick tick;//控制器周期性事务处理函数指针 NicEnableIrq enableIrq;//打开控制器中断函数指针 NicDisableIrq disableIrq;//关闭控制器中断函数指针 NicEventHandler eventHandler;//控制器中断响应函数指针,这个是下半段的中断处理部分。 NicSetMacFilter setMacFilter;//配置多播MAC地址过滤函数指针 NicSendPacket sendPacket;//发送包函数指针 NicWritePhyReg writePhyReg;//写PHY寄存器函数指针 NicReadPhyReg readPhyReg;//读PHY寄存器函数指针 bool_t autoPadding;//是否支持自动填充 bool_t autoCrcGen;//是否支持自动生成CRC校验码 bool_t autoCrcCheck;//是否支持自动检查CRC错误 NicSendControlFrame sendControlFrame;//发送控制帧函数指针 NicReceiveControlFrame receiveControlFrame;//接收控制帧函数指针 NicPurgeTxBuffer purgeTxBuffer;//清除发送缓冲函数指针 NicPurgeRxBuffer purgeRxBuffer;//清除接受缓存函数指针 xxxxEthInitGpio(...)//用于在init中初始化GPIO。 xxxxEthInitDmaDesc(...)//用于在init中初始化DMA任务描述符列表。 XXXX_Handler(...)//用于MAC中断的上半段处理。 xxxxEthReceivePacket(...)//用于在eventHandler中收包,把数据从dma的缓冲复制到外部缓冲。xxxxEthCalcCrc(...)//计算CRC值,这个函数基本上是固定的。 xxxxEthDumpPhyReg(...)//用于调试的打印PHY寄存器列表值。

Zigbee协议栈原理基础

1Zigbee协议栈相关概念 1.1近距离通信技术比较: 近距离无线通信技术有wifi、蓝牙、红外、zigbee,在无线传感网络中需求的网络通信恰是近距离需求的,故,四者均可用做无线传感网络的通信技术。而,其中(1)红外(infrared):能够包含的信息过少;频率低波衍射性不好只能视距通信;要求位置固定;点对点传输无法组网。(2)蓝牙(bluetooth):可移动,手机支持;通信距离10m;芯片价格贵;高功耗(3)wifi:高带宽;覆盖半径100m;高功耗;不能自组网;(4)zigbee:价格便宜;低功耗;自组网规模大。?????WSN中zigbee通信技术是最佳方案,但它连接公网需要有专门的网关转换→进一步学习stm32。 1.2协议栈 协议栈是网络中各层协议的总和,其形象的反映了一个网络中文件传输的过程:由上层协议到底层协议,再由底层协议到上层协议。 1.2.1Zigbee协议规范与zigbee协议栈 Zigbee各层协议中物理层(phy)、介质控制层(mac)规范由IEEE802.15.4规定,网络层(NWK)、应用层(apl)规范由zigbee联盟推出。Zigbee联盟推出的整套zigbee规范:2005年第一版ZigBeeSpecificationV1.0,zigbee2006,zigbee2007、zigbeepro zigbee协议栈:很多公司都有自主研发的协议栈,如TI公司的:RemoTI,Z-Stack,SimpliciTI、freakz、msstatePAN 等。 1.2.2z-stack协议栈与zigbee协议栈 z-stack协议栈与zigbee协议栈的关系:z-stack是zigbee协议栈的一种具体实现,或者说是TI公司读懂了zigbee 协议栈,自己用C语言编写了一个软件—---z-stack,是由全球几千名工程师共同开发的。ZStack-CC2530-2.3.1-1.4.0软件可与TI的SmartRF05平台协同工作,该平台包括MSP430超低功耗微控制器(MCU)、CC2520RF收发器以及CC2591距离扩展器,通信连接距离可达数公里。 Z-Stack中的很多关键的代码是以库文件的形式给出来,也就是我们只能用它们,而看不到它们的具体的实现。其中核心部分的代码都是编译好的,以库文件的形式给出的,比如安全模块,路由模块,和Mesh自组网模块。与z-stack 相比msstatePAN、freakz协议栈都是全部真正的开源的,它们的所有源代码我们都可以看到。但是由于它们没有大的商业公司的支持,开发升级方面,性能方面和z-stack相比差距很大,并没有实现商业应用,只是作为学术研究而已。 还可以配备TI的一个标准兼容或专有的网络协议栈(RemoTI,Z-Stack,或SimpliciTI)来简化开发,当网络节点要求不多在30个以内,通信距离500m-1000m时用simpliciti。 1.2.3IEEE802.15.4标准概述 IEEE802.15.4是一个低速率无线个人局域网(LowRateWirelessPersonalAreaNetworks,LR-WPAN)标准。定义了物理层(PHY)和介质访问控制层(MAC)。 LR-WPAN网络具有如下特点: ◆实现250kb/s,40kb/s,20kb/s三种传输速率。 ◆支持星型或者点对点两种网络拓扑结构。 ◆具有16位短地址或者64位扩展地址。 ◆支持冲突避免载波多路侦听技术(carriersensemultipleaccesswithcollisionavoidance,CSMA/CA)。(mac层) ◆用于可靠传输的全应答协议。(RTS-CTS) ◆低功耗。 ◆能量检测(EnergyDetection,ED)。 ◆链路质量指示(LinkQualityIndication,LQI)。 ◆在2.45GHz频带内定义了16个通道;在915MHz频带内定义了10个通道;在868MHz频带内定义了1个通道。 为了使供应商能够提供最低可能功耗的设备,IEEE(InstituteofElectricalandElectronicsEngineers,电气及电子工程师学会)定义了两种不同类型的设备:一种是完整功能设备(full.functionaldevice,FFD),另一种是简化功能设备

TCPIP协议栈实践报告

《专业综合实践》 训练项目报告训练项目名称:TCP/IP协议栈

1.IP协议 IP协议是TCP/IP协议的核心,所有的TCP,UDP,IMCP,IGCP的数据都以IP数据格式传输。要注意的是,IP不是可靠的协议,这是说,IP协议没有提供一种数据未传达以后的处理机制--这被认为是上层协议--TCP或UDP要做的事情。所以这也就出现了TCP是一个可靠的协议,而UDP就没有那么可靠的区别。这是后话,暂且不提 1.1.IP协议头如图所示

挨个解释它是教科书的活计,我感兴趣的只是那八位的TTL字段,还记得这个字段是做什么的么?这个字段规定该数据包在穿过多少个路由之后才会被抛弃(这里就体现出来IP协议包的不可靠性,它不保证数据被送达),某个ip数据包每穿过一个路由器,该数据包的TTL数值就会减少1,当该数据包的TTL成为零,它就会被自动抛弃。这个字段的最大值也就是255,也就是说一个协议包也就在路由器里面穿行255次就会被抛弃了,根据系统的不同,这个数字也不一样,一般是32或者是64,Tracerouter这个工具就是用这个原理工作的,tranceroute 的-m选项要求最大值是255,也就是因为这个TTL在IP协议里面只有8bit。 现在的ip版本号是4,所以也称作IPv4。现在还有IPv6,而且运用也越来越广泛了。 1.2.IP路由选择 当一个IP数据包准备好了的时候,IP数据包(或者说是路由器)是如何将数据包送到目的地的呢?它是怎么选择一个合适的路径来"送货"的呢? 最特殊的情况是目的主机和主机直连,那么主机根本不用寻找路由,直接把数据传递过去就可以了。至于是怎么直接传递的,这就要靠ARP协议了,后面会讲到。 稍微一般一点的情况是,主机通过若干个路由器(router)和目的主机连接。那么路由器就要通过ip包的信息来为ip包寻找到一个合适的目标来进行传递,比如合适的主机,或者合适的路由。路由器或者主机将会用如下的方式来处理某一个IP数据包 如果IP数据包的TTL(生命周期)以到,则该IP数据包就被抛弃。 搜索路由表,优先搜索匹配主机,如果能找到和IP地址完全一致的目标

ZigBee协议栈OSAL介绍

讨论ZigBee协议栈的构成以及内部OSAL的工作机理。 ZigBee协议栈OSAL介绍 操作系统抽象层 OSAL常用术语: 1.资源(Resource):任何任务所占用的实体都叫资源,如变量、数组、结构体 2.共享资源(Shared Resource):两个或两个以上任务使用的资源,为防止破坏资源,任务在操作共享资源时是独占状态。 3.任务(Task):即线程,简单的程序的执行过程。任务设计时将问题尽可能分成多个任务,每个任务独立完成某项功能,同时赋予优先级、CPU寄存器和堆栈空间。一般一个任务设计为一个无限循环。 4.多任务运行(Muti-task Running):其实同一时刻只有一个任务运行。 5.内核(Kernel):内核负责管理各个任务。包括:分配CPU时间;任务调度;任务间的通信。 6.互斥(Mutual Exclusion):多任务通信最常用方法是共享数据结构。 保护共享资源常用的方法: 关中断; 使用测试并置位指令(T&S指令); 禁止任务切换; 使用信号量; 7.消息队列(Message Queue):用于任务间传递消息。 OSAL提供如下功能: 任务注册、初始化和启动; 任务间的同步、互斥; 中断处理; 储存器分配和管理; OSAL运行机理: OSAL就是一种支持多任务运行的系统资源分配机制。 OSAL是一种基于事件驱动的轮询式操作系统。、 void osal_start_system(void)是ZigBee协议栈的灵魂,不断的查看事件列表,如果有事件发生就调用相应的事件处理函数。 SYS_EVENT_MSG是一个事件集合,是由协议栈定义的事件,即系统强制事件(Mandatory Events),它的定义为: #define SYS_EVENT_MSG 0x8000; 它包含如下事件: AF_INCOMING_MSG_CMD 收到一个新的无线数据

mtcp协议栈

mTCP:A Highly Scalable User-level TCP Stack for Multicore Systems EunYoung Jeong,Shinae Woo,Muhammad Jamshed,Haewon Jeong Sunghwan Ihm*,Dongsu Han,and KyoungSoo Park KAIST*Princeton University Abstract Scaling the performance of short TCP connections on multicore systems is fundamentally challenging.Although many proposals have attempted to address various short-comings,inef?ciency of the kernel implementation still persists.For example,even state-of-the-art designs spend 70%to80%of CPU cycles in handling TCP connections in the kernel,leaving only small room for innovation in the user-level program. This work presents mTCP,a high-performance user-level TCP stack for multicore systems.mTCP addresses the inef?ciencies from the ground up—from packet I/O and TCP connection management to the application inter-face.In addition to adopting well-known techniques,our design(1)translates multiple expensive system calls into a single shared memory reference,(2)allows ef?cient?ow-level event aggregation,and(3)performs batched packet I/O for high I/O ef?ciency.Our evaluations on an8-core machine showed that mTCP improves the performance of small message transactions by a factor of25compared to the latest Linux TCP stack and a factor of3compared to the best-performing research system known so far.It also improves the performance of various popular applications by33%to320%compared to those on the Linux stack. 1Introduction Short TCP connections are becoming widespread.While large content transfers(e.g.,high-resolution videos)con-sume the most bandwidth,short“transactions”1dominate the number of TCP?ows.In a large cellular network,for example,over90%of TCP?ows are smaller than32KB and more than half are less than4KB[45]. Scaling the processing speed of these short connec-tions is important not only for popular user-facing on-line services[1,2,18]that process small messages.It is 1We refer to a request-response pair as a transaction.These transac-tions are typically small in size.also critical for backend systems(e.g.,memcached clus-ters[36])and middleboxes(e.g.,SSL proxies[32]and redundancy elimination[31])that must process TCP con-nections at high speed.Despite recent advances in soft-ware packet processing[4,7,21,27,39],supporting high TCP transaction rates remains very challenging.For exam-ple,Linux TCP transaction rates peak at about0.3million transactions per second(shown in Section5),whereas packet I/O can scale up to tens of millions packets per second[4,27,39]. Prior studies attribute the inef?ciency to either the high system call overhead of the operating system[28,40,43] or inef?cient implementations that cause resource con-tention on multicore systems[37].The former approach drastically changes the I/O abstraction(e.g.,socket API) to amortize the cost of system calls.The practical lim-itation of such an approach,however,is that it requires signi?cant modi?cations within the kernel and forces ex-isting applications to be re-written.The latter one typically makes incremental changes in existing implementations and,thus,falls short in fully addressing the inef?ciencies. In this paper,we explore an alternative approach that de-livers high performance without requiring drastic changes to the existing code base.In particular,we take a clean-slate approach to assess the performance of an untethered design that divorces the limitation of the kernel implemen-tation.To this end,we build a user-level TCP stack from the ground up by leveraging high-performance packet I/O libraries that allow applications to directly access the packets.Our user-level stack,mTCP,is designed for three explicit goals: 1.Multicore scalability of the TCP stack. 2.Ease of use(i.e.,application portability to mTCP). 3.Ease of deployment(i.e.,no kernel modi?cations). Implementing TCP in the user level provides many opportunities.In particular,it can eliminate the expen-sive system call overhead by translating syscalls into inter-process communication(IPC).However,it also in-

tcp、ip协议栈移植

This article was downloaded by: [University of Jiangnan] On: 27 March 2015, At: 06:51 Publisher: Taylor & Francis Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK Journal of Discrete Mathematical Sciences and Cryptography Publication details, including instructions for authors and subscription information: https://www.360docs.net/doc/e916828766.html,/loi/tdmc20 An abridged protocol stack for micro controller in place of TCP/IP R. Seshadri a a Computer Centre, S.V. University , Tirupati , 517 502 , India Published online: 03 Jun 2013. PLEASE SCROLL DOWN FOR ARTICLE

An abridged protocol stack for micro controller in place of TCP/IP R.Seshadri ? Computer Centre S.V .University Tirupati 517502India Abstract The existing TCP/IP protocol stack running in hosts takes lot of overhead while the node in network is for a speci?c purpose.For example transferring simple messages across network.If the node in the network is not a PC but,some thing like a micro controller,which measures some values and stores in its local memory,then it becomes lavishness in using the micro controller’s memory.As it is a node in a network,working with TCP/IP ,it should be able to transfer those values in the form of messages to other hosts which are in either local network or global network. But in micro controller terms the memory is expensive and compact.The existing TCP/IP stack consumes a few mega bytes of memory.Therefore it can’t be accommodated in the memory of micro controller.Hence one needs to reduce the memory consumption.In this regard,an abridged protocol which replaces the existing TCP/IP has been designed to suit the above needs.For this purpose,the TCP/IP have been combined with KEIL C51features for 8051micro controller to make it work in transferring messages in local area network as well as global network. The above scheme was implemented and tested and the system was working satisfac-torily.The results are found to be more effective in communicating information/message from the micro controller to a PC. Keywords :Ethernet,stack,Transmission Control Protocol (TCP ),Internet Protocol (IP ).Introduction to TCP/IP The name TCP/IP refers to a suite of communication protocols.The name is misleading because TCP and IP are the only two of the dozens of protocols that compose the suite.Its name comes from two of the most ?E-mail :ravalaseshadri@yahoo.co.in —————————————————– Journal of Discrete Mathematical Sciences &Cryptography Vol.9(2006),No.3,pp.523–536 c Taru Publications D o w n l o a d e d b y [U n i v e r s i t y o f J i a n g n a n ] a t 06:51 27 M a r c h 2015

2020年Zigbee协议栈中文说明免费

1.概述 1.1解析ZigBee堆栈架构 ZigBee堆栈是在IEEE 802.15.4标准基础上建立的,定义了协议的MAC和PHY层。ZigBee设备应该包括IEEE802.15.4(该标准定义了RF射频以及与相邻设备之间的通信)的PHY和MAC层,以及ZigBee堆栈层:网络层(NWK)、应用层和安全服务提供层。图1-1给出了这些组件的概况。 1.1.1ZigBee堆栈层 每个ZigBee设备都与一个特定模板有关,可能是公共模板或私有模板。这些模板定义了设备的应用环境、设备类型以及用于设备间通信的簇。公共模板可以确保不同供应商的设备在相同应用领域中的互操作性。 设备是由模板定义的,并以应用对象(Application Objects)的形式实现(见图1-1)。每个应用对象通过一个端点连接到ZigBee堆栈的余下部分,它们都是器件中可寻址的组件。 图1-1 zigbe堆栈框架 从应用角度看,通信的本质就是端点到端点的连接(例如,一个带开关组件的设备与带一个或多个灯组件的远端设备进行通信,目的是将这些灯点亮)。 端点之间的通信是通过称之为簇的数据结构实现的。这些簇是应用对象之间共享信息所需的全部属性的容器,在特殊应用中使用的簇在模板中有定义。图1-1-2就是设备及其接口的一个例子:

图1-1-2 每个接口都能接收(用于输入)或发送(用于输出)簇格式的数据。一共有二个特殊的端点,即端点0和端点255。端点0用于整个ZigBee设备的配置和管理。应用程序可以通过端点0与ZigBee 堆栈的其它层通信,从而实现对这些层的初始化和配置。附属在端点0的对象被称为ZigBee设备对象 (ZD0)。端点255用于向所有端点的广播。端点241到254是保留端点。 所有端点都使用应用支持子层(APS)提供的服务。APS通过网络层和安全服务提供层与端点相接,并为数据传送、安全和绑定提供服务,因此能够适配不同但兼容的设备,比如带灯的开关。APS使用网络层(NWK)提供的服务。NWK负责设备到设备的通信,并负责网络中设备初始化所包含的活动、消息路由和网络发现。应用层可以通过ZigBee设备对象(ZD0)对网络层参数进行配置和访问。 1.1.2 80 2.15.4 MAC层 IEEE 802.15.4标准为低速率无线个人域网(LR-WPAN)定义了OSI模型开始的两层。PHY层定义了无线射频应该具备的特征,它支持二种不同的射频信号,分别位于2450MHz波段和868/915MHz 波段。2450MHz波段射频可以提供250kbps的数据速率和16个不同的信道。868 /915MHz波段中,868MHz支持1个数据速率为20kbps的信道,915MHz支持10个数据速率为40kbps的信道。MAC层负责相邻设备间的单跳数据通信。它负责建立与网络的同步,支持关联和去关联以及MAC 层安全:它能提供二个设备之间的可靠链接。 1.1.3 关于服务接入点 ZigBee堆栈的不同层与802.15.4 MAC通过服务接入点(SAP)进行通信。SAP是某一特定层提供的服务与上层之间的接口。 ZigBee堆栈的大多数层有两个接口:数据实体接口和管理实体接口。数据实体接口的目标是向上层提供所需的常规数据服务。管理实体接口的目标是向上层提供访问内部层参数、配置和管理数据的机制。 1.1.4 ZigBee的安全性 安全机制由安全服务提供层提供。然而值得注意的是,系统的整体安全性是在模板级定义的,这意味着模板应该定义某一特定网络中应该实现何种类型的安全。 每一层(MAC、网络或应用层)都能被保护,为了降低存储要求,它们可以分享安全钥匙。SSP是通过ZD0进行初始化和配置的,要求实现高级加密标准(AES)。ZigBee规范定义了信任中心的用

ZigBee测试与协议分析

ZigBee测试与协议分析 1 前言 ZigBee协议栈包括物理层协议(IEEE802.15.4)和上层软件协议(ZigBee 2007以及其他的ZigBee网络协议)。本文将从这两方面来了解这些协议,通过介绍如何捕获及如何理解关键参数,深层次剖析ZigBee技术。有了这些本质性的认识,对于分析解决无线产品应用问题,会有很大的帮助。 2 物理层分析 ZigBee的物理层为IEEE802.15.4标准所规定,定义了ZigBee底层的调制编码方式。这些规约大多是芯片设计者需要关心的,对于应用开发来说,更关心的是衡量一个芯片、一个射频系统性能的参数。在过去的文章中,已介绍了输出功率、接收灵敏度和链路预算等参数,这一讲将更深入地介绍一个调制质量的参数:EVM。EVM指的是误差向量(包括幅度和相位的矢量),表征在一个给定时刻理想无误差基准信号与实际发射信号的向量差,。从EVM参数中,可以了解到一个输出信号的幅度误差及相位误差。 EVM是衡量一个RF系统总体调制质量的指标,定义为信号星座图上测量信号与理想信号之间的误差,它用来表示发射器的调制精度,调制解调器、PA、混频器、收发器等对它都会有影响。EVM数据和眼图。 了解完这个参数之后,再看看实际测试中是如何获取EVM参数的。 ZigBee物理层的测试,在产品研发、生产和维护阶段,可以分别采用不同的仪器。 (1)产品研发阶段要测量EVM参数,需要使用带协议解析的频谱仪,最好是自带相应协议插件的仪器,可以使用安捷伦PXA N9030A频谱分析仪+8960B插件(选配了ZigBee分析插件)。这些仪器可以测试出ZigBee调制信号的星座图、实时数据和眼图等信息,在芯片级开发过程中,需要考量高频电容电感以及滤波器等的单个及组合性能,特别需要注意的是ZigBee信号的临道抑制参数,利用PXA N9030A的高分辨率,可以查看点频的带外信号,这些细节在更换射频器件供应商时,需要仔细测量,一般数字电路抄板比较容易,因为器件性能的影响不是很大,只要值和封装对了就可以,但是射频前端的设计上,即使原样的封装、容值和感值,供应商不一样,射频参数也是不一样的,板材的选用也极大地影响着阻抗匹配,因此复制和再开发都有较大难度。合格的测试工具,加上有质量保证的射频器件供应商资源,方能真正具备RF设计能力。安捷伦PXA N9030A频谱分析仪。 (2)批量生产阶段在批量生产中,不可能将实验室的研发测试仪器搬到工厂,因此,需要便携小巧的测试设备,这时可用罗德与斯瓦茨公司的热功率探头,如NRP-Z22,做一个2.4 GHz的输出功率测试,保证能够输出公差允许的功率信号即可,因为在生产中,射频器件的焊接不良、馈线连接头的接触不良,都会造成输出功率的下降甚至消失。需要注意的是,探头非常容易被静电损坏,必须要带上防静电手套进行操作,返修过程如需要经过德国,则时间长,经费也不便宜,不是很严重的损坏倒是可以在深圳维修中心处理。NRP-Z22。 (3)应用阶段在现场出现问题时,ZigBee节点已经安装到现场,不能逐一拆下来测试,并且周围的电磁环境也是没办法在单个节点上检测到,这时就需要手持式的频谱仪进行现场勘查了,例如安捷伦公司的N9912A手持式频谱仪。使用该频谱仪,可以完成无线系统设计初期的现场勘查工作,检测现场各个地点是否有异常电磁干扰,对于ZigBee来说,当然是检测是否有持续的WIFI信号干扰了。同时,更为详细的现场勘查,还包括在定点进行数据发送,预期覆盖点进行信号强度分析,以实地评估墙体等障碍物的信号衰减,在已经架设好的ZigBee网络中,也可以检测信号覆盖,数据通信是否正常等。N9912A。

TCPIP协议栈

TCP/IP协议族 IPv4包 UDP包 UDP的伪首部(根据IP数据包的内容建立) UDP校验和覆盖的内容超出了UDP数据报本身的X围。计算校验和,先把零值赋予校验和字段,然后对整个对象,包括伪首部、UDP的首部和用户数据,算出一个16比特的二进制

TCP包 TCP的伪首部(根据IP数据包的内容建立) 三次握手报文序列 在网点1的事件网络报文在网点2的事件 发送SYN seq=x 接收SYN报文段 发送SYN seq=y,ACK x+1

接收SYN+ACK报文段 发送ACK y+1 接收ACK报文段 TCP连接关闭的三次握手 在网点1的事件网络报文在网点2的事件 (应用程序关闭连接) 发送FIN seq=x 接收FIN报文段 发送ACK x+1 接收ACK报文段 发送FIN seq=y,ACK x+1 接收FIN+ACK报文段 发送ACK y+1 接收ACK报文段 IPv6 IPv6是“Internet Protocol Version 6”的缩写,它是IETF设计的用于替代现行版本IP协议-IPv4-的下一代IP协议。IPv6采用了分级地址模式、高效IPXX、服务质量、主机地址自动配置、认证和加密等许多技术。

IPv4和IPv6的主要差别 IPv6包结构 IPv6包由IPv6XX、扩展XX和上层协议数据单元三部分组成:

IPv6XX Version(4bit) Traffic Class(8bit) Flow Label(20bit) Payload Length(16bit) Next Header(8bit) Hop Limit(8bit) Source IP address (128bit) Destination IP address (128bit) 附:常用的Next Header 字段值表 扩展头 一个典型的IPv6包,没有扩展头。仅当需要路由器或目的节点做某些特殊处理时,才由发送方添加一个或多个扩展头。与IPv4不同,IPv6扩展头长度任意,不受40字节限制,但是为了提高处理选项头和传输层协议的性能,扩展头总是8字节长度的整数倍。 目前,RFC 2460中定义了以下6个IPv6扩展头: 1)Hop-by-Hop选项XX 包含分组传送过程中,每个路由器都必须检查和处理的特殊参数选项。Hop-by-Hop选 项XX中的选项描述一个分组的某些特性或用于提供填充。这些选项有: Pad1选项(选项类型为0),填充单字节。

从Zigbee协议栈底层添加自己的按键配置

本实验是基于ZStack-CC2530-2.5.1a版本的协议栈来进行实验的,整个实验需要改动 hal_board_cfg.h、hal_board_cfg.h、hal_key.c、hal_key.h和自己定义的Coordinator.c这5个文件。 注意:添加自己的按键时尽量不要修改协议栈里面的按键程序,自己另行添加即可。 1、hal_key.h 在/* Switches (keys) */下面添加自己的按键定义 #define HAL_KEY_SW_8 0x80 图1: ---------------------------------------------------------------------------------------- 2、hal_board_cfg.h 在/* S6 */ #define PUSH1_BV BV(1) #define PUSH1_SBIT P0_1 #if defined (HAL_BOARD_CC2530EB_REV17) #define PUSH1_POLARITY ACTIVE_LOW #elif defined (HAL_BOARD_CC2530EB_REV13) #define PUSH1_POLARITY ACTIVE_LOW #else #error Unknown Board Indentifier #endif 下面模仿/* S6 */下的程序定义自己的按键值: /* S8 */ #define PUSH8_BV BV(4)//修改 #define PUSH8_SBIT P0_4//修改 #if defined (HAL_BOARD_CC2530EB_REV17)

zigbee协议栈代码主要名词解释

zigbee协议重要名词解释及英文缩写(转载)网络层功能: 1. 加入和退出网络 2. 申请安全结构 3. 路由管理 4. 在设备之间发现和维护路由 5. 发现邻设备 6. 储存邻设备信息 当适当的重新分配地址联合其他设备,ZIGBEE2006可以依赖于网络协调者建立一个新网络. ZIGBEE应用层由APS(应用支持)、AF(应用结构)、ZDO(ZIGBEE设备对象)和厂商自定义应用对象组成。 APS功能 1. 绑定维持工作台,定义一个两个合拢的设备进行比较建立他们的需要和服务。 2. 促进信息在设备之间的限制 3. 组地址定义,移除和过滤组地址消息 4. 地址映射来自于64位IEEE地址和16位网络地址 5. 分裂、重新组装和可靠数据传输 ZDO功能 1. 定义设备内部网络(ZigBee协调者和终端接点) 2. 开始和/或回答绑定请求 3. 在网络设备中建立一个网络安全关系 4. 在网络中发现设备和决定供给哪个应用服务 ZDO同样有责任在网络中发现设备和为他们提供应用服务。 1.1.4 网络拓扑 ZIGBEE网络层支持星状、树状和网状拓扑。在星状拓扑中网络受约束与单个设备,呼叫COORD。COORD有责任建立和维持在网络中发现的设备和其他所有设备,都知道的终端接点直接和COORD 通信。在网状和树状拓扑中,COORD有责任建立一个网络和选择几个关键网络参数,但是网络有有可能直接应用于ZigBee路由器。在树状网络中,利用分等级路由策略完成路由传输数据和控制消息直通网络。树状网络在802.15.4-2003中可以采用信标引导通信。网状网络将允许所有对等网络通信。ZIGBEE 路又将不能在网状网络中发射规则的IEEE802.15.4-2003信标。

TI_zigbee协议栈结构分析应用

无线盛世《快速进入ZB世界》
Ver:1

进入Zigbee世界的准备工作
§ 首先,我们需具备一些硬件设备及平台。以下 我就罗列一下Zigbee开发基本工具: § 计算机:不管是设计电路还是编程开发都是离 不开它的。 § Zigbee开发板:对于初学者来说,Zigbee开发 板无疑是最佳选择。有了开发板,你可以在我 们成熟设计的基础上学习或者做自己的设计。 § Zigbee模块:集MCU,RF,天线设计于一体 的Zigbee模块。使用它,我们可省去设计天线 及IC周边电路设计的复杂工作。

进入Zigbee世界的准备工作
§ Zigbee仿真器:是集烧写程序、在线编程和在线仿真 功能于一身的开发过程工作中必不可少的开发工具。 编程器既能对CC243x芯片(其实包括TI产品中的CC 系列的大部分芯片)进行烧写程序(hex标准文件程序 ),也能对CC243x芯片进行在线编程和仿真,让我们 能方便地在线调试开发,从而大大地提高了开发效率 。 § Zigbee协议分析仪:ZigBee的设计开发者必不可少的 工具!ZigBee协议分析仪具有广泛的功能,包括:分 析以及解码在PHY、MAC、NETWORK/SECURITY、 APPLICATION FRAMEWORK、和APPLICATION PROFICES等各层协议上的信息包;显示出错的包以 及接入错误;指示触发包;在接收和登记过程中可连 续显示包。

进入Zigbee世界的准备工作
§ 再次,我们需要在将用于开发Zigbee的计 算机平台上安装这些软件: § Zigbee协议分析软件(sniffer) § 程序烧写软件(Flash Programmer) § IAR公司的EW8051 version 7.20I/W32 。

TCPIP协议栈实践报告

《专业综合实践》 训练项目报告 训练项目名称:TCP/I P 协议栈 1、IP 协议 IP 协议就是TCP/IP 协议得核心,所有得TCRUDPJMCP, I GCP 得数据都 以IP 数据格式传输。要注意得就是,IP 不就是可靠得协议,这就是说,I P 协议 没有提供一种数据未传达以后得处理机制一一这被认为就是上层协议一一TCP 或UDP 要做得事情。所以这也就出现了 TCP 就是一个可靠得协议,而UDP 就 没有那么可靠得区别。这就是后话,暂且不提 1、1、IP 协议头如图所示 挨个解释它就是教科书得活计,我感兴趣得只就是那八位得TT L 字段,还记 得这个字段就是做什么得么?这个字段规定该数据包在穿过多少个路山之后才 会被抛弃(这里就体现出来I P 协议包得不可靠性,它不保证数据被送达),某个 ip 数据包每穿过一个路III 器,该数据包得TTL 数值就会减少1,当该数据包得T TL 成为零,它就会被自动抛弃。这个字段得最大值也就就是2 5 5,也就就是说 一个协议包也就在路由器里面穿行2 55次就会被抛弃了,根据系统得不同,这个 数字也不一样,一般就是32或者就是64, T r acero ute r 这个工具就就是用这个 原理丄作得,trancer o ute 得-m 选项要求最大值就是25 5,也就就是因为这个T TL 在IP 协议里面只有8b i to 现在得ip 版本号就是4,所以也称作IPv 4。现在还有IPv 6 ,而且运用也 越来越广泛了。 1、2、IP 路由选择 当一个IP 数据包准备好了得时候,IP 数据包(或者说就是路111器)就是如何 将数据包送到LI 得地得呢?它就是怎么选择一个合适得路径来”送货“得呢? 最特殊得情况就是U 得主机与主机直连,那么主机根本不用寻找路山,直接 把数 ii 恤如紀伯 字方

相关文档
最新文档