标签: url

The American Registry for Internet Numbers (ARIN) has just sent out an alert that its share of the unique URL addresses for the Internet Protocol, Version 4 (IPv4) is running out. Since only a few of four billion or so unique URL addresses possible with IPv4 are left, ARIN has announced that there’s not enough in its stock to satisfy an entire order. So it has activated a stricter procedure by which to assign the few remaining IPv4 addresses.   Specifically, in its recently announced policy for unmet requests , when an organization qualifies for a block size that no longer remains in the ARIN IPv4 inventory, they'll be given the option to either accept a smaller block that is available to fully satisfy their request, or to be placed on the waiting list for unmet requests.   “The number of days remaining before depletion are dwindling," writes ARIN's chief information officer Richard Jimmerson in a blog post just before July 4. "It is very likely that we are already processing a request that we will be unable to fulfill."   An article in the Washington Post on the ARIN announcement seems to imply that major changes are imminent, but that we are not to worry because IPv6 is available to save us and give us all the URL addresses we need. Only the second part of that is true. Except for many mobile smartphone and tablet users whose wireless service providers are just now making the shift, the transition to IPv6 will take years and even decades. Many existing Internet Service Providers with IPv4 will be around for a long time. Indeed, there is already a growing market for buying used and highly desirable IPv4 addresses .   IPv6 with its 340 trillion trillion trillion possible unique combinations has been sitting in the wings as a replacement for IPv4 since about 2000. But few if any large organizations with the bankroll to establish a presence on the Internet have felt it was economically viable to invest in it until recently. It was not until three to four years ago that major Internet and Web entities under the umbrella of the Internet Society finally started making the transition. Many of those most active in making the shift are in mobile smartphone markets, including ATT, Google, T-Mobile, and Verizon. Most of them are still only half-way through their deployment and testing on IPv6. And where available, it is being offered only as an optional alternative to IPv4.   Currently, only about seven percent of users who come to Google do so over IPv6 connections. (Source: Google)   Even with the number of its remaining unique addresses drying up, IPv4 still accounts for 93 percent of worldwide Internet traffic. According to a continuously updated chart maintained by Google, as of July 3, 2015, the percentage of users worldwide who access Google via ISPs with IPv6 is currently about seven percent. Google's per country adoption charts indicate that in the United States just slightly over 20 percent of the users who come to Google do so via IPv6 connections.   The reason there is not a rush on IPv6 is simple: economics. Most local, regional, and in some cases national Internet Service Providers are not able or are unwilling to pay the expense of transitioning from their existing base of IPv4-based routers, switches, and servers, except on a slow and years-long incremental basis. In the United States, only the largest of ISPs have committed to the transition, including Charter Communications, Comcast, Global Crossing, Hurricane Electric, Liberty Global, and Time-Warner Cable. IPv6 will slowly eat away at the continued IPv4 dominance, due mostly to new network providers and companies with no investment in existing IPv4.   But most second and third tier regional, statewide, and local ISPs who have major investments in IPv4 are not rushing to make the shift. Engineers and technicians at the several regional ISPs I have dealt with directly over the last decade or so point out that there is no compelling end-use application that cannot be done with existing IPv4. Since about 2000, through the use of such traditional techniques as the use of several levels of subdomains, dynamic rather than static network address translation (NAT) , destination and stateful NAT, NAT loopbacks, port address translation, and Internet connection sharing, they have been able to keep up with demands, not only for more bandwidth, but more features and flexibility.   Where such enhancements and workarounds put additional load on their network hardware, IPv4 Internet Service providers are shifting to the use of switches and routers based on more powerful and lower cost multicore processor designs. Also aiding their efforts at improving IPv4 is the shift to systems based on software defined networking (SDN) . Such routers and switches depend not on dedicated hardware for separate network functions, but on software-based network function virtualization (NFV) allowing lightning -fast reconfiguration of a variety of network elements.   While such enhancements of existing IPv4-based systems involve additional investment in hardware and software, this can be done at a lower cost, and on a more piecemeal, as needed, basis rather than by replacing their existing IPv4 systems with IPv6. So, despite the fewer unique URL address out of the four billion or so made possible by IPv4, the end of the Internet has we have known it will not occur soon. IPv4 will continue to be the norm for many decades to come.   In the U.S. that transition will occur more quickly only if one of three things happen: First, a dramatic use case for IPv6 emerges that triggers a demand from users of the Internet, causing IPv4-based ISP companies to make the shift; second, government action is taken either in the form of significant incentives or through a direct statutory requirement; and third, the economics of maintaining IPv4 becomes unviable. Nothing I see now or in the near future makes any of these likely any time soon.

大家好，前面我们为大家分享了如何实现W5200E01-M3中的UPnP(通用即插即用) 端口转发(一)，今天继续为大家分享第二部分，希望对大家有帮助~ 第一部分请参考： http://forum.eet-cn.com/BLOG_ARTICLE_12795.HTM   3. 端口转发和W5200 工作流程 这篇应用笔记主要介绍了在 W5200 单片机中通过 UPnP 执行端口发送的过程。在此过程中， W5200 是 IGD 的控制指针，它能够编辑端口的发送功能。同时， W5200 单片机也是 LAN 客户端， IGD 则来执行端口转发。这样我们可以总结为， W5200 单片机控制指针能够向 IGD 发送命令执行端口发送函数。所有的指令都基于 IGD 标准，这些标准由因特网网关工作委员会定义，而委员会又是由 UPnP 建立的。基本上，端口发送包括两个步骤：一是添加端口映射，另一个是删除端口映射。除此以外，在添加和删除端口映射的过程中，有一些异常需要 W5200 单片机去处理，例如： 1.映射入口的冲突 : 端口映射入口指定的冲突在之前就已经由另一个客户端分配。 2. 更多的异常可以在 IGD 服务模板中找到 。 这篇应用手册将会介绍 W5200 如何添加以及删除端口映射。下面的图形也解释了 W5200UPnP 端口转发的过程。 注意: 更多关于Step0寻址 的信息，请参阅“如何用 W5200 实现 DHCP 通信”。   图 5. W5200 的 UPnP 端口发送过程   阶段1 SSDP 为了能够搜索在相同子网中的IGD，W5200必须使用UDP多播地址发送SSDP M-SEARCH信息。 ☞注意:SSDP利用多播地址、通用socket方式来发送数据。例如： 1)在实际的多播过程中，W5200单片机必须采取下面的方式打开socket： socket(sock_id, Sn_MR_UDP, MULTICAST_PORT, Sn_MR_MULTI); 2) 在SSDP中，W5200单片机仍然可以创建通用socket： socket(sock_id, Sn_MR_UDP, MULTICAST_PORT, 0)    在这篇应用手册中，所有和描述相关的多播都属于2)中的情况。 SSDP响应能够使W5200获知IGD的IP地址、端口号以及所有的描述URL。         M-SEARCH * HTTP/1.1\r\n Host:239.255.255.250:1900\r\n ST:urn:schemas-upnp-org:device:InternetGatewayDevice:1\r\n Man:"ssdp:discover"\r\n MX:3\r\n \r\n   下面的源代码在SSDPProcess()函数执行：     {       初始化一个多播的socket（UDP，目的IP是239.255.255.250，目的端口是1900，目的MAC是0x01:0x00:0x5E:0x7F:0xFF:0xFA)         //发送SSDP       sendto(sockfd, SSDP, strlen(SSDP), mcast_addr, 1900);         //接收回复       while       {            if(overtime){                  close a multicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       Close a multicasting socket         // 解析SSDP信息       return parseSSDP(recv_buffer); }   阶段2 获取IGD服务的描述 利用IGD的IP地址，端口号和Description URL描述来完成HTTP GET Header，然后将其发送给IGD。 当IGD接收到HTTP GET Header后，IGD将会让W5200单片机获知它的描述。 描述过程将会使W5200获知它的Control URL以及Eventing Subscription URL。     GET destURL HTTP/1.1\r\n Accept: text/xml, application/xml\r\n User-Agent: Mozilla/4.0 (compatible; UPnP/1.0; Windows NT/5.1)\r\n"); Host: destIP:destPORT \r\n Connection: Keep-Alive\r\n Cache-Control: no-cache\r\n Pragma: no-cache\r\n \r\n     下面的源代码是由GetDescriptionProcess()函数来执行的。       {       //构造HTTP GET Header       MakeGETHeader(send_buffer);         Initialize a unicasting socket         //连接到IGD(Internet Gateway Device)       connect(sockfd, ipaddr of IGD, port of IGD);         wait while connecting to IGD         //发送Get Discription Message       send(sockfd, send_buffer, strlen(send_buffer), FALSE);         //接收回复       while       {            if(overtime){                  close a unicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       Close a unicasting socket         //解析Discription Message       return parseDescription(recv_buffer); }   阶段3 Case 1:添加端口控制 利用IGD的IP地址、端口号以及控制URL来完成XML，然后通过HTTP POST method-based SOAP执行AddPortMapping操作。                                           下面的源代码是由AddPortProcess()函数执行的。.     {       //构造"Add Port" XML(SOAP)       MakeSOAPAddControl(content, protocol, extertnal_port, internal_ip, internal_port, description);         //构造HTTP POST Header       MakePOSTHeader(send_buffer, strlen(content), ADD_PORT);       strcat(send_buffer, content);         Initialize a unicasting socket         //连接到IGD(Internet Gateway Device)       connect(sockfd, ipaddr of IGD, port of IGD);         wait while connecting to IGD         //发送"Add Port"信息       send(sockfd, send_buffer, strlen(send_buffer), FALSE);         // 接收回复       while       {            if(overtime){                  close a unicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       close a unicasting socket         //解析回复信息       return parseAddPort(recv_buffer); }   Case 2: 删除端口控制 利用IGD的IP地址、端口号以及控制URL来完成XML，然后通过HTTP POST method-based SOAP执行DeletePortMapping操作。   下面的源代码是在DeletePortProcess()函数中执行的。.     {       //构造"Delete Port" XML(SOAP)       MakeSOAPDeleteControl(content, protocol, extertnal_port);         //构造HTTP POST Header       MakePOSTHeader(send_buffer, strlen(content), DELETE_PORT);       strcat(send_buffer, content);         Initialize a unicasting socket         //连接到(Internet Gateway Device)       connect(sockfd, ipaddr of IGD, port of IGD);         wait while connecting to IGD         // 发送"Delete Port"信息       send(sockfd, send_buffer, strlen(send_buffer), FALSE);         // 接收回复       while       {            if(overtime){                  close a unicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       close a unicasting socket         //解析回复信息       return parseDeletePort(recv_buffer); }   Case 1和Case 2测试 为了确认UPnP端口转发能否正常工作，用户可以在远程PC机上运行TCP客户端，然后将其连接到W5200(TCP服务器)单片机。用户可以参考第五章节“学习如何检验AddPortMapping和DeletePortMapping的使用举例”。     下面的源代码是在tcp_test()函数中执行的。       {       switch (getSn_SR(sockfd))       {            case SOCK_ESTABLISHED:/* 如果连接建立*/                  if(receive buffer is not empty){                        recv(sockfd, recv_buffer, len);                  }            break;              case SOCK_CLOSE_WAIT:/*如果客户端请求关闭 */                  if (receive buffer is not empty)                  {                        recv(sockfd, recv_buffer, len);                  }                  disconnect(sockfd);            break;              case SOCK_CLOSED:/*如果socket关闭 */                  reinitialize a TCP socket                  listen            break;       } }       4.  阶段4 提交事件 (可选) 为了能够提交事件，首先W5200单片机通过IGD的IP地址、端口号和事件提交URL来完成GENA信息，然后将GENA信息发送给IGD。   SUBSCRIBE eventSubURL HTTP/1.1\r\n Host: destIP:destPORT \r\n USER-AGENT: Mozilla/4.0 (compatible; UPnP/1.1; Windows NT/5.1)\r\n CALLBACK: http:// myIP:listen_port /\r\n NT: upnp:event\r\n TIMEOUT: Second-1800\r\n \r\n     下面的源代码是在SetEventing()函数中执行的。       {       // 构造Subscription message       MakeSubscribe(send_buffer, listen_port);         Initialize a unicasting socket         // Connect to IGD(Internet Gateway Device)       connect(sockfd, ipaddr of IGD, port of IGD);         wait while connecting to IGD         // 发送Subscription Message       send(sockfd, send_buffer, strlen(send_buffer), FALSE);         //接收回复       while       {            if(overtime){                  close a unicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       close a unicasting socket         return 0; } 如果您有什么疑问，请直接留言或登录WIZnet官方网站：http://www.wiznettechnology.cn/ 或者来电：86-10-84539974（转166），QQ:2377211388, 邮箱：wiznetbj@wiznettechnology.com  联系人：Jerry ，谢谢！  

大家好，前面我们为大家分享了如何实现W5200E01-M3中的UPnP(通用即插即用) 端口转发(一)，今天继续为大家分享第二部分，希望对大家有帮助~   第一部分请参考： http://bbs.ednchina.com/BLOG_ARTICLE_3005093.HTM   3. 端口转发和W5200 工作流程 这篇应用笔记主要介绍了在 W5200 单片机中通过 UPnP 执行端口发送的过程。在此过程中， W5200 是 IGD 的控制指针，它能够编辑端口的发送功能。同时， W5200 单片机也是 LAN 客户端， IGD 则来执行端口转发。这样我们可以总结为， W5200 单片机控制指针能够向 IGD 发送命令执行端口发送函数。所有的指令都基于 IGD 标准，这些标准由因特网网关工作委员会定义，而委员会又是由 UPnP 建立的。基本上，端口发送包括两个步骤：一是添加端口映射，另一个是删除端口映射。除此以外，在添加和删除端口映射的过程中，有一些异常需要 W5200 单片机去处理，例如： 1.映射入口的冲突 : 端口映射入口指定的冲突在之前就已经由另一个客户端分配。 2. 更多的异常可以在 IGD 服务模板中找到 。 这篇应用手册将会介绍 W5200 如何添加以及删除端口映射。下面的图形也解释了 W5200UPnP 端口转发的过程。 注意: 更多关于寻址 的信息，请参阅“如何用 W5200 实现 DHCP 通信”。   1. 阶段1  SSDP 为了能够搜索在相同子网中的IGD，W5200必须使用UDP多播地址发送SSDP M-SEARCH信息。 注意:SSDP利用多播地址、通用socket方式来发送数据。例如： 1)在实际的多播过程中，W5200单片机必须采取下面的方式打开socket： socket(sock_id, Sn_MR_UDP, MULTICAST_PORT, Sn_MR_MULTI); 2) 在SSDP中，W5200单片机仍然可以创建通用socket： socket(sock_id, Sn_MR_UDP, MULTICAST_PORT, 0)    在这篇应用手册中，所有和描述相关的多播都属于2)中的情况。 SSDP响应能够使W5200获知IGD的IP地址、端口号以及所有的描述URL。         M-SEARCH * HTTP/1.1\r\n Host:239.255.255.250:1900\r\n ST:urn:schemas-upnp-org:device:InternetGatewayDevice:1\r\n Man:"ssdp:discover"\r\n MX:3\r\n \r\n   下面的源代码在SSDPProcess()函数执行：     {       初始化一个多播的socket（UDP，目的IP是239.255.255.250，目的端口是1900，目的MAC是0x01:0x00:0x5E:0x7F:0xFF:0xFA)         //发送SSDP       sendto(sockfd, SSDP, strlen(SSDP), mcast_addr, 1900);         //接收回复       while       {            if(overtime){                  close a multicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       Close a multicasting socket         // 解析SSDP信息       return parseSSDP(recv_buffer); }   阶段2 获取IGD服务的描述 利用IGD的IP地址，端口号和Description URL描述来完成HTTP GET Header，然后将其发送给IGD。 当IGD接收到HTTP GET Header后，IGD将会让W5200单片机获知它的描述。 描述过程将会使W5200获知它的Control URL以及Eventing Subscription URL。     GET destURL HTTP/1.1\r\n Accept: text/xml, application/xml\r\n User-Agent: Mozilla/4.0 (compatible; UPnP/1.0; Windows NT/5.1)\r\n"); Host: destIP:destPORT \r\n Connection: Keep-Alive\r\n Cache-Control: no-cache\r\n Pragma: no-cache\r\n \r\n     下面的源代码是由GetDescriptionProcess()函数来执行的。       {       //构造HTTP GET Header       MakeGETHeader(send_buffer);         Initialize a unicasting socket         //连接到IGD(Internet Gateway Device)       connect(sockfd, ipaddr of IGD, port of IGD);         wait while connecting to IGD         //发送Get Discription Message       send(sockfd, send_buffer, strlen(send_buffer), FALSE);         //接收回复       while       {            if(overtime){                  close a unicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       Close a unicasting socket         //解析Discription Message       return parseDescription(recv_buffer); }   阶段3 Case 1:添加端口控制 利用IGD的IP地址、端口号以及控制URL来完成XML，然后通过HTTP POST method-based SOAP执行AddPortMapping操作。                                           下面的源代码是由AddPortProcess()函数执行的。.     {       //构造"Add Port" XML(SOAP)       MakeSOAPAddControl(content, protocol, extertnal_port, internal_ip, internal_port, description);         //构造HTTP POST Header       MakePOSTHeader(send_buffer, strlen(content), ADD_PORT);       strcat(send_buffer, content);         Initialize a unicasting socket         //连接到IGD(Internet Gateway Device)       connect(sockfd, ipaddr of IGD, port of IGD);         wait while connecting to IGD         //发送"Add Port"信息       send(sockfd, send_buffer, strlen(send_buffer), FALSE);         // 接收回复       while       {            if(overtime){                  close a unicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       close a unicasting socket         //解析回复信息       return parseAddPort(recv_buffer); }   Case 2: 删除端口控制 利用IGD的IP地址、端口号以及控制URL来完成XML，然后通过HTTP POST method-based SOAP执行DeletePortMapping操作。   下面的源代码是在DeletePortProcess()函数中执行的。.     {       //构造"Delete Port" XML(SOAP)       MakeSOAPDeleteControl(content, protocol, extertnal_port);         //构造HTTP POST Header       MakePOSTHeader(send_buffer, strlen(content), DELETE_PORT);       strcat(send_buffer, content);         Initialize a unicasting socket         //连接到(Internet Gateway Device)       connect(sockfd, ipaddr of IGD, port of IGD);         wait while connecting to IGD         // 发送"Delete Port"信息       send(sockfd, send_buffer, strlen(send_buffer), FALSE);         // 接收回复       while       {            if(overtime){                  close a unicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       close a unicasting socket         //解析回复信息       return parseDeletePort(recv_buffer); }   Case 1和Case 2测试 为了确认UPnP端口转发能否正常工作，用户可以在远程PC机上运行TCP客户端，然后将其连接到W5200(TCP服务器)单片机。用户可以参考第五章节“学习如何检验AddPortMapping和DeletePortMapping的使用举例”。     下面的源代码是在tcp_test()函数中执行的。       {       switch (getSn_SR(sockfd))       {            case SOCK_ESTABLISHED:/* 如果连接建立*/                  if(receive buffer is not empty){                        recv(sockfd, recv_buffer, len);                  }            break;              case SOCK_CLOSE_WAIT:/*如果客户端请求关闭 */                  if (receive buffer is not empty)                  {                        recv(sockfd, recv_buffer, len);                  }                  disconnect(sockfd);            break;              case SOCK_CLOSED:/*如果socket关闭 */                  reinitialize a TCP socket                  listen            break;       } }   阶段4 提交事件 (可选) 为了能够提交事件，首先W5200单片机通过IGD的IP地址、端口号和事件提交URL来完成GENA信息，然后将GENA信息发送给IGD。       SUBSCRIBE eventSubURL HTTP/1.1\r\n Host: destIP:destPORT \r\n USER-AGENT: Mozilla/4.0 (compatible; UPnP/1.1; Windows NT/5.1)\r\n CALLBACK: myIP:listen_port/\r\n NT: upnp:event\r\n TIMEOUT: Second-1800\r\n \r\n     下面的源代码是在SetEventing()函数中执行的。       {       // 构造Subscription message       MakeSubscribe(send_buffer, listen_port);         Initialize a unicasting socket         // Connect to IGD(Internet Gateway Device)       connect(sockfd, ipaddr of IGD, port of IGD);         wait while connecting to IGD         // 发送Subscription Message       send(sockfd, send_buffer, strlen(send_buffer), FALSE);         //接收回复       while       {            if(overtime){                  close a unicasting socket                  return -1;            }else if(receive buffer is not empty){                  receive the SSDP response from IGD to recv_buffer            }       }       close a unicasting socket         return 0;     如果您有什么疑问，请直接留言或登录WIZnet官方网站： http://www.wiznettechnology.cn/ 或者来电：86-10-84539974（转166），QQ:2377211388, 邮箱： wiznetbj@wiznettechnology.com   联系人：Jerry ，谢谢！   

这篇应用文章将会介绍WIZnet W5200芯片和基于W5200的模块上UPnP的一些技术信息。第一，介绍什么是UPnP。第二，介绍UPnP工作组定义的端口转发概念。最后，这篇文章会说明W5200芯片如何添加和删除端口映射。今天为大家分享第一部分，端午节后继续为大家分享后面两部分~希望对大家有帮助~ 1. 说明 1.1 概念 请参考Wikipedia What is UPnP?     UPnP 的概念最早来源于即插即用。即插即用是描述计算机总线特性、设备规格的一个专业术语。利用即插即用可以大大简化系统的整个硬件组成，而不需要再进行物理设备的配置，也避免了解决资源冲突时用户的干预 。整个思路就是：只需要在设备中插入，然后就可以使用。 如今将UPnP将即插即用概念创造性地应用于网络环境下。UPnP可以自动搜索设备类别。它支持零配置，“隐形”网络，以及自动检索功能。这就意味着设备UPnP可以动态加入网络、获得IP地址、传输性能，从而得到当前设备以及其他设备的性能的相关信息——全自动化、完全零配置网络支持。 1.2 UPnP结构以及UPnP涉及的步骤 UPnP 结构 TCP 由客户端和服务器构成。同样地， UPnP 结构也基于设备和控制点 :   设备：      提供服务     例如， UPnP DVD 播放器是用来提供 DVD 播放服务的设备。     记录设备的状态 .     例如， DVD 播放器能够记录 DVD 的播放状态。 控制点      控制已经定义的设备来执行相应的服务 图 1. UPnP网络 为了能够实现所有的描述，通用即插即主要应用于TCP/IP、DHCP、XML等等现存的一些标准中，从而使这些标准的应用更加广泛。 UPnP 网络应用的步骤 在 UPnP 机制下存在 6 种不同的步骤： （1） 寻址 寻址是通过控制点和设备取得网络地址的过程。这些控制点和设备先从 DHCP 服务器上获得一个 IP 地址；如果没有可用的 IP 地址，将会在 169.254 的子网上随机获取一个自动 IP 地址。 注意: 在寻址过程中 ， AutoIP 和 DHCP 都可以协助 UPnP 控制点和设备取得一个 IP 地址。但是 DHCP 要比 AutoIP 的更为常用和可靠。所以，在这篇应用手册和基于 W5200 的模型中， DHCP 是获得 IP 地址的唯一方法。   （2）搜索 控制点可以通过搜索来查找对它们有意义的设备。 当控制点进入网络时，它们以普通或者特殊方式释放 search packets 来搜索 and/or 服务的设备。搜索完成后，具有合适服务特性的设备或者子设备就会做出响应。 同样地， UPnP 设备首先将会以规律性间隔的方式在网络上表明自身的存在。控制点监听这些状态，检测这些新的设备并且判断它们在网络上的性能表现。 网络上的其它 UPnP 设备将会发出通知表明它们提供的服务将不再有效。 注意: 在搜索过程中，无论是Searching或者Advertising都可以帮助UPnP控制点来寻找UPnP设备。在Searching和Advertising这两种方法相同的情况下，在这篇应用手册和基于W5200的模型中都是保留了Searching方法，而Advertising方法将被忽略。 （3）描述 UPnP 发送搜索包，将控制点送到一个它们能够检索 Device Description Document(DDD) 的位置。 DDD 包括： 所有嵌入式设备的概述以及一个服务列表。 被称做服务控制协议定义 (SCPD) 一个 URL 。 SCPD 描述了控制点如何使用这些设备提供的服务。 控制和事件 URLs: 这些 URLs 表示控制点必须发送命令来配置 UPnP 设备 , 并且利用这些设备所提供的服务。 用来陈述的 URL( 见第 6 步 ).   （4） 控制 控制过程允许控制点向设备发送命令。如之前提到的，在 DDD 中指定发送命令的 URL 。   （5）   事件 事件过程允许控制点跟踪设备的状态变化。控制点首先订阅合适的服务，随后设备服务中任何状态的变化都会以事件的形式发送给已经订阅的控制点来保证它们的更新。   （6）  陈述 控制点能够选择性地为设备显示一个用户的界面。用来陈述的 URL 是在 DDD 中已经被指定。陈述页面显示基于 HTML 的用户界面，这样用户就可以参考 and/or 设备的状态。所以陈述过程是控制过程和事件过程的补充。 注意: W5200扮演了一个UPnP控制点的角色，实际上它并不需要嵌入一个网络服务器。网络服务器在UPnP设备中是不可缺少的，所以在本文和基于W5200单片机的模型中，并不支持陈述过程。   2. 端口转发和UPnP 端口转发 简单来说，端口发送（另一种说法是 NAT 遍历）功能允许创建 TCP 和 UDP 协议映射。这些协议应用于外部因特网网关设备（ IGD ）端口（称为外部端口）和内部客户机地址。这里的内部客户地址与其中的一个端口相联系（分别称为内部客户机和内部端口）。 请参考下面的图形来理解端口转发的应用： UPnP 和端口转发 端口转发是 IGD 众多功能中最基本的一个（更多的 IGD 标准功能可以在 UPnP IGD 服务模板中找到）。尽管端口转发功能可以手动完成，但是通过使用 UPnP ，端口转发功能默认执行操作。我们可以这样说， UPnP 为用户实现了端口转发的更清晰化。 目前，很多类型的 P2P 软件都支持 UPnP 的端口转发功能，例如 Skype 、 UTorrent 以及 MSN 。如果你对 UPnP 感兴趣，可以登录 IGD 的设置页面找到端口发送列表（见图 4 ），在列表中你会发现所有的端口映射。大部分的映射都是有 UPnP 完成，而不是用户。 图4. UPnP端口映射列表

这篇应用文章将会介绍WIZnet W5200芯片和基于W5200的模块上UPnP的一些技术信息。第一，介绍什么是UPnP。第二，介绍UPnP工作组定义的端口转发概念。最后，这篇文章会说明W5200芯片如何添加和删除端口映射。今天为大家分享第一部分，端午节后继续为大家分享后面两部分~希望对大家有帮助~ 1. 说明 1.1 概念 请参考Wikipedia What is UPnP?     UPnP 的概念最早来源于即插即用。即插即用是描述计算机总线特性、设备规格的一个专业术语。利用即插即用可以大大简化系统的整个硬件组成，而不需要再进行物理设备的配置，也避免了解决资源冲突时用户的干预 。整个思路就是：只需要在设备中插入，然后就可以使用。 如今将UPnP将即插即用概念创造性地应用于网络环境下。UPnP可以自动搜索设备类别。它支持零配置，“隐形”网络，以及自动检索功能。这就意味着设备UPnP可以动态加入网络、获得IP地址、传输性能，从而得到当前设备以及其他设备的性能的相关信息——全自动化、完全零配置网络支持。 1.2 UPnP结构以及UPnP涉及的步骤 UPnP 结构 TCP 由客户端和服务器构成。同样地， UPnP 结构也基于设备和控制点 :   设备：      提供服务     例如， UPnP DVD 播放器是用来提供 DVD 播放服务的设备。     记录设备的状态 .     例如， DVD 播放器能够记录 DVD 的播放状态。 控制点      控制已经定义的设备来执行相应的服务 图 1. UPnP网络 为了能够实现所有的描述，通用即插即主要应用于TCP/IP、DHCP、XML等等现存的一些标准中，从而使这些标准的应用更加广泛。 UPnP 网络应用的步骤 在 UPnP 机制下存在 6 种不同的步骤： （1） 寻址 寻址是通过控制点和设备取得网络地址的过程。这些控制点和设备先从 DHCP 服务器上获得一个 IP 地址；如果没有可用的 IP 地址，将会在 169.254 的子网上随机获取一个自动 IP 地址。 注意: 在寻址过程中 ， AutoIP 和 DHCP 都可以协助 UPnP 控制点和设备取得一个 IP 地址。但是 DHCP 要比 AutoIP 的更为常用和可靠。所以，在这篇应用手册和基于 W5200 的模型中， DHCP 是获得 IP 地址的唯一方法。   （2）搜索 控制点可以通过搜索来查找对它们有意义的设备。 当控制点进入网络时，它们以普通或者特殊方式释放 search packets 来搜索 and/or 服务的设备。搜索完成后，具有合适服务特性的设备或者子设备就会做出响应。 同样地， UPnP 设备首先将会以规律性间隔的方式在网络上表明自身的存在。控制点监听这些状态，检测这些新的设备并且判断它们在网络上的性能表现。 网络上的其它 UPnP 设备将会发出通知表明它们提供的服务将不再有效。 注意: 在搜索过程中，无论是Searching或者Advertising都可以帮助UPnP控制点来寻找UPnP设备。在Searching和Advertising这两种方法相同的情况下，在这篇应用手册和基于W5200的模型中都是保留了Searching方法，而Advertising方法将被忽略。 （3）描述 UPnP 发送搜索包，将控制点送到一个它们能够检索 Device Description Document(DDD) 的位置。 DDD 包括： 所有嵌入式设备的概述以及一个服务列表。 被称做服务控制协议定义 (SCPD) 一个 URL 。 SCPD 描述了控制点如何使用这些设备提供的服务。 控制和事件 URLs: 这些 URLs 表示控制点必须发送命令来配置 UPnP 设备 , 并且利用这些设备所提供的服务。 用来陈述的 URL( 见第 6 步 ).   （4） 控制 控制过程允许控制点向设备发送命令。如之前提到的，在 DDD 中指定发送命令的 URL 。   （5）   事件 事件过程允许控制点跟踪设备的状态变化。控制点首先订阅合适的服务，随后设备服务中任何状态的变化都会以事件的形式发送给已经订阅的控制点来保证它们的更新。   （6）  陈述 控制点能够选择性地为设备显示一个用户的界面。用来陈述的 URL 是在 DDD 中已经被指定。陈述页面显示基于 HTML 的用户界面，这样用户就可以参考 and/or 设备的状态。所以陈述过程是控制过程和事件过程的补充。 注意: W5200扮演了一个UPnP控制点的角色，实际上它并不需要嵌入一个网络服务器。网络服务器在UPnP设备中是不可缺少的，所以在本文和基于W5200单片机的模型中，并不支持陈述过程。   2. 端口转发和UPnP 端口转发 简单来说，端口发送（另一种说法是 NAT 遍历）功能允许创建 TCP 和 UDP 协议映射。这些协议应用于外部因特网网关设备（ IGD ）端口（称为外部端口）和内部客户机地址。这里的内部客户地址与其中的一个端口相联系（分别称为内部客户机和内部端口）。 请参考下面的图形来理解端口转发的应用： UPnP 和端口转发 端口转发是 IGD 众多功能中最基本的一个（更多的 IGD 标准功能可以在 UPnP IGD 服务模板中找到）。尽管端口转发功能可以手动完成，但是通过使用 UPnP ，端口转发功能默认执行操作。我们可以这样说， UPnP 为用户实现了端口转发的更清晰化。 目前，很多类型的 P2P 软件都支持 UPnP 的端口转发功能，例如 Skype 、 UTorrent 以及 MSN 。如果你对 UPnP 感兴趣，可以登录 IGD 的设置页面找到端口发送列表（见图 4 ），在列表中你会发现所有的端口映射。大部分的映射都是有 UPnP 完成，而不是用户。 图4. UPnP端口映射列表