2007年9月26日星期三

Memory partition in C program

/* Memory Layout of a C Program */



  • 正文段。C P U执行的机器指令部分。通常,正文段是可共享的,所以即使是经常执行的程序(如文本编辑程序、C编译程序、s h e l l等)在存储器中也只需有一个副本,另外,正文段常常是只读的,以防止程序由于意外事故而修改其自身的指令。
  • 初始化的数据段。通常将此段称为数据段,它包含了程序中需赋初值的变量。初始化的全局变量和静态变量存放在这里。例如,C程序中任何函数之外的说明:int maxcount = 99; 使此变量以初值存放在初始化数据段中。
  • 非初始化数据段。通常将此段称为b s s段,这一名称来源于早期汇编程序的一个操作符,意思是“block started by symbol(由符号开始的块)”,未初始化的全局变量和静态变量存放在这里。在程序开始执行之前,内核将此段初始化为0。函数外的说明:long sum[1000] ; 使此变量存放在非初始化数据段中
  • 。需要由程序员分配、释放,若程序员不释放,程序结束时可能由OS回收。通常在堆中进行动态存储分配。
  • 。由编译器自动分配、释放。局部变量及每次函数调用时返回地址、以及调用者的环境信息(例如某些机器寄存器)都存放在栈中。新被调用的函数在栈上为其自动和临时变量分配存储空间。通过以这种方式使用栈,C函数可以递归调用。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

C++中的默认初始化:

如果没有提供初始式,
  • 全局的、名字空间的和局部静态的对象(统称静态对象)将被自动初始化为适当类型的0。(非初始化数据段中???)
  • 局部对象(自动对象)和在自由存储区里建立的对象(动态对象或堆对象)将不会用默认值做初始化。
  • 数组和结构的成员,也根据数组或结构是否为静态来确定是否默认地进行初始化
  • 用户定义类型可以有自定义的默认初始化方式。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

对于x86处理器上的Linux,正文段从0x08048000单元开始,栈底在0xC0000000之下开始(栈由高地址向低地址方向增长)。堆顶和栈底之间未用的虚拟空间很大。



(转载)

堆与栈的区别由以下几点:

管理方式:对于栈来讲,是由编译器自动管理,无需我们手工控制;对于堆来说,释放工作由程序员控制,容易产生memory leak。

空间大小:一般来讲在32位系统下,堆内存可以达到4G的空间,从这个角度来看堆内存几乎是没有什么限制的。但是对于栈来讲,一般都是有一定的空间大小的,例如,在VC6下面,默认的栈空间大小是1M。

碎片问题:对于堆来讲,频繁的new/delete势 必会造成内存空间的不连续,从而造成大量的碎片,使程序效率降低。对于栈来讲,则不会存在这个问题,因为栈是先进后出的队列,他们是如此的一一对应,以至 于永远都不可能有一个内存块从栈中间弹出,在他弹出之前,在他上面的后进的栈内容已经被弹出,详细的可以参考数据结构,这里我们就不再一一讨论了。

生长方向:对于堆来讲,生长方向是向上的,也就是向着内存地址增加的方向;对于栈来讲,它的生长方向是向下的,是向着内存地址减小的方向增长

分配方式:堆都是动态分配的,没有静态分配的堆。栈有2种分配方式:静态分配和动态分配。静态分配是编译器完成的,比如局部变量的分配。动态分配由alloca函数进行分配,但是栈的动态分配和堆是不同的,他的动态分配是由编译器进行释放,无需我们手工实现。

分配效率:栈是机器系统提供的数据结构,计算机会在底层对栈提供支持:分配专门的寄存器存放栈的地址,压栈出栈都有专门的指令执行,这就决定了栈的效率比较高。堆则是C/C++函数库提供的,它的机制是很复杂的,例如为了分配一块内存,库函数会按照一定的算法(具体的算法可以参考数据结构/操作系统)在堆内存中搜索可用的足够大小的空间,如果没有足够大小的空间(可能是由于内存碎片太多),就有可能调用系统功能去增加程序数据段的内存空间,这样就有机会分到足够大小的内存,然后进行返回。显然,堆的效率比栈要低得多。

从这里可以看到,堆和栈相比,由于大量new/delete的使用,容易造成大量的内存碎片;由于没有专门的系统支持,效率很低;由于可能引发用户态和核心态的切换,内存的申请,代价变得更加昂贵。所以栈在程序中是应用最广泛的,就算是函数的调用也利用栈去完成,函数调用过程中的参数,返回地址,EBP和局部变量都采用栈的方式存放。所以,我们推荐大家尽量用栈,而不是用堆。

虽然栈有如此众多的好处,但是由于和堆相比不是那么灵活,有时候分配大量的内存空间,还是用堆好一些。无论是堆还是栈,都要防止越界现象的发生,因为越界的结果要么是程序崩溃,要么是摧毁程序的堆、栈结构,产生以想不到的结果.


(转载)

2007年9月22日星期六

Why need Three-way handshake in TCP

握手的第一个报文段可以通过码元字段的SYN比特置1来识别。
第二个报文的码元字段的SYN和ACK比特均置1,指出这是对第一个SYN报文段的确认并继续握手操作。
最后一个握手报文仅仅是一个确认信息,通知目的主机已成功建立了双方所同意的这个连接。







三次握手协议是连接的两端正确同步的充要条件:
因为TCP建立在不可靠的分组交付服务之上,报文可能出现丢失、延迟、重复和乱序的情况,因而协议必须使用超时机制,重传丢失的连接请求。
如果重传的连接请求和原先的连接请求在连接正在建立时到达,或是当一个连接已经建立、使用和结束之后,某个被延迟的连接请求才到达,都会出现麻烦。
三次握手协议(加上这样的规则:在连接建立以后TCP不再理睬又一次的连接请求)就能解决这些问题。

2007年9月21日星期五

Character Pointers and Character Arrays

字符指针和字符数组

Example:

char *GetString1 (void)
{
char *p = "test";
return p;
}

char *GetString2 (void)
{
char p[] = "test";
return p;
}

int main ()
{
char *str1 = NULL;
char *str2 = NULL;

str1 = GetString1();
str2 = GetString2();

printf("using 'char *' str1 is: %s\n", str1);
printf("using 'char []' str2 is: %s\n", str2);

return 0;
}

Result:
using 'char *' str1 is: test
using 'char []' str2 is: ..... (乱码)

解释:
在main函数中,str1和str2两个指针都已经不为空。
GetString1中使用了字符指针,而其指向的内容是放在程序的常量区的。所以在main函数中可以正常访问到指针所指向的空间。
GetString2中使用了字符数组,在函数内部的声明使其内容存放在栈上。所以在main函数中实体str2所指向的空间在GetString2退出时已经被释放,所以访问到的内容会是乱码。

/*在函数中返回局部定义的指针是可行的,关键是要判断返回的指针当我们在访问它时其指向的 内存空间是否还有效。不要用return语句返回指向“栈内存”的指针(可以返回指向堆的指针或指向静态存储区的指针)*/

(转载)

1.以字符串形式出现的,编译器都会为该字符串自动添加一个0作为结束符,如在代码中写
"abc",那么编译器帮你存储的是"abc\0"

2."abc"是常量吗?答案是有时是,有时不是。

不是常量的情况:"abc"作为字符数组初始值的时候就不是,如
char str[] = "abc";
因为定义的是一个字符数组,所以就相当于定义了一些空间来存放"abc",而又因为字符数组就是把字符一个一个地存放的,所以编译器把这个语句解析为
char str[3] = {'a','b','c'};
又根据上面的总结1,所以char str[] = "abc";的最终结果是
char str[4] = {'a','b','c','\0'};
做一下扩展,如果char str[] = "abc";是在函数内部写的话,那么这里的"abc\0"因为不是常量,所以应该被放在栈上。

是常量的情况: 把"abc"赋给一个字符指针变量时,如
char* ptr = "abc";
因为定义的是一个普通指针,并没有定义空间来存放"abc",所以编译器得帮我们找地方来放"abc",显然,把这里的"abc"当成常量并把它放到程序的常量区是编译器最合适的选择。所以尽管ptr的类型不是const char*,并且ptr[0] = 'x';也能编译通过,但是执行ptr[0] = 'x';就会发生运行时异常,因为这个语句试图去修改程序常量区中的东西。

记得哪本书中曾经说过char* ptr = "abc";这种写法原来在c++标准中是不允许的,但是因为这种写法在c中实在是太多了,为了兼容c,不允许也得允许。虽然允许,但是建议的写法应该是const char* ptr = "abc";这样如果后面写ptr[0] = 'x'的话编译器就不会让它编译通过,也就避免了上面说的运行时异常。又扩展一下,如果char* ptr = "abc";写在函数体内,那么虽然这里的"abc\0"被放在常量区中,但是ptr本身只是一个普通的指针变量,所以ptr是被放在栈上的,只不过是它所指向的东西被放在常量区罢了

3.数组的类型是由该数组所存放的东西的类型以及数组本身的大小决定的。如char s1[3]和char s2[4],s1的类型就是char[3],s2的类型就是char[4],也就是说尽管s1和s2都是字符数组,但两者的类型却是不同的。

4.字符串常量的类型可以理解为相应字符常量数组的类型,如"abcdef"的类型就可以看成是const char[7]

5.sizeof是用来求类型的字节数的。如int a; 那么无论sizeof(int)或者是sizeof(a)都是等于4,因为sizeof(a)其实就是sizeof(type of a)

6.对于函数参数列表中的以数组类型书写的形式参数,编译器把其解释为普通的指针类型,如对于void func(char sa[100],int ia[20],char *p) 则sa的类型为char*,ia的类型为int*,p的类型为char*

7.根据上面的总结,来实战一下:
对于char str[] = "abcdef";就有sizeof(str) == 7,因为str的类型是char[7],
也有sizeof("abcdef") == 7,因为"abcdef"的类型是const char[7]。
对于char *ptr = "abcdef";就有sizeof(ptr) == 4,因为ptr的类型是char*。
对于char str2[10] = "abcdef";就有sizeof(str2) == 10,因为str2的类型是char[10]。
对于void func(char sa[100],int ia[20],char *p); 就有sizeof(sa) == sizeof(ia) == sizeof(p) == 4,
因为sa的类型是char*,ia的类型是int*,p的类型是char*。

(转载)

Example:
(strdup的作用)

char *str = (char *) malloc(n * sizeof(char));
str = "this is test";
free(str); //has error, may be cause kernel panic

str = strdup("this is test");
free(str); //ok


解释:因为是字符串常量,所以被存储在静态存储区。而这个区域的内存是不可以修改的

2007年9月17日星期一

Big/Little endian, union, bitfield

大端小端模式、union、位域

Example:

union s {
struct x {
unsigned int x1:2;
unsigned int x2:3;
unsigned int x3:3;
}x;

char y;
};

int main ()
{
union s test;

test.y = 100;

printf("x1: %d\n", test.x.x1);
printf("x2: %d\n", test.x.x2);
printf("x3: %d\n", test.x.x3);

return 0;
}

Result:
x1: 0
x2: 1
x3: 3
注意: 本例中union的大小只有一个字节,所以这里不涉及到大端和小端的问题。只涉及到union中成员的存放顺序问题(见下面的解释)


(转载)
试题1:请写一个C函数,若处理器是Big_endia的,则返回;若是Little_endian的,则返回1
解答:
int checkCPU( )
{
union w {
int a;
char b;
} c;

c.a = 1;
return(c.b ==1);
}

剖析: 嵌入式系统开发者应该对Little-endian和Big-endian模式非常了解。采用Little-endian模式的CPU对操作数的存放方式是从低字节到高字节,而Big-endian模式对操作数的存放方式是从高字节到低字节。

例如,16bit宽的数0x1234
在Little-endian模式CPU内存中的存放方式(假设从地址0x4000开始存放)为:
————————————————————————
内存地址 0x4000 0x4001
————————————————————————
存放内容 0x34 0x12
————————————————————————

而在Big-endian模式CPU内存中的存放方式则为:
————————————————————————
内存地址 0x4000 0x4001
————————————————————————
存放内容 0x12 0x34
————————————————————————

32bit宽的数0x12345678
在Little-endian模式CPU内存中的存放方式(假设从地址0x4000开始存放)为:
————————————————————————————
内存地址 0x4000 0x4001 0x4002 0x4003
————————————————————————————
存放内容 0x78 0x56 0x34 0x12
————————————————————————————

而在Big-endian模式CPU内存中的存放方式则为:
————————————————————————————
内存地址 0x4000 0x4001 0x4002 0x4003
————————————————————————————
存放内容 0x12 0x34 0x56 0x78
————————————————————————————

联合体union的存放顺序是所有成员都从低地址开始存放,面试者的解答利用该特性,轻松地获得了CPU对内存采用Little-endian还是Big-endian模式读写。如果谁能当场给出这个解答,那简直就是一个天才的程序员。
(转载)

2007年9月12日星期三

你这"该死的"CVS

今天在CVS上面出了个问题,我提交的版本把别人以前的修改都给覆盖了,怎么会出现这种错误我到现在也还没弄明白,真不知道当时自己做了什么操作竟然会出现这种矛盾的commit(既提交了新的内容同时又改回了一些旧的内容)。真是百思不得其解!

总之,现在总结几条以后操作中的注意事项:

1. 每次提交自己的修改前,用 cvs diff 查看一下要提交的内容是不是就是自己刚刚修改过的内容,有没有其他不相关的内容将被提交上去!!!

2. 涉及到branch和带 tag 的文件时一定要小心,尽量不要用 cvs update -A .... 来解决问题

3. ( to be continue)

TR064: LAN-Side DSL CPE Configuration

/*
*A summary of TR064 during my projects
*/


官方Abstract:
This Working Text will specify the method for configuring DSL CPE through software on PCs inside the LAN.

最新的TR-064技术报告:
TR-064
http://www.dslforum.org/techwork/tr/TR-064.pdf

TR-133 DSLHomeTM TR-064 Extensions for Service Differentiation
http://www.dslforum.org/techwork/tr/TR-133.pdf



+++ Introduction +++

As residential gateways offer increasingly complex services, customer premise installation and configuration increase the operators' operational costs. DSL Forum's LAN-Side DSL CPE Configuration protocol, known as TR-064, provides a zero-touch solution for automating the installation and configuration of gateways from the LAN side.

/* Summary of LAN-side Configuration Interface */
  • Management Protocol - standards based XML over SOAP protocol
  • Parameter Model - Parameters defined using UPnP model as base, disallowing values and parameters that are inconsistent with DSL model, and adding objects as needed for DSL CPE.
  • Security - HTTP Digest Authentication; optional SSL 3.0 or TLS 1.0 encryption.
  • CPE Type - Supports Bridge/Router/PPPoE on-board IP pass-thru CPEs.
  • Management Usage - CPE turn-up, status determination, monitoring, diagnostics.
  • CPE discovery - Standards-based DHCP and SSDP device discovery.
  • OS support - CPE management app with integrated XML over SOAP stack to operate on any OS, native XML/SOAP OS support is not required or desired.
This Device Control Protocol (DCP) is compliant with UPnP Device Architecture 1.0 (UDA).




+++ Discovery +++

TR064 use Simple Service Discovery Protocol (SSDP) to discover LAN devices.
SSDP: http://quimby.gnus.org/internet-drafts/draft-cai-ssdp-v1-03.txt

关于SSDP协议的具体内容可以参考UPnP的其他相关文档
/*
The Simple Service Discovery Protocol (SSDP) provides a mechanism
where by network clients, with little or no static configuration,
can discover network services. SSDP accomplishes this by providing
for multicast discovery support as well as server based notification
and discovery routing.
*/

1. When started the CPE MUST broadcast SSDP discovery advertisement (NOTIFY) messages as specified in the UDA. In summary, the requirements are as follows:
  • Three announcements for the root device
  • Two announcements for each embedded device
  • One announcement for each service type in each device
  • Each announcement specifies a lease time; each of the above announcements must be re-sent prior to the expiry of the lease.
2. When started the CPE management application MUST broadcast a SSDP discovery request message (M-SEARCH) with a specific embedded device Search Type of “ST: urn:dslforum-org:device:InternetGatewayDevice:1” so that only the DSL CPE will respond.

3. CPE Discovery and Communications




+++ Security +++

Security is important in order to protect CPE from intentional or unintentional misconfiguration. The main objective is to provide authentication in order to prevent unauthorized configuration.

1. Access Restriction
Access to any action that allows configuration changes to the CPE MUST be password protected.

2. Authentication
Access to any password-protected action MUST require HTTP digest authentication.

3. Password Initialization
Two distinct states are defined for the CPE with respect to authentication: Factory state and Normal state. The Factory state is defined to allow the ConfigPassword to be set for the first time without requiring the user to have knowledge of some other password to do so.

4. Encryption
Access to the LANConfigSecurity service SHOULD occur over an encrypted https link using either SSL 3.0 or TLS 1.0.

5. Co-existence with UPnP IGD
If the CPE implements both UPnP IGD and DSL CPE Management, it may share protocol stacks and information models but the DSL CPE management method MUST be secured as described in the above sections. This approach provides the flexibility to allow UPnP IGD to operate as-is while also providing the security required for CPE configuration management.

The use of the URN prefix “dslforum-org” for this DCP indicates the following differences from the standard UPnP gateway IGD DCP:
• Actions marked as secure will be authenticated using HTTP digest authentication.
• Variables defined within this document(TR-064 technical report) have no defined events.
• The services in this DCP exist in the DSL Forum schema namespace so that non-IGD variables and services do not require the X_ prefix.




+++ Protocols +++
  • The HTTP protocol is also required to support an HTML based CPE management GUI.
  • Management and monitoring of CPE parameters and status is conveyed using XML. XML is a flexible text based format to describe the services supported on a CPE and the parameters and values which can be read or written. However, XML is almost free-form and therefore a standard schema must be defined for its use. For this purpose, the Simple Object Action Protocol (SOAP) [3] protocol is used so that messages can be constructed to define actions to perform along with associated parameters and responses which contain status and return parameters. So, SOAP is like a message based remote procedure call.
  • SSDP is used for device discovery if the CPE IP address is unknown or misconfigured. SSDP provides the means to discover and identify the CPE and services.
  • The CPE Management Application uses multicast HTTP over UDP to send a SSDP discovery request message to the LAN to discover the CPE.
  • The CPE then uses a HTTP over UDP message to send the SSDP discovery request response back to the Management Application.




+++ XML Parameters +++


UPnP devices and services are shown in black (solid line). New services that are defined in this document are shown in blue (dashed line).



Complex action sequences (e.g read-modify-write sequences) SHOULD make use of a locking mechanism. Before the first action in a logical series, the Control Point SHOULD issue the ConfigurationStarted action, which initiates a lock. After the sequence of actions is complete, the Control Point MUST issue the ConfigurationFinished action, which frees the lock.

The Control Point MUST generate a unique session ID, which it passes as an argument to the CPE in the ConfigurationStarted action.

A uniform structure is utilized in defining new Tables for access via the LAN CPE configuration Management. Each table is REQUIRED to identify the KEY, which is a variable or set of variables that uniquely identify the row in the table.

Layer3Forwarding service allows the handling of the routing and forwarding configuration of the device.

QueueManagement Service contains queue management functions including classification, queuing, policing, and application-specific flows. This service enables the ability to read and set the current classification and hierarchical queuing settings. This service is required for TR-059 compliance.

Layer2Bridging service specifies layer-2 bridges between LAN and/or WAN interfaces. Bridges can be defined to include layer-2 filter criteria to selectively bridge traffic between interfaces.

LANDevice:
A LANDevice corresponds to a physically attached network to the DSL CPE; each LANDevice has at most one MAC address.



In this example, 4 Ethernet ports and 1 wireless interface are bridged together on one physiacal network. All attached clients would receive IP addresses in the same subnet, and no routing is required in order for these ports to pass traffic to one another. This device would have 1 LANDevice that contains 1 WLANConfiguration service and 1 LANEthernetInterfaceConfig service. The IP interfaces table in LANHostConfigManagmenet would have exactly 1 entry to indicate the IP address of the LAN interface of the gateway.

Note that there may be more than one LANEthernetInterfaceConfig service within a given LANDevice if required. For example, 2 LANInterfaces with 2 different bit rates would require 2 services.



This device supports one physically attached network through the Ethernet hub and another physically attached network through the wireless interface. Traffic from one network must be routed through the gateway to communicate with devices on the other. Modeling this CPE requires 2 LANDevices: one with an LANEthernetInterfaceConfig service and one with a WLALANHostConfigManagement service. The LANHostConfigManagement service on each LANDevice has exactly 1 entry in the IPInterfaces table to dicate the IP address of the LAN interface of the gateway.



This device has 2 Ethernet ports that comprise a managed switch. In this configuration, each port is modelled by a separate LANEthernetInterfaceConfig service within a single LAN device. This configuration allows for management of each individual Ethernet port.



This device has 2 Ethernet ports supporting 2 separate attached physical networks with 2 separate IP pools. As above, these would be modelled with 2 LANDevices, each with a LANEthernetInterfaceConfig service.

In addition, the network on the left is setup as a VLAN, combining two different address ranges together into a single physical LAN. In the LANHostConfigManagement service of that LANDevice, the IP interfaces table contains two entries corresponding to the 2 IP addresses of the VLAN.


+++ User Cases +++






+++ Concurrency Diagrams +++

The first diagram represents the scenario in which Control Point one is making changes to the CPE and does not need a reboot to commit the changes.



The next diagram represents the scenario in which the CPE must reboot to apply the changes.



The next diagram illustrates the timeout for a CPE that requires no reboot:




+++ Queuing and Bridging +++

The queuing and bridging model for an Internet Gateway Device. This model relates to the QueueManagement object as well as the Layer2Bridging and Layer3Forwarding objects.





//to be continue

2007年9月9日星期日

SOAP's Not soap

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SOAP规范:
http://www.w3.org/TR/soap/

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


DHCP

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

RFC2131 - Dynamic Host Configuration Protocol
http://www.ietf.org/rfc/rfc2131.txt?number=2131

RFC2132 - DHCP Options and BOOTP Vendor Extensions
http://www.ietf.org/rfc/rfc2132.txt?number=2132

RFC3046 -DHCP Relay Agent Information Option
http://www.ietf.org/rfc/rfc3046.txt?number=3046

RFC3396 - Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)
http://www.ietf.org/rfc/rfc3396.txt?number=3396

RFC3925 - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)

http://www.ietf.org/rfc/rfc3925.txt?number=3925

RFC3495 - Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration
http://www.ietf.org/rfc/rfc3495.txt?number=3495

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

为做到通用,DHCP允许分配3种类型的地址:
  • 类似BOOTP,DHCP允许手工配置,管理人员可为特定的某台计算机配置特定的地址
  • DHCP也允许自动配置,管理人员允许DHCP服务器为第一次上网的机器分配一个永久地址
  • DHCP允许完全动态配置,服务器可使计算机在一段有限的时间内“租用”一个地址
由于DHCP允许一台主机无人工干预即可获得通信所需的全部参数,所以DHCP是允许自动配置的。当然,自动配置受到管理上的约束。

为适应各种可能的环境,DHCP不指定租用期的固定长度,而是让客户申请某一个租用期,并由服务器通知客户它认可的租用期。

BOOTP和DHCP都使用中继代理(relay agent),中继代理允许计算机与非本地网络上的服务器联系。当中继代理接收到来自客户的广播申请,他将申请转发到服务器,然后返回服务器发给主机的响应。中继代理使多地址配置变得复杂,因为服务器可能收到同一台机器发出的多个请求。由于BOOTP和DHCP都使用了客户标识符,我们假定一个多地址客户发送识别特定接口的一个值(如一个唯一的硬件地址),因此即使是通过中继代理收到请求,服务器也能区分一台多地址主机发出的多个请求。


上图为客户使用DHCP获取其IP地址时的6个主要状态和状态间的转换

为使用DHCP,一台主机通过把报文广播给本地网上服务器而成为客户。然后该主机收集服务器提供的地址,从中选择一个地址并验证服务器是否接受。

当不再需要租用地址时,DHCP允许客户终止租用,不再等待租用到期。

当DHCP客户进入已绑定状态后,客户设置3个定时器,分别控制租用更新重新绑定到期
  • 第一个定时器的默认值通常是总租用期的50%,当其到期时客户必须尝试重新租用期。
  • 第二个定时器在租用期的87.5%时到期,并使客户从更新状态转换到重绑定状态。
  • 客户转换到重绑定状态后,已经请求原服务器和本地网络上其他服务器延长其租用期,很少有客户在第三个定时器到期前还没有从任何一个服务器收到响应。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DHCP Options的总结
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing
configuration information to hosts on a TCP/IP network. Configuration parameters and
other control information are carried in tagged data items that are stored in the 'options' field
of the DHCP message. The data items themselves are also called "options."

RFC2132:
0 - pad option
255 - end option
1 - subnet mask
2 - time offset
3 - router option
4 - time server option
5 - name server option
6 - domain name server option
7 - log server option
8 - cookie server option
9 - LRP server option
10 - impress server option
11 - resource location server option
12 - host name option
13 - boot file size option
14 - merit dump file
15 - domain name
16 - swap server
17 - root path
18 - extensions path
19 - IP Forwarding Enable/Disable Option
20 - Non-Local Source Routing Enable/Disable Option
21 - Policy Filter Option
22 - Maximum Datagram Reassembly Size
23 - Default IP Time-to-live
24 - Path MTU Aging Timeout Option
25 - Path MTU Plateau Table Option
26 - Interface MTU Option
27 - All Subnets are Local Option
28 - Broadcast Address Option
29 - Perform Mask Discovery Option
30 - Mask Supplier Option
31 - Perform Router Discovery Option
32 - Router Solicitation Address Option
33 - Static Route Option
34 - Trailer Encapsulation Option
35 - ARP Cache Timeout Option
36 - Ethernet Encapsulation Option
37 - TCP Default TTL Option
38 - TCP Keepalive Interval Option
39 - TCP Keepalive Garbage Option
40 - Network Information Service Domain Option
41 - Network Information Servers Option
42 - Network Time Protocol Servers Option
43 - Vendor Specific Information
44 - NetBIOS over TCP/IP Name Server Option
45 - NetBIOS over TCP/IP Datagram Distribution Server Option
46 - NetBIOS over TCP/IP Node Type Option
47 - NetBIOS over TCP/IP Scope Option
48 - X Window System Font Server Option
49 - X Window System Display Manager Option
50 - Requested IP Address
51 - IP Address Lease Time
52 - Option Overload
53 - DHCP Message Type
54 - Server Identifier
55 - Parameter Request List
56 - Message
57 - Maximum DHCP Message Size
58 - Renewal (T1) Time Value
59 - Rebinding (T2) Time Value
60 - Vendor class identifier
61 - Client-identifier
64 - Network Information Service+ Domain Option
65 - Network Information Service+ Servers Option
66 - TFTP server name
67 - Bootfile name
68 - Mobile IP Home Agent option
69 - Simple Mail Transport Protocol (SMTP) Server Option
70 - Post Office Protocol (POP3) Server Option
71 - Network News Transport Protocol (NNTP) Server Option
72 - Default World Wide Web (WWW) Server Option
73 - Default Finger Server Option
74 - Default Internet Relay Chat (IRC) Server Option
75 - StreetTalk Server Option
76 - StreetTalk Directory Assistance (STDA) Server Option

RFC3495:
122 - CableLabs Client Configuration Option

RFC3925:
The Dynamic Host Configuration Protocol (DHCP) options for Vendor
Class and Vendor-Specific Information can be limiting or ambiguous
when a DHCP client represents multiple vendors. This document
defines two new options, modeled on the IPv6 options for vendor class
and vendor-specific information, that contain Enterprise Numbers to
remove ambiguity.

124 - Vendor-Identifying Vendor Class Option
125 - Vendor-Identifying Vendor-Specific Information Option

RFC3046:
82 - Relay Agent Information Option

2007年9月7日星期五

TR069: CPE WAN Management Protocol

/*
* A summary about TR069 during my projects
*/

TR69是由DSL论坛定义的用户终端广域网管理协议。

最新的TR069标准:
TR-069 Amendment2
http://www.dslforum.org/techwork/tr/TR-069Amendment2.pdf

与TR069相关的几个技术报告:
TR098 - Internet Gateway Device Data Model for TR-069 (used for QoS)
http://www.dslforum.org/techwork/tr/TR-098%20Amendment%201.pdf
TR104 -
DSLHomeTM Provisioning Parameters for VoIP CPE
http://www.dslforum.org/techwork/tr/TR-104.pdf
TR106 - Data Model Template for TR-069 Enabled Devices
http://www.dslforum.org/techwork/tr/TR-106%20Amendment%201.pdf
TR140 - TR-069 Data Model for Storage Service Enabled Devices
http://www.dslforum.org/techwork/tr/TR-140.pdf
TR111 - DSLHome
TMApplying TR-069 to Remote Management of Home Networking Devices
http://www.dslforum.org/techwork/tr/TR-111.pdf

DSL论坛定义的其他技术报告
http://www.dslforum.org/trlist/trlist.php


+++ Introduction +++

A protocol for communication between a CPE and Auto-Configuration Server (ACS) that encompasses secure auto-configuration as well as other CPE management functions within a common framework.


TR069的主要功能:
  • Auto-configuration and dynamic service provisioning
  • Software/firmware image management
  • Status and performance monitoring
  • Diagnostics

The position of TR069 in the Auto-Configuration Architecture:


The position of TR069 in the End-to-End Architecture:


TR069 Family:



Connectivity model of TR069:
• Allow both CPE and ACS initiated connection establishment, avoiding the need for a persistent connection to be maintained between each CPE and an ACS.
• The functional interactions between the ACS and CPE should be independent of which end initiated the establishment of the connection. In particular, even where ACS initiated connectivity is not supported, all ACS initiated transactions should be able to take place over a connection initiated by the CPE.
• Allow one or more ACS servers to serve a population of CPE, which may be associated with one or more service providers.
• Optimize the use of connections that are established to minimize connection overhead by allowing multiple bi-directional transactions to occur over a single connection.



+++ Architecture +++

Protocol Stack of TR069:




Security Mechanisms:
The following security mechanisms are incorporated in this protocol:
• The protocol supports the use of SSL/TLS for communications transport between CPE and ACS. This provides transaction confidentiality, data integrity, and allows certificate-based authentication between the CPE and ACS.
• The HTTP layer provides an alternative means of CPE and ACS authentication based on shared secrets. Note that the protocol does not specify how the shared secrets are learned by the CPE and ACS.

CPE Initiated Sessions/
Asynchronous ACS Initiated Sessions:
The basic mechanism defined in the CPE WAN Management Protocol to enable asynchronous ACS initiated communication assumes direct IP addressability of the CPE from the ACS. An alternative mechanism is defined in Annex G, which accommodates CPE operating behind a NAT gateway that are not directly addressable by the ACS.



+++ Procedures/Requirements +++

ACS Discovery:
1.
The CPE MAY be configured locally with the URL of the ACS. For example, via TR064.
2. As part of the IP layer auto-configuration, a DHCP server on the access network MAY be configured to include the ACS URL as a DHCP option.
3. The CPE MAY have a default ACS URL that it MAY use if no other URL is provided to it.

Connection Establishment:
1.
The CPE MAY at any time initiate a connection to the ACS using the pre-determined ACS address. A CPE MUST establish a connection to the ACS and issue the Inform RPC method
under some specific conditions (see TR069).
2.
The ACS MAY at any time request that the CPE initiate a connection to the ACS using the Connection Request mechanism. Support for this mechanism is REQUIRED in a CPE, and is RECOMMENDED in an ACS.
(This mechanism relies on the ACS having had at least one prior communication with the CPE via a CPE initiatedinteraction. During this interaction, if the ACS wishes to allow future ACS-initiated transactions, it would use the value of the "ManagementServer.ConnectionRequestURL" Parameter. If the URL used for management access changes, the CPE MUST notify the ACS by issuing an Inform message indicating the new management IP address, thus keeping the ACS up-to-date.)


Use of HTTP:
SOAP messages are carried between a CPE and an ACS using HTTP 1.1, where the CPE acts as the HTTP client and the ACS acts as the HTTP server.
The CPE WAN Management Protocol also uses HTTP for Connection Requests, where the ACS acts as the HTTP client and the CPE acts as the HTTP server.

Use of SOAP:
The CPE WAN Management Protocol defines SOAP 1.1 as the encoding syntax to transport the RPC method calls and responses.

Transaction Session Procedures:







+++ Signed Vouchers +++

An optional mechanism for securely enabling or disabling optional CPE capabilities.Unlike Parameters, the Voucher mechanism provides an additional layer of security for optional capabilities that require secure tracking (such as those involving payment).

A Voucher is a digitally signed data structure that instructs a CPE to enable or disable a set of Options. An Option is any optional capability of a CPE. When an Option is enabled, the Voucher can specify various characteristics that determine under what conditions that Option persists.



+++ Web Identity Management +++

To support web-based applications or other CPE-related web pages on a back-end web site for access from a browser within the CPE’s local network, the CPE WAN Management Protocol provides an optional mechanism that allows such web sites to customize their content with explicit knowledge of the customer associated with that CPE. That is, the location of users browsing from inside the CPE’s LAN can be automatically identified without any manual login process.

The protocol defines a set of optional interfaces that allow the web site to initiate communication between the CPE and ACS, which allows a web site in communication with that ACS to identify which CPE the user is operating behind. This allows the web site to customize its content to be specific to the associated broadband account, the particular type of CPE, or any other characteristic that is known to the ACS.


Note—this identification mechanism does not distinguish among different users on the same network behind a single CPE. In situations where identification of a specific user is required, a separate identity management mechanism, such as manual login, would be needed.
The CPE WAN Management Protocol defines an optional Kicked RPC method in Annex A, which can be used to support web identity management functionality.




+++ Signed Package Format +++

A signed package format that MAY used to securely download files into a recipient device.The format allows one or more files to be encapsulated within a single signed package. The package format allows the recipient to authenticate the source, and contains instructions for the
recipient to extract and install the contents.





+++ Device-Gateway Association +++

The CPE WAN Management Protocol can be used to remotely manage CPE Devices that are connected via a LAN through a Gateway. When an ACS manages both a Device and the Gateway through which the Device is connected, it can be useful for the ACS to be able to determine the identity of that particular Gateway.

The procedures defined in this Annex allow an ACS to determine the identity of the Gateway through which a given Device is connected.

The specific scenario that the defined mechanism is intended to accommodate is where both the Gateway and Device are managed via the CPE WAN Management Protocol, and both are managed by the same ACS (or by distinct ACSs that are appropriately coupled).

The defined mechanism relies on the Device’s use of DHCP.








+++ Connection Request via NAT Gateway +++

RFC3489 -
STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) http://www.ietf.org/rfc/rfc3489.txt?number=3489 To accommodate the ability for an ACS to issue the equivalent of a Connection Request to CPE allocated a private address through a NAT Gateway that might not be CPE WAN Management Protocol capable, the following is required:
  • The CPE MUST be able to discover that its connection to the ACS is via a NAT Gateway that has allocated a private IP address to the CPE.
  • The CPE MUST be able to maintain an open NAT binding through which the ACS can send unsolicited packets.
  • The CPE MUST be able to determine the public IP address and port associated with the open NATbinding, and communicate this information to the ACS.
The use of STUN for this purpose requires that a new UDP-based Connection Request mechanism be defined to augment the existing TCP-based Connection Request mechanism.












//

2007年9月6日星期四

IGMP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

IGMP标准的演进:
RFC1112 - Host Extensions for IP Multicasting
http://www.ietf.org/rfc/rfc1112.txt?number=1112

RFC2236 - Internet Group Management Protocol, Version 2
http://www.ietf.org/rfc/rfc2236.txt?number=2236

RFC3376 - Internet Group Management Protocol, Version 3
http://www.ietf.org/rfc/rfc3376.txt?number=3376

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

其他一些相关标准:
/* IGMP proxy-routing function */
RFC4605 - Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
http://www.ietf.org/rfc/rfc4605.txt?number=4605

/*
SSM(source-specific multicast) */
RFC3569 -
An Overview of Source-Specific Multicast (SSM)
http://www.ietf.org/rfc/rfc3569.txt?number=3569
RFC4604 - Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast
http://www.ietf.org/rfc/rfc4604.txt?number=4604

/* MLD */
RFC2710 -
Multicast Listener Discovery (MLD) for IPv6
http://www.ietf.org/rfc/rfc2710.txt?number=2710
RFC3590 - Source Address Selection for the Multicast Listener Discovery (MLD) Protocol
http://www.ietf.org/rfc/rfc3590.txt?number=3590
RFC3810 - Multicast Listener Discovery Version 2 (MLDv2) for IPv6
http://www.ietf.org/rfc/rfc3810.txt?number=3810

/* IGMP snooping */
RFC4541 - Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
http://www.ietf.org/rfc/rfc4541.txt?number=4541

/* PIM-SM */
RFC2362 - Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
http://www.ietf.org/rfc/rfc2362.txt?number=2362

/* MBGP */
RFC2283 - Multiprotocol Extensions for BGP-4
http://www.ietf.org/rfc/rfc2283.txt?number=2283

/* MADCAP */
RFC2730 - Multicast Address Dynamic Client Allocation Protocol
http://www.ietf.org/rfc/rfc2730.txt?number=2730

/* MZAP */
RFC2776 - Multicast-Scope Zone Announcement Protocol
http://www.ietf.org/rfc/rfc2776.txt?number=2776

/* IP Router Alert Option */
RFC2113 -IP Router Alert Option
http://www.ietf.org/rfc/rfc2113.txt?number=2113

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

IGMP协议是IP协议的组成部分,被封装在IPv4数据包里进行传输。包含IGMP协议的IP包的TTL值被置为1,限定IGMP只会在本子网内传播。组播路由器和实现组播的主机必须使用IGMP来进行群组成员信息的通信

IGMP的工作分为两个阶段:
  1. 当主机加入一个新的组播群组时,他把一个IGMP报文发送给群组的组播地址,宣布其成员。本地组播路由器接收到这个报文之后,向互联网上其他组播路由器传播这个群组成员信息,以建立必要的路由。
  2. 为适应动态的成员,本地组播路由器周期性地轮询本地网络上的主机,以便确定现在各个群组中有哪些主机。如果若干次轮询后,某个群组中始终没有成员,组播路由器就认为该群组中不再有本地网络中的主机,于是停止向其他组播路由器通告该群组的成员信息。
IGMP通过几种方式使得对网络的影响最小:
  • 主机与组播路由器之间的所有通信都使用IP组播。当IGMP报文封装到IP数据报中进行传输时,IP目的地址是个组播地址(路由器把通用的IGMP查询发送到全主机组播地址,主机把一些IGMP报文发送给所有路由器地址,主机和路由器都把特定于一个群组的IGMP报文发送到该群组的地址)。因此携带IGMP报文的数据报在传输过程中尽量利用硬件的组播能力。其结果是在支持硬件组播的网络上,不参与IP组播的主机就不会收到IGMP报文。【IGMP Snooping的功能】
  • 轮询确定群组成员时,组播路由器不会为每个群组发送单独报文,而是发送单个查询请求得到关于所有群组的信息
  • 如果多个组播路由器连接到同一个网络,他们会迅速而有效地选用一个路由器来轮询主机成员。因此当网络中添加其他组播路由器时,网络上的IGMP通信量总量不会增加。
  • 主机不会同时响应路由器的IGMP查询,每个查询包含一个N值,指定了最大响应时间。当查询到达时,主机选择0到N之间的一个随机时延,在这个时延之后发送响应报文。
  • 每台主机监听群组中其他主机的响应,并抑制那些不必要的响应通信量。时延最小的主机首先发送自己的响应,该响应发送给群组的组播地址,所有其他成员都会和组播路由器一样收到副本。其他成员就会取消自己的定时器并抑制传输。因此,实践中每个群组中只有一台主机对请求报文做出响应。

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * *

IGMPv3 详解:
/*
IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers.
Version 2 added support for "low leave latency";
Version 3 adds support for "source filtering"
*/


1. The Service Interface for Requesting IP Multicast Reception (support source filters)

IPMulticastListen (socket, interface, multicast-address,filter-mode, source-list)

2. IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2.
Every IGMP message described in this document is sent with an IP Time-to-Live of 1,
IP Precedence of Internetwork Control (e.g., Type of Service 0xc0),
and carries an IP Router Alert option [RFC-2113] in its IP header.

3. IGMPv3 支持的消息

0x11 Membership Query
0x22 Version 3 Membership Report
0x12 Version 1 Membership Report
0x16 Version 2 Membership Report
0x17 Version 2 Leave Group

4. Membership Query 消息的IP目的地址

In IGMPv3, General Queries are sent with an IP destination address of
224.0.0.1, the all-systems multicast address. Group-Specific and
Group-and-Source-Specific Queries are sent with an IP destination
address equal to the multicast address of interest. *However*, a
system MUST accept and process any Query whose IP Destination
Address field contains *any* of the addresses (unicast or multicast)
assigned to the interface on which the Query arrives.

5. V3 Membership Report 消息的IP源地址

An IGMP report is sent with a valid IP source address for the
destination subnet. The 0.0.0.0 source address may be used by a
system that has not yet acquired an IP address. Note that the
0.0.0.0 source address may simultaneously be used by multiple systems
on a LAN. Routers MUST accept a report with a source address of 0.0.0.0

6. V3 Membership Report 消息的IP目的地址

Version 3 Reports are sent with an IP destination address of
224.0.0.22, to which all IGMPv3-capable multicast routers listen.
A system that is operating in version 1 or version 2 compatibility
modes sends version 1 or version 2 Reports to the multicast group
specified in the Group Address field of the Report. In addition, a
system MUST accept and process any version 1 or version 2 Report
whose IP Destination Address field contains *any* of the addresses
(unicast or multicast) assigned to the interface on which the Report
arrives.

7. IGMP is an asymmetric protocol, specifying separate behaviors for
group members -- that is, hosts or routers that wish to receive
multicast packets -- and multicast routers.

8. The all-systems multicast address, 224.0.0.1, is handled as a special
case. On all systems -- that is all hosts and routers, including
multicast routers -- reception of packets destined to the all-systems
multicast address, from all sources, is permanently enabled on all
interfaces on which multicast reception is supported. No IGMP
messages are ever sent regarding the all-systems multicast address.

9. The purpose of IGMP is to enable each multicast router to learn, for
each of its directly attached networks, which multicast addresses are
of interest to the systems attached to those networks. IGMP version
3 adds the capability for a multicast router to also learn which
*sources* are of interest to neighboring systems, for packets sent to
any particular multicast address. The information gathered by IGMP
is provided to whichever multicast routing protocol is being used by
the router, in order to ensure that multicast packets are delivered
to all networks where there are interested receivers.

10. IGMPv3 specifies two types of Membership Reports: Current-State and State Change.
"Current-State" Reports are sent in response to Queries; while "State Change" Reports
are sent as a result of a change in interface state.



// To be continue

World Clocks

Endless Space Headline Animator

Mobile Ads