久久久婷婷五月亚洲97号色,国产午夜精品久久久久九九电影,国产91色综合久久免费分享

CPP&&设计模式��屋 — Thu, 04 Jan 2007 05:37:00 GMT

P2P之UDP�I�K��NAT的原理与实现�Q�附源代码）

作者：shootingstars | 日期�Q?span id="TimeLabel">2004-05-25 | 字体�Q?a href="javascript:ContentSize(16)">�?/a>�?/a>��?/a>

P2P �?UDP�I�K��NAT的原理与实现�Q�附源代码）
原创�Q�shootingstars
参考：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

论坛上经常有对P2P原理的讨论，但是讨论归讨论，很少有实质的东西产生�Q�源代码�Q�。呵呵，在这里我��q��自己实现的一个源代码来说明UDP�I�越NAT的原理�?/p>

首先先介�l�一些基本概念：
    NAT(Network Address Translators)�Q�网�l�地址转换�Q�网�l�地址转换是在IP地址日益�~�Z��的情况下产生的，它的主要目的��是��Z��能够地址重用。NAT分�ؓ两大�c�，基本的NAT和NAPT(Network Address/Port Translator)�?br />    最开始NAT是运行在路由器上的一个功能模块�?br />
    最先提出的是基本的NAT�Q�它的��生基于如下事实：一个私有网�l�（域）中的节点中只有很��的节点需要与外网�q�接�Q�呵呵，�q�是在上世纪90�q�代中期提出的）。那么这个子�|�中其实只有��数的节炚w��要全球唯一的IP地址�Q�其他的节点的IP地址应该是可以重用的�?br />    因此�Q�基本的NAT实现的功能很��单，在子�|�内使用一个保留的IP子网�D�，�q�些IP对外是不可见的。子�|�内只有��数一些IP地址可以对应到真正全球唯一的IP地址。如果这些节炚w��要访问外部网�l�，那么基本NAT��p��责将�q�个节点的子�|�内IP转化��Z��个全球唯一的IP然后发送出厅R�?基本的NAT会改变IP包中的原IP地址�Q�但是不会改变IP包中的端�?
    关于基本的NAT可以参看RFC 1631

    另外一�U�NAT叫做NAPT�Q�从名称上我们也可以看得出，NAPT不但会改变经�q�这个NAT讑֤�的IP数据报的IP地址�Q�还会改变IP数据报的TCP/UDP端口。基本NAT的设备可能我们见的不多（呵呵�Q�我没有见到�q�）�Q�NAPT才是我们真正讨论的主角。看下图�Q?br />                                Server S1
                         18.181.0.31:1235
                                      |
          ^ Session 1 (A-S1) ^      |
          | 18.181.0.31:1235 |      |
          v 155.99.25.11:62000 v      |
                                      |
                                     NAT
                                 155.99.25.11
                                      |
          ^ Session 1 (A-S1) ^      |
          | 18.181.0.31:1235 |      |
          v   10.0.0.1:1234    v      |
                                      |
                                   Client A
                                10.0.0.1:1234
    有一个私有网�l?0.*.*.*�Q�Client A是其中的一台计��机�Q�这个网�l�的�|�关�Q�一个NAT讑֤��Q�的外网IP�?55.99.25.11(应该�q�有一个内�|�的IP地址�Q�比�?0.0.0.10)。如果Client A中的某个�q�程�Q�这个进�E�创��Z��一个UDP Socket,�q�个Socket�l�定1234端口�Q�想讉K��外网��L��18.181.0.31�?235端口�Q�那么当数据包通过NAT时会发生什么事情呢�Q?br />    首先NAT会改变这个数据包的原IP地址�Q�改�?55.99.25.11。接着NAT会�ؓ�q�个传输创徏一个Session�Q�Session是一个抽象的概念�Q�如果是TCP�Q�也许Session是由一个SYN包开始，以一个FIN包结束。而UDP呢，以这个IP的这个端口的�W�一个UDP开始，�l�束呢，呵呵�Q�也许是几分钟，也许是几��时�Q�这要看具体的实��C��Q��ƈ且给�q�个Session分配一个端口，比如62000�Q�然后改变这个数据包的源端口�?2000。所以本来是�Q?0.0.0.1:1234->18.181.0.31:1235�Q�的数据包到了互联网上变��Z��Q?55.99.25.11:62000->18.181.0.31:1235�Q��?br />    一旦NAT创徏了一个Session后，NAT会记�?2000端口对应的是10.0.0.1�?234端口�Q�以后从18.181.0.31发送到62000端口的数据会被NAT自动的�{发到10.0.0.1上。（注意�Q�这里是�?8.181.0.31发送到62000端口的数据会被�{发，其他的IP发送到�q�个端口的数据将被NAT抛弃�Q�这样Client A��׃��Server S1建立以了一个连接�?/p>

    呵呵�Q�上面的基础知识可能很多人都知道了，那么下面是关键的部分了�?br />    看看下面的情况：
    Server S1                                     Server S2
18.181.0.31:1235                              138.76.29.7:1235
        |                                             |
        |                                             |
        +----------------------+----------------------+
                               |
   ^ Session 1 (A-S1) ^      |      ^ Session 2 (A-S2) ^
   | 18.181.0.31:1235 |      |      | 138.76.29.7:1235 |
   v 155.99.25.11:62000 v      |      v 155.99.25.11:62000 v
                               |
                            Cone NAT
                          155.99.25.11
                               |
   ^ Session 1 (A-S1) ^      |      ^ Session 2 (A-S2) ^
   | 18.181.0.31:1235 |      |      | 138.76.29.7:1235 |
   v   10.0.0.1:1234    v      |      v   10.0.0.1:1234    v
                               |
                            Client A
                         10.0.0.1:1234
    接上面的例子�Q�如果Client A的原来那个Socket(�l�定�?234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包，那么�q�个UDP包在通过NAT时会怎么样呢�Q?br />    �q�时可能会有两种情况发生�Q�一�U�是NAT再次创徏一个Session�Q��ƈ且再�ơ�ؓ�q�个Session分配一个端口号�Q�比如：62001�Q�。另外一�U�是NAT再次创徏一个Session�Q�但是不会新分配一个端口号�Q�而是用原来分配的端口�?2000。前一�U�NAT叫做Symmetric NAT�Q�后一�U�叫做Cone NAT。我们期望我们的NAT是第二种�Q�呵呵，如果你的NAT刚好是第一�U�，那么很可能会有很多P2P软�g��q��。（可以庆幸的是�Q�现在绝大多数的NAT属于后者，即Cone NAT�Q?br />
    好了�Q�我们看刎ͼ�通过NAT,子网内的计算机向外连�l�是很容易的�Q�NAT相当于透明的，子网内的和外�|�的计算��Z��用知道NAT的情况）�?br />    但是如果外部的计��机惌��问子�|�内的计��机��比较困难了�Q�而这正是P2P所需要的�Q��?br />    那么我们如果想从外部发送一个数据报�l�内�|�的计算机有什么办法呢�Q�首先，我们必须在内�|�的NAT上打上一个“洞”（也就是前面我们说的在NAT上徏立一个Session�Q�，�q�个�z�不能由外部来打�Q�只能由内网内的��L��来打。而且�q�个�z�是有方向的�Q�比如从内部某台��L��Q�比如：192.168.0.10�Q�向外部的某个IP(比如�Q?19.237.60.1)发送一个UDP包，那么��在�q�个内网的NAT讑֤�上打了一个方向�ؓ219.237.60.1的“洞”，�Q�这��是�U�CؓUDP Hole Punching的技术）以后219.237.60.1��可以通过�q�个�z�与内网�?92.168.0.10联系了。（但是其他的IP不能利用�q�个�z�）�?/p>

呵呵�Q�现在该轮到我们的正题P2P了。有了上面的理论�Q�实��C��个内�|�的��L��通讯��差最后一步了�Q�那��是鸡生蛋还是蛋生鸡的问题了�Q�两辚w��无法��d��发出�q�接��h��Q�谁也不知道谁的公网地址�Q�那我们如何来打�q�个�z�呢�Q�我们需要一个中间�h来联�p�这两个内网��L��?br /> 现在我们来看看一个P2P软�g的流�E�，以下图�ؓ例：

                       Server S �Q?19.237.60.1�Q?br />                          |
                          |
   +----------------------+----------------------+
   |                                             |
NAT A (外网IP:202.187.45.3)                 NAT B (外网IP:187.34.1.56)
   |   (内网IP:192.168.0.1)                      | (内网IP:192.168.0.1)
   |                                             |
Client A (192.168.0.20:4000)             Client B (192.168.0.10:40000)

    首先�Q�Client A��d��服务器，NAT A��ơ的Session分配了一个端�?0000�Q�那么Server S收到的Client A的地址�?02.187.45.3:60000�Q�这��是Client A的外�|�地址了。同��P��Client B��d��Server S�Q�NAT B�l�此�ơSession分配的端口是40000�Q�那么Server S收到的B的地址�?87.34.1.56:40000�?br />    此时�Q�Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client B�Q�那么他可以从Server S那儿获得B的公�|�地址187.34.1.56:40000�Q�是不是Client A向这个地址发送信息Client B��p��收到了呢�Q�答案是不行�Q�因为如果这样发送信息，NAT B会将�q�个信息丢弃�Q�因��L��信息是不误��来的�Q��ؓ了安全，大多数NAT都会执行丢弃动作�Q�。现在我们需要的是在NAT B上打一个方向�ؓ202.187.45.3�Q�即Client A的外�|�地址�Q�的�z�，那么Client A发送到187.34.1.56:40000的信�?Client B��p��收到了。这个打�z�命令由谁来发呢�Q�呵呵，当然是Server S�?br />    �ȝ��一下这个过�E�：如果Client A惛_��Client B发送信息，那么Client A发送命令给Server S�Q�请求Server S命��oClient B向Client A方向打洞。呵呵，是不是很�l�口�Q�不�q�没关系�Q�想一惛_��很清楚了�Q�何况还有源代码呢（侯老师说过�Q�在源代码面前没有秘�?8�Q�）�Q�然后Client A��可以通过Client B的外�|�地址与Client B通信了�?br />
    注意�Q�以上过�E�只适合于Cone NAT的情况，如果是Symmetric NAT�Q�那么当Client B向Client A打洞的端口已�l�重新分配了�Q�Client B��无法知道这个端口（如果Symmetric NAT的端口是��序分配的，那么我们或许可以猜测�q�个端口��P��可是�׃��可能��D��p�|的因素太多，我们不推荐这�U�猜��端口的�Ҏ��Q��?br />
    下面是一个模拟P2P聊天的过�E�的源代码，�q�程很简单，P2PServer�q�行在一个拥有公�|�IP的计��机上，P2PClient�q�行在两个不同的NAT后（注意�Q�如果两个客��L��q�行在一个NAT后，本程序很可能不能�q�行正常�Q�这取决于你的NAT是否支持loopback translation�Q�详�?a >http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt�Q�当�Ӟ��此问题可以通过双方先尝试连接对方的内网IP来解冻I��但是�q�个代码只是��Z��验证原理�Q��ƈ没有处理�q�些问题�Q�，后登录的计算机可以获得先��d��计算机的用户名，后登录的计算机通过send username message的格式来发送消息。如果发送成功，说明你已取得了直接与�Ҏ��q�接的成功�?br />    �E�序现在支持三个命��o�Q�send , getu , exit

    send格式�Q�send username message
    功能�Q�发送信息给username

    getu格式�Q�getu
    功能�Q�获得当前服务器用户列表

    exit格式�Q�exit
    功能�Q�注销与服务器的连接（服务器不会自动监��客��h��否吊�U�）

    代码很短�Q�相信很�Ҏ��懂，如果有什么问题，可以�l�我发邮�?a href="mailto:zhouhuis22@sina.com">zhouhuis22@sina.com 或者在CSDN上发送短消息。同�Ӟ��Ƣ迎转发此文�Q�但希望保留作者版�?-�Q��?br />
    最后感谢CSDN�|�友 PiggyXP �?Seilfer的测试帮�?/p>

P2PServer.c

/* P2P �E�序服务�?br /> *
* 文�g名：P2PServer.c
*
* 日期�Q?004-5-21
*
* 作者：shootingstars(zhouhuis22@sina.com)
*
*/
#pragma comment(lib, "ws2_32.lib")

#include "windows.h"
#include "..\proto.h"
#include "..\Exception.h"

UserList ClientList;

void InitWinSock()
{
WSADATA wsaData;

if (WSAStartup(MAKEWORD(2, 2), &wsaData) != 0)
{
  printf("Windows sockets 2.2 startup");
  throw Exception("");
}
else{
  printf("Using %s (Status: %s)\n",
   wsaData.szDescription, wsaData.szSystemStatus);
  printf("with API versions %d.%d to %d.%d\n\n",
   LOBYTE(wsaData.wVersion), HIBYTE(wsaData.wVersion),
   LOBYTE(wsaData.wHighVersion), HIBYTE(wsaData.wHighVersion));

}
}

SOCKET mksock(int type)
{
SOCKET sock = socket(AF_INET, type, 0);
if (sock < 0)
{
printf("create socket error");
throw Exception("");
}
return sock;
}

stUserListNode GetUser(char *username)
{
for(UserList::iterator UserIterator=ClientList.begin();
      UserIterator!=ClientList.end();
       ++UserIterator)
{
  if( strcmp( ((*UserIterator)->userName), username) == 0 )
   return *(*UserIterator);
}
throw Exception("not find this user");
}

int main(int argc, char* argv[])
{
try{
  InitWinSock();

  SOCKET PrimaryUDP;
  PrimaryUDP = mksock(SOCK_DGRAM);

  sockaddr_in local;
  local.sin_family=AF_INET;
  local.sin_port= htons(SERVER_PORT);
  local.sin_addr.s_addr = htonl(INADDR_ANY);
  int nResult=bind(PrimaryUDP,(sockaddr*)&local,sizeof(sockaddr));
  if(nResult==SOCKET_ERROR)
   throw Exception("bind error");

  sockaddr_in sender;
  stMessage recvbuf;
  memset(&recvbuf,0,sizeof(stMessage));

  // 开始主循环.
  // ��d�@环负责下面几件事�?
  // 一:��d��客户端登陆和��d��消息,记录客户列表
  // �?转发客户p2p��h��
  for(;;)
  {
   int dwSender = sizeof(sender);
   int ret = recvfrom(PrimaryUDP, (char *)&recvbuf, sizeof(stMessage), 0, (sockaddr *)&sender, &dwSender);
   if(ret <= 0)
   {
    printf("recv error");
    continue;
   }
   else
   {
    int messageType = recvbuf.iMessageType;
    switch(messageType){
    case LOGIN:
     {
      // ��这个用��L��信息记录到用户列表中
      printf("has a user login : %s\n", recvbuf.message.loginmember.userName);
      stUserListNode *currentuser = new stUserListNode();
      strcpy(currentuser->userName, recvbuf.message.loginmember.userName);
      currentuser->ip = ntohl(sender.sin_addr.S_un.S_addr);
      currentuser->port = ntohs(sender.sin_port);

      ClientList.push_back(currentuser);

      // 发送已�l�登陆的客户信息
      int nodecount = (int)ClientList.size();
      sendto(PrimaryUDP, (const char*)&nodecount, sizeof(int), 0, (const sockaddr*)&sender, sizeof(sender));
      for(UserList::iterator UserIterator=ClientList.begin();
        UserIterator!=ClientList.end();
        ++UserIterator)
      {
       sendto(PrimaryUDP, (const char*)(*UserIterator), sizeof(stUserListNode), 0, (const sockaddr*)&sender, sizeof(sender));
      }

      break;
     }
    case LOGOUT:
     {
      // ��此客户信息删除
      printf("has a user logout : %s\n", recvbuf.message.logoutmember.userName);
      UserList::iterator removeiterator = NULL;
      for(UserList::iterator UserIterator=ClientList.begin();
       UserIterator!=ClientList.end();
       ++UserIterator)
      {
       if( strcmp( ((*UserIterator)->userName), recvbuf.message.logoutmember.userName) == 0 )
       {
        removeiterator = UserIterator;
        break;
       }
      }
      if(removeiterator != NULL)
       ClientList.remove(*removeiterator);
      break;
     }
    case P2PTRANS:
     {
      // 某个客户希望服务端向另外一个客户发送一个打�z�消�?br />      printf("%s wants to p2p %s\n",inet_ntoa(sender.sin_addr),recvbuf.message.translatemessage.userName);
      stUserListNode node = GetUser(recvbuf.message.translatemessage.userName);
      sockaddr_in remote;
      remote.sin_family=AF_INET;
      remote.sin_port= htons(node.port);
      remote.sin_addr.s_addr = htonl(node.ip);

      in_addr tmp;
      tmp.S_un.S_addr = htonl(node.ip);
      printf("the address is %s,and port is %d\n",inet_ntoa(tmp), node.port);

      stP2PMessage transMessage;
      transMessage.iMessageType = P2PSOMEONEWANTTOCALLYOU;
      transMessage.iStringLen = ntohl(sender.sin_addr.S_un.S_addr);
      transMessage.Port = ntohs(sender.sin_port);

      sendto(PrimaryUDP,(const char*)&transMessage, sizeof(transMessage), 0, (const sockaddr *)&remote, sizeof(remote));

      break;
     }

    case GETALLUSER:
     {
      int command = GETALLUSER;
      sendto(PrimaryUDP, (const char*)&command, sizeof(int), 0, (const sockaddr*)&sender, sizeof(sender));

int nodecount = (int)ClientList.size();
sendto(PrimaryUDP, (const char*)&nodecount, sizeof(int), 0, (const sockaddr*)&sender, sizeof(sender));

      for(UserList::iterator UserIterator=ClientList.begin();
        UserIterator!=ClientList.end();
        ++UserIterator)
      {
       sendto(PrimaryUDP, (const char*)(*UserIterator), sizeof(stUserListNode), 0, (const sockaddr*)&sender, sizeof(sender));
      }
      break;
     }
    }
   }
  }

}
catch(Exception &e)
{
printf(e.GetMessage());
return 1;
}

return 0;
}

/* P2P �E�序客户�?br /> *
* 文�g名：P2PClient.c
*
* 日期�Q?004-5-21
*
* 作者：shootingstars(zhouhuis22@sina.com)
*
*/

#pragma comment(lib,"ws2_32.lib")

#include "windows.h"
#include "..\proto.h"
#include "..\Exception.h"
#include
using namespace std;

UserList ClientList;

#define COMMANDMAXC 256
#define MAXRETRY 5

SOCKET PrimaryUDP;
char UserName[10];
char ServerIP[20];

bool RecvedACK;

void InitWinSock()
{
WSADATA wsaData;

SOCKET mksock(int type)
{
SOCKET sock = socket(AF_INET, type, 0);
if (sock < 0)
{
printf("create socket error");
throw Exception("");
}
return sock;
}

void BindSock(SOCKET sock)
{
sockaddr_in sin;
sin.sin_addr.S_un.S_addr = INADDR_ANY;
sin.sin_family = AF_INET;
sin.sin_port = 0;

if (bind(sock, (struct sockaddr*)&sin, sizeof(sin)) < 0)
throw Exception("bind error");
}

void ConnectToServer(SOCKET sock,char *username, char *serverip)
{
sockaddr_in remote;
remote.sin_addr.S_un.S_addr = inet_addr(serverip);
remote.sin_family = AF_INET;
remote.sin_port = htons(SERVER_PORT);

stMessage sendbuf;
sendbuf.iMessageType = LOGIN;
strncpy(sendbuf.message.loginmember.userName, username, 10);

sendto(sock, (const char*)&sendbuf, sizeof(sendbuf), 0, (const sockaddr*)&remote,sizeof(remote));

int usercount;
int fromlen = sizeof(remote);
int iread = recvfrom(sock, (char *)&usercount, sizeof(int), 0, (sockaddr *)&remote, &fromlen);
if(iread<=0)
{
throw Exception("Login error\n");
}

// ��d��到服务端后，接收服务端发来的已经��d��的用��L��信息
cout<<"Have "< for(int i = 0;i {
  stUserListNode *node = new stUserListNode;
  recvfrom(sock, (char*)node, sizeof(stUserListNode), 0, (sockaddr *)&remote, &fromlen);
  ClientList.push_back(node);
  cout<<"Username:"<userName<  in_addr tmp;
  tmp.S_un.S_addr = htonl(node->ip);
  cout<<"UserIP:"<  cout<<"UserPort:"<port<  cout<<""< }
}

void OutputUsage()
{
cout<<"You can input you command:\n"
  <<"Command Type:\"send\",\"exit\",\"getu\"\n"
  <<"Example : send Username Message\n"
  <<"          exit\n"
  <<"          getu\n"
  <}

/* �q�是主要的函敎ͼ�发送一个消息给某个用户(C)
*��程�Q�直接向某个用户的外�|�IP发送消息，如果此前没有联系�q?br /> *      那么此消息将无法发送，发送端�{�待��时�?br /> *      ��时后，发送端��发送一个请求信息到服务端，
*      要求服务端发送给客户C一个请求，��h��C�l�本机发送打�z�消�?br /> *      以上��程��重复MAXRETRY��?br /> */
bool SendMessageTo(char *UserName, char *Message)
{
char realmessage[256];
unsigned int UserIP;
unsigned short UserPort;
bool FindUser = false;
for(UserList::iterator UserIterator=ClientList.begin();
      UserIterator!=ClientList.end();
      ++UserIterator)
{
  if( strcmp( ((*UserIterator)->userName), UserName) == 0 )
  {
   UserIP = (*UserIterator)->ip;
   UserPort = (*UserIterator)->port;
   FindUser = true;
  }
}

if(!FindUser)
return false;

strcpy(realmessage, Message);
for(int i=0;i {
RecvedACK = false;

  sockaddr_in remote;
  remote.sin_addr.S_un.S_addr = htonl(UserIP);
  remote.sin_family = AF_INET;
  remote.sin_port = htons(UserPort);
  stP2PMessage MessageHead;
  MessageHead.iMessageType = P2PMESSAGE;
  MessageHead.iStringLen = (int)strlen(realmessage)+1;
  int isend = sendto(PrimaryUDP, (const char *)&MessageHead, sizeof(MessageHead), 0, (const sockaddr*)&remote, sizeof(remote));
  isend = sendto(PrimaryUDP, (const char *)&realmessage, MessageHead.iStringLen, 0, (const sockaddr*)&remote, sizeof(remote));

  // �{�待接收�U�程��此标记修改
  for(int j=0;j<10;j++)
  {
   if(RecvedACK)
    return true;
   else
    Sleep(300);
  }

  // 没有接收到目标主机的回应�Q�认为目标主机的端口映射没有
  // 打开�Q�那么发送请求信息给服务器，要服务器告诉目标��L��
  // 打开映射端口�Q�UDP打洞�Q?br />  sockaddr_in server;
  server.sin_addr.S_un.S_addr = inet_addr(ServerIP);
  server.sin_family = AF_INET;
  server.sin_port = htons(SERVER_PORT);

  stMessage transMessage;
  transMessage.iMessageType = P2PTRANS;
  strcpy(transMessage.message.translatemessage.userName, UserName);

sendto(PrimaryUDP, (const char*)&transMessage, sizeof(transMessage), 0, (const sockaddr*)&server, sizeof(server));
Sleep(100);// �{�待�Ҏ��先发送信息�?br /> }
return false;
}

// 解析命��o�Q�暂时只有exit和send命��o
// 新增getu命��o�Q�获取当前服务器的所有用�?br />void ParseCommand(char * CommandLine)
{
if(strlen(CommandLine)<4)
return;
char Command[10];
strncpy(Command, CommandLine, 4);
Command[4]='\0';

if(strcmp(Command,"exit")==0)
{
  stMessage sendbuf;
  sendbuf.iMessageType = LOGOUT;
  strncpy(sendbuf.message.logoutmember.userName, UserName, 10);
  sockaddr_in server;
  server.sin_addr.S_un.S_addr = inet_addr(ServerIP);
  server.sin_family = AF_INET;
  server.sin_port = htons(SERVER_PORT);

  sendto(PrimaryUDP,(const char*)&sendbuf, sizeof(sendbuf), 0, (const sockaddr *)&server, sizeof(server));
  shutdown(PrimaryUDP, 2);
  closesocket(PrimaryUDP);
  exit(0);
}
else if(strcmp(Command,"send")==0)
{
  char sendname[20];
  char message[COMMANDMAXC];
  int i;
  for(i=5;;i++)
  {
   if(CommandLine[i]!=' ')
    sendname[i-5]=CommandLine[i];
   else
   {
    sendname[i-5]='\0';
    break;
   }
  }
  strcpy(message, &(CommandLine[i+1]));
  if(SendMessageTo(sendname, message))
   printf("Send OK!\n");
  else
   printf("Send Failure!\n");
}
else if(strcmp(Command,"getu")==0)
{
  int command = GETALLUSER;
  sockaddr_in server;
  server.sin_addr.S_un.S_addr = inet_addr(ServerIP);
  server.sin_family = AF_INET;
  server.sin_port = htons(SERVER_PORT);

sendto(PrimaryUDP,(const char*)&command, sizeof(command), 0, (const sockaddr *)&server, sizeof(server));
}
}

// 接受消息�U�程
DWORD WINAPI RecvThreadProc(LPVOID lpParameter)
{
sockaddr_in remote;
int sinlen = sizeof(remote);
stP2PMessage recvbuf;
for(;;)
{
  int iread = recvfrom(PrimaryUDP, (char *)&recvbuf, sizeof(recvbuf), 0, (sockaddr *)&remote, &sinlen);
  if(iread<=0)
  {
   printf("recv error\n");
   continue;
  }
  switch(recvbuf.iMessageType)
  {
  case P2PMESSAGE:
   {
    // 接收到P2P的消�?br />    char *comemessage= new char[recvbuf.iStringLen];
    int iread1 = recvfrom(PrimaryUDP, comemessage, 256, 0, (sockaddr *)&remote, &sinlen);
    comemessage[iread1-1] = '\0';
    if(iread1<=0)
     throw Exception("Recv Message Error\n");
    else
    {
     printf("Recv a Message:%s\n",comemessage);

     stP2PMessage sendbuf;
     sendbuf.iMessageType = P2PMESSAGEACK;
     sendto(PrimaryUDP, (const char*)&sendbuf, sizeof(sendbuf), 0, (const sockaddr*)&remote, sizeof(remote));
    }

delete []comemessage;
break;

   }
  case P2PSOMEONEWANTTOCALLYOU:
   {
    // 接收到打�z�命令，向指定的IP地址打洞
    printf("Recv p2someonewanttocallyou data\n");
    sockaddr_in remote;
    remote.sin_addr.S_un.S_addr = htonl(recvbuf.iStringLen);
    remote.sin_family = AF_INET;
    remote.sin_port = htons(recvbuf.Port);

    // UDP hole punching
    stP2PMessage message;
    message.iMessageType = P2PTRASH;
    sendto(PrimaryUDP, (const char *)&message, sizeof(message), 0, (const sockaddr*)&remote, sizeof(remote));

    break;
   }
  case P2PMESSAGEACK:
   {
    // 发送消息的应答
    RecvedACK = true;
    break;
   }
  case P2PTRASH:
   {
    // �Ҏ��发送的打洞消息�Q�忽略掉�?br />    //do nothing ...
    printf("Recv p2ptrash data\n");
    break;
   }
  case GETALLUSER:
   {
    int usercount;
    int fromlen = sizeof(remote);
    int iread = recvfrom(PrimaryUDP, (char *)&usercount, sizeof(int), 0, (sockaddr *)&remote, &fromlen);
    if(iread<=0)
    {
     throw Exception("Login error\n");
    }

    ClientList.clear();

    cout<<"Have "<    for(int i = 0;i    {
     stUserListNode *node = new stUserListNode;
     recvfrom(PrimaryUDP, (char*)node, sizeof(stUserListNode), 0, (sockaddr *)&remote, &fromlen);
     ClientList.push_back(node);
     cout<<"Username:"<userName<     in_addr tmp;
     tmp.S_un.S_addr = htonl(node->ip);
     cout<<"UserIP:"<     cout<<"UserPort:"<port<     cout<<""<    }
    break;
   }
  }
}
}

int main(int argc, char* argv[])
{
try
{
  InitWinSock();

  PrimaryUDP = mksock(SOCK_DGRAM);
  BindSock(PrimaryUDP);

cout<<"Please input server ip:";
cin>>ServerIP;

cout<<"Please input your name:";
cin>>UserName;

ConnectToServer(PrimaryUDP, UserName, ServerIP);

  HANDLE threadhandle = CreateThread(NULL, 0, RecvThreadProc, NULL, NULL, NULL);
  CloseHandle(threadhandle);
  OutputUsage();

  for(;;)
  {
   char Command[COMMANDMAXC];
   gets(Command);
   ParseCommand(Command);
  }
}
catch(Exception &e)
{
  printf(e.GetMessage());
  return 1;
}
return 0;
}

/* 异常�c?br /> *
* 文�g名：Exception.h
*
* 日期�Q?004.5.5
*
* 作者：shootingstars(zhouhuis22@sina.com)
*/

#ifndef __HZH_Exception__
#define __HZH_Exception__

#define EXCEPTION_MESSAGE_MAXLEN 256
#include "string.h"

class Exception
{
private:
char m_ExceptionMessage[EXCEPTION_MESSAGE_MAXLEN];
public:
Exception(char *msg)
{
strncpy(m_ExceptionMessage, msg, EXCEPTION_MESSAGE_MAXLEN);
}

char *GetMessage()
{
return m_ExceptionMessage;
}
};

#endif

/* P2P �E�序传输协议
*
* 日期�Q?004-5-21
*
* 作者：shootingstars(zhouhuis22@sina.com)
*
*/

#pragma once
#include

// 定义iMessageType的�?br />#define LOGIN 1
#define LOGOUT 2
#define P2PTRANS 3
#define GETALLUSER 4

// 服务器端�?br />#define SERVER_PORT 2280

// Client��d��时向服务器发送的消息
struct stLoginMessage
{
char userName[10];
char password[10];
};

// Client注销时发送的消息
struct stLogoutMessage
{
char userName[10];
};

// Client向服务器��h��另外一个Client(userName)向自己方向发送UDP打洞消息
struct stP2PTranslate
{
char userName[10];
};

// Client向服务器发送的消息格式
struct stMessage
{
int iMessageType;
union _message
{
  stLoginMessage loginmember;
  stLogoutMessage logoutmember;
  stP2PTranslate translatemessage;
}message;
};

// 客户节点信息
struct stUserListNode
{
char userName[10];
unsigned int ip;
unsigned short port;
};

// Server向Client发送的消息
struct stServerToClient
{
int iMessageType;
union _message
{
stUserListNode user;
}message;

};

//======================================
// 下面的协议用于客��L��之间的通信
//======================================
#define P2PMESSAGE 100 // 发送消�?br />#define P2PMESSAGEACK 101 // 收到消息的应�{?br />#define P2PSOMEONEWANTTOCALLYOU 102 // 服务器向客户端发送的消息
// 希望此客��L��发送一个UDP打洞�?br />#define P2PTRASH 103 // 客户端发送的打洞包，接收端应该忽略此消息

// 客户端之间发送消息格�?br />struct stP2PMessage
{
int iMessageType;
int iStringLen; // or IP address
unsigned short Port;
};

using namespace std;
typedef list UserList;

CPP&&设计模式��屋 2007-01-04 13:37 发表评论

Peer-to-Peer (P2P) communication across middleboxes(�?

CPP&&设计模式��屋 — Thu, 04 Jan 2007 05:35:00 GMT

摘要: Internet Draft B. FordDocument: draft-ford-midcom-p2p-01.txt M.I.T.Expires: April 27, 2004 ... 阅读全文

CPP&&设计模式��屋 2007-01-04 13:35 发表评论

P2P直播相关(�?

CPP&&设计模式��屋 — Tue, 19 Dec 2006 09:17:00 GMT

最�q�对P2P直播技术进行了一些研�IӞ��谈谈个�h�?/font>Tvkoo软�g的优�~�点的看法，一斚w��希望Tvkoo能做的更好，另一斚w��也抛砖引玉一下：

P2P直播的技术难�Ҏ��Q?/font>
一、防火墙的穿透：��过90�Q�的电脑都在防火墙后面，如果�?/font>2台在防火墙后面的电脑能够实现P2P互联�Q�这是一个技术的隄��。有2�U�方式：

1. 要求用户配置TCP端口�Q?/font>BT和电驴采用的方式�Q�配�|�需要网�l�专业知识。一般做法是通过在防火墙上开�?/font>TCP端口来实玎ͼ�如果开启了端口或者本�w�有Internet IP地址的，为高联通性电脑；在防火墙内�ƈ且没有开�?/font>TCP端口的电脑，��Z��联通性电脑。高联通性电脑可以和其它的高联通性电脑已�l�低联通性电脑进�?/font>P2P�Q�而低联通电脑只能和高联通性电脑进�?/font>P2P。因此在BT、电驴中�Q�有Internet IP或者已�l�在防火墙上开启端口的电脑速度很快�Q�而在防火墙后面的电脑(一般�ؓ局域网上网方式)��比较慢了。而通过局域网方式上网的电脑超�q?/font>70%�Q�如果没有网�l�基��Q�或者没有网��特�D�配�|�，只能处于低联通性，速度很慢�?o:p>

2. 防火墙自动穿透。无需用户配置�Q�自动让2台在防火墙后面的电脑�?/font>P2P互联�?/font>P2P�q�接可以使用TCP�?/font>UDP 2�U�方式。由�?/font>WinXP SP2限制了一个应用程序的TCP�q�接敎ͼ�因此采用TCP方式�q�行P2P的话�Q�要安装TCP限制的破解��Y件。�?/font>Tvkoo是��?/font>UDP�q�行数据传送的�Q�因此不会有TCP限制。这是�ؓ什么有些用戯��Q�通过Netstat看不到很多的TCP�q�接而怀�?/font>Tvkoo是不�?/font>P2P软�g的原因�?o:p>

Tvkoo�?/font>P2P�I�K��力是我见到最强的软�g了，当然�׃��没有使用TCP�Q��得在仅允�?/font>HTTP讉K��的防火墙后面的计��机没有办法讉K��?/font>Skype�?/font>P2P�I�K��时有一个技巧，让一些有Internet IP的电脑��?/font>TCP�?/font>80端口�Q�在仅允�?/font>HTTP讉K��的防火墙后面的电脑通过�c�M��HTTP的访问方式连接这�?/font>80端口的电脑进�?/font>P2P�q�接�?/font>Tvkoo也可以考虑一下这个方式�?o:p>

二�?/font>WMV格式的分�?o:p>

目前P2P直播都是使用WMV格式�Q�通过模拟HTTP服务器的方式�Q�把WMV数据��传送给Media Player。这�?/font>P2P直播的关键点。需要将Media Encoder发出�?/font>HTTP数据�q�行拆包�Q�然后组�?/font>30�U�－1分钟�?/font>P2P数据块，然后通过P2P方式��数据块发送给Tvkoo客户端，Tvkoo模拟�?/font>HTTP服务器将传输完成的数据块发送给Media Player。这部分Tvkoo做的也不错�?o:p>

三、如何有效的选择P2P的节�?o:p>

�q�是Tvkoo的弱��V��因��Z��台电脑在P2P传输�Ӟ��最多连接几十台其它的电脑。当几万台电脑同时传送一�?/font>P2P数据块时�Q�要有一个优化算法。比如：��国�?/font>5000个用��P��中国电信�?/font>5000个用��P��中国�|�通有5000个用��P��而每个用��h��多只能连30�Q?/font>50个节点，如果不凑巧，一个电信的用户�q�接�?/font>20个网通的用户�?/font>30个美国的用户�Q�就不断的出现断断箋�l�的情况了。这��是��Z��么�h一多，Tvkoo��卡�Q��ƈ�?/font>Tvkoo要把国外IP��掉的原因了�?o:p>

有什么好的方式解册��个问题呢�Q�我先抛砖引玉一下：

(1) 作�ؓP2P直播的营�q�商�Q�可以多讑և��?/font>P2P�U�子服务器，分布在不同的�|�段中。比如：北方�|�通设一�?/font>(�l?/font>)�Q�南方电信设一�?/font>(�l?/font>)�Q�种子的内容是一��L��。种子服务器多了�Q�可以降低优化算法的隑ֺ��?o:p>

(2) �U�子服务器和普通节点的优先�U�：�U�子服务器的优先�U��L��低于普通节点的�Q�如果普通节点的速度快了�Q�就减少从种子服务器获取的数据量�?o:p>

(3) 全球IP地址表�?/font>P2P节点仲裁服务器中�Q�应该有一个全�?/font>IP地址表，分中国大陆、香港、台湾、北��、欧�z�Ӏ�澳�z�Ӏ�其它。中国大陆先按照营运商分�Q�电信、网通、铁通、联通、教育网�{�，再按照省份分�c�R�?/font>(�|�上有下载，可以整理)

(4) 高速网�D�表。在P2P讉K��中，节点动态地��速度快的其它节点IP地址传回服务器，服务器根据全�?/font>IP地址表算出网�D�，以网�D?/font>-�|�段的方式记录在数据库中�?o:p>

(5) 当一个新用户�q�入节点�Ӟ��在全�?/font>IP地址表中扑ֈ�最�q�的节点�Q�按照比例依�ơ分配最快网�D늚�节点�Q�最�q�的节点�Q�差一个��别的�E�近的节点；随机节点以及�U�子服务器�?o:p>

(6) P2P在数据传送中�Q�可以将30�U�视频作�?/font>1块数据包�Q�数据包中按照每16KB作�ؓ一个数据块。每个时间段(�?/font>2�U?/font>)�Q�本节点向其它节点交换一下数据块的传送情况，然后计算一下数据包中每个数据块的拥有率�Q�优先传送拥有率低的数据块。在拥有率相当的情况下，随机选择�?o:p>

(7) 在数据交换中�Q�对于传送慢的节点，定期剔除�Q�然后问节点仲裁服务器要新的节点�?o:p>

(8) 如果数据包中��于10%的数据块没有传送完毕，在时间充��的情况下，对于余下的数据块�Q�可以同一个数据块向多个节点请求�?o:p>

(9) 节点仲裁服务器也会将新的P2P节点��加蝲到另一个节点上�Q�但不能��过节点最大连接数�?/font>

CPP&&设计模式��屋 2006-12-19 17:17 发表评论

Kademlia: ��Z��异或�q�算的P2P信息�pȝ��(��译�E?

CPP&&设计模式��屋 — Mon, 11 Sep 2006 08:18:00 GMT

Petar Maymounkov and David Mazi`eres

fpetar,dmg@cs.nyu.edu

http://kademlia.scs.cs.nyu.edu

摘要

本文我们��描�q�C��个在�Ҏ��出错的网�l�环境中拥有可证实的�E�_��性和高性能

1 �Q�介�l?/span>

本论文描�q�Kademlia , 一个点对点�Q�P2P�Q�的<�? �?gt;元组存储和查询系�l��?Kademlia拥有许多的可喜的特点�Q�这些特�Ҏ��M��以前的P2P�pȝ��所无法同时提供的。它减少了节点必��d��送的用来�怺�认识的配�|�消息的数量。在做键查询的同�? 配置消息��会被自动传播�?节点拥有��_��的知识和灉|��性来通过低时延�\径发送查询请求�?Kademlia使用�q��?异步的查询请求来避免节点失效所带来的超时时延。通过节点记录�怺�的存在的��法可以抉|��某些基本的拒�l�服务（DoS�Q�攻凅R�?最�? 仅仅使用在分布式�q�行旉��上较��q��假设�Q�通过对现有点对点�pȝ��的测量而确认的�q�些假设�Q�，我们可以正式的证实Kademlia的许多重要特�?strong>�?/strong>

Kademlia 使用了许多点对点�Q�P2P�Q�系�l�的基本�Ҏ��?键是一�?60-bit的隐式数�?例如, 对一些大型数据进行SHA-1哈希的�?�?每个参与的机器都拥有一个节点ID, 160位的键�?<�? �?gt;对将存储在那些ID与键很‘接�q�’的节点�? �q�里‘接�q�’当然是按照一个接�q�度的概忉|��计算的。最�? 一个基于节点ID的�\��q��法��得�Q何�h可以在一个目的键附近定位��C��个服务器�?/span>

Kademlia 的许多的优点都是得益于它使用了一个很新颖的方�? 那就是用节点间的键作异或�q�算的结果来作�ؓ节点间的距离。异或运��是对称�? 允许Kademlia的参与者接收来自相同分布的�q�且包含在其路由表中的节点的查找��h��。如果没有这个性质�Q�就像Chord一��P��pȝ��无法从它们收到的查询��h��中学习到有用的�\�׃��息。更�p�的是， �׃��Chord中的�q�算是不对称的， Chord的�\��p��更加严格�?Chord节点的查找表的每一��w��必须存储�_��的按ID域的间隔递增的节炏V��在�q�个间隔内的��M��节点都比�q�个间隔内的某些键大�Q�因此离键很�q�。相反，Kademlia 可以在一定的间隔内发送请求给��M��节点�Q?允许��Z��时�g来选择路由�Q�甚臛_��送��^行的�Q�异步的查询�?/span>

��Z��在特定的ID附近定位节点�Q�Kademlia自始至终使用一个单�E�的路由��法。相反，其它一些系�l��用一�U�算法来接近目标ID,然后在最后的几个��x��使用另外一�U�算法。在现有�pȝ��中，Kademlia与pastry的第一阶段最像，�Q�虽然作者�ƈ没有用这�U�方式来描述�Q�，Kademlia 的异或运��可以��当前节点到目标ID的距��ȝ��略的持箋减半�Q�以此来��L��节点。在�W�二阶段�Q�Pastry不再使用距离�q�算�Q�而是改�ؓ比较ID的数字区别。它使用�W�二�U�，数字区别�q�算作�ؓ替代。不�q�的是，按第二种�q�算计算的接�q�比�W�一�U�的�q�得多，�q�造成特定节点ID值的中断�Q�降低了性能�Q��ƈ且导致在最差行��Z��的正式分析的��试��p�|�?/span>

2 �Q�系�l�描�q?/span>

每个Kademlia节点有一�?60位的节点ID。在Chord�pȝ��中，ID是通过某种规则构造出来的�Q�但在这片文章中�Q��ؓ了简化，我们假设每台机器在加入系�l�时��选择一个随机的160位倹{��每条节点发送的消息包含它的节点ID�Q?同时允许接收者记录下发送者的存在信息�Q�如果有必要的话�?/span>

键，同样也是160位的标识�W�。�ؓ了发布和��L��<键，�?gt;对，Kademlia依赖一个概念，那就是两标识�W�之间的距离的概��c��给定两个标识符�Q?x和y�Q?Kademlia定义两者的位异或（XOR�Q�的�l�果作�ؓ两者的距离�Q�d(x�Q�y)�Q�x⊕y。我们首先注意到异或�q�算是一个有意义的运��，虽然不是�Ƨ几里得�q�算。很明显��h��下面的性质�Q?d(x�Q�x)�Q?�Q�如果x≠y, 则d(x, y)>0�Q��Q意的x, y: d(x, y) = d(y, x)�?异或�q�算�q�满��三角性质�Q�d(x, y) + d(y, z) �?d(x, z)�?�q�个三角性质之所以成立是��Z��下面�q�个事实�Q?d(x, z) = d(x, y) + d(y, z); �q�且��L��的a>=0, b�?: a+b≥a⊕b�?

跟Chord的顺旉��循环�q�算一��P��异或�q�算也是单向的。对于给定的一个点x以及距离Δ�Q�仅有一个点y�Q��得d(x, y) = Δ�?单向性确保所有对于相同的键的查询��汇聚到相同路径中来�Q�而不��是什么�v源节炏V��因此，在查找�\径上�~�存<键，�?gt;对可以减��‘撞车’的��Z��。跟Pastry而不是Chord一��P�� 异或�q�算也是对称的。（�Ҏ��有的x以及y�Q?d(x,y) = d(y,x�Q?

2 �Q?�Q�节点状�?/span>

Kademlia 节点存储互相的联�p�M��息，以用于�\由查询消息。对于�Q�? =< i < 160, 每个节点保存那些到本节点的距��Mؓ2ⁱ�?ⁱ^�Q?之间的节点信息列表，包括。我们把�q�些列表�U�CؓK-桶。每个K-桶中的节�Ҏ��最后联�pȝ��旉��排序――最久未联系的节�Ҏ��在头部，最�q�联�pȝ��节点攑֜��N��。对于比较小的i��|��K-桉��常是空的（因�ؓ没有合适的节点存在于系�l�中�Q�。对于比较大的i��|��列表节点数可以达到k的大��，k是一个系�l��别的冗余参数。k值的选择必须满��一个条�Ӟ��那就是�Q意k个节点在一个小时内都失效的可能性很��（例如k =20�Q��?/span>

�?�Q?/span> 以当前已在线旉��的函数的形式昄��了节点在接下来的一��时后��l�在�U�的比例。X轴代表分钟，y轴代表那些已�l�在�U�了x分钟的节点中��l�在�U?��时的比例�?/span>

当一个Kademlia节点收到来自另外一个节点的��M��消息�Q�请求的或者回复的�Q�，它将更新自己的一个K-�Ӟ��卛_��送节点ID对应的那个桶。如果发送节点已�l�存在于接收者的K-桶中�Q�接收者会把它�U�d��列表的尾部。如果这个节点还没有存在于对应的K-桶中�q�且�q�个桶少于k个节点，则接收者把发送者插入到列表的尾部。如果对应的K-桶已�l�满了，则发送者将向该K-桶中的最久未联系节点发送ping命��o��试是否存在�Q�如果最久未联系节点没有回复�Q�则把它从列表中�U�除�Q��ƈ把新的发送者插入到列表��N��。如果它回复了，则新的发送者信息会丢弃掉�?/span>

K- 桉��帔R��效的实现了剔除最久未联系节点的策略，存活的节点将永远不会从列表中�U�除。这�U�偏向保留旧节点的做法是我们对由Saroiu�{��h攉��的Gnutella协议的跟�t�数据进行分析而得出来的。图1以当前已存在旉��的函数的形式昄��了Gnutella节点在一��时后��l�在�U�的比例。一个节点存�zȝ��旉��长�Q�则�q�个节点�l�箋存活一��时的可能性越大。通过保留存活旉��最长的那些节点�Q�K-桶中存储的节点��l�在�U�的概率大大提高了�?/span>

K- 桶的�W�二个优�Ҏ��它提供了对一定的拒绝服务�Q�DoS�Q�的��d��的抵抗。系�l�中不断涌入新节点�ƈ不会造成节点路由状态的更新�q�快。Kademlia节点只有在旧节点��d��pȝ��时才会向k-桶中插入新节炏V�?/span>

2 �Q?�Q�Kademlia协议

Kademlia 协议�?个远�E�过�E�调用（RPC�Q�组成：PING�Q�STORE�Q�FIND_NODE, FIND_VALUE�?PING RPC ��试节点是否存在。STORE指示一个节点存储一�?lt;键，�?gt;对以用于以后的检索�?/span>

FIND_NODE �?60位ID作�ؓ变量�Q�RPC的接收者将�q�回k个它所知道的最接近目标ID�?lt;IP地址�Q�UDP端口�Q�节点ID>元组。这些元�l�可以来自于一个K-�Ӟ��也可以来自于多个K-�Ӟ��当最接近的K-桶没有满�Ӟ��。在��M��情况下， RPC接收者都必须�q�回k��（除非�q�个节点的所有的K-桶的元组加�v来都��于k个，�q�种情况下RPC接收者返回所有它知道的节点）

FIND_VALUE 和FIND_NODE行�ؓ�怼�――返�?lt;IP地址�Q�UDP端口�Q�节点ID>元组。仅有一�Ҏ��不同的，如果RPC接收者已�l�收��C��q�个键的STORE RPC,则只需要返回这个已存储的倹{�?/span>

在所有RPC中，接收者都必须回应一�?60位的随机RPC ID,�q�可以防止地址伪造。PING中则可以为RPC接收者在RPC回复中捎回以对发送者的�|�络地址获得额外的保证�?/span>

Kademlia 参与者必��d��的最重要的工作是��Z��个给定的节点ID定位k个最接近节点。我们称�q�个�q�程��Ҏ��询。Kademlia使用一�U�递归��法来做节点查询。查询的发�v者从最接近的非�I�的K-桶中取出а个节点（或者，如果�q�个桶没有а项�Q�则只取出它所知道的最接近的几个节点）。发赯��然后向选定的��C��节点发送��^行的�Q�异步的FIND_NODE RPC。а是一个系�l��别的�q�行参数�Q�比如�ؓ3�?/span>

在这个递归的步骤中�Q�发赯��重新发送FIND_NODE�l�那些从上次RPC中学习到的节点（�q�个递归可以在之前的所有的а个RPC�q�回之前开始）。在�q�返回的与目标最接近的k个节点中�Q�发赯��将选择а个还没有被询问过的节点�ƈ且重新发送FIND_NODE RPC�l�它们。没有立即作出响应的节点��不再予以考虑除非�q�且直到它们作出响应。如果经�q�一轮的FIND_NODE都没有返回一个比已知最接近的节�Ҏ��接近的节点，则发赯��将重新向所有k个未曾询问的最接近节点发送FIND_NODE。直到发赯��已�l�询问了k个最接近节点�q�且得到了响应，�q�个查询才结束。当а�Q?�Ӟ��查询��法在消息开支和��失效节�Ҏ��的时延上与Chord非常�怼��?然而，Kademlia可以做到低时延�\由因为它有��够的灉|��性来选择k个节点中的一个去做查询�?/span>

按照上面的查询过�E�，大多数的操作都可以实现。要存储一�?lt;键，�?gt;对，参与者定位k个与键最接近的节点然后向�q�些节点发送STORE RPC。另外，每个节点每个��时都会重新发布它所有的<键，�?gt;寏V��这可以以高概率的把握确�?lt;键，�?gt;对的持箋存在于系�l�中�Q�我们将会在验证概略一节中看到�Q�。通常来说�Q�我们还要求<键，�?gt;对的原始发布者每�?4��时重新发布一�ơ。否则，所有的<键，�?gt;对在最原始发布�?4��时后失效，以尽量减��系�l�中的陈旧信息�?/span>

最后，��Z��l�持<键，�?gt;对在发布�Q�搜索生命周期中的一致性，我们要求��M��时候节点w拥有一个新节点u�Q�u比w更接�q�w中的一�?lt;键，�?gt;寏V��w��复制这�?lt;键，�?gt;对给u�q�且不从自己的数据库中删除�?/span>

��Z��查找��C��?lt;键，�?gt;对，节点首先查找k个ID与键接近的节炏V��然而，值查询��用FIND_VALUE而不是FIND_NODE RPC�?而且�Q�只要�Q何节点返回了��|��则这个过�E�立即结束。�ؓ了缓�?caching)的缘故，只要一个查询成功了�Q�这个请求节点将会把�q�个<键，�?gt;对存储到它拥有的最接近的�ƈ且没能返回值的节点上�?/span>

�׃��q�个拓扑的单向性，对相同的键的以后的搜索将很有可能在查询最接近节点前命中已�~�存的项。对于一个特定的键，�l�过多次的查扑֒�传播�Q�系�l�可能在许多的节点上都缓存了�q�个键。�ؓ了避免“过度缓存”，我们设计了一�?lt;键，�?gt;对在��M��节点的数据库中的存活旉��与当前节点和与键ID最接近的节点ID之间的节�Ҏ��成指数��的反比例关系。简单的剔除最久未联系节点会导致相似的生存旉��分布�Q�没有很自然的方法来选择�~�存大小�Q�因��点不能提前知道系�l�将会存储多��个倹{�?/span>

一般来��_��׃��存在于节点之间的查询的通信�Q�桶会保持不停地��h��。�ؓ了避免当没有通信时的病态情况，每个节点对在一个小时内没有做过节点查询的桶�q�行��h��Q�刷新意味着在桶的范围内选择一个随机ID然后��个ID做节�Ҏ��索�?/span>

��Z��加入到这个网�l�中�Q�节点u必须与一个已�l�加入到�|�络中的节点w联系。u把w加入到合适的桶中�Q�然后u��q��节点ID做一�ơ节�Ҏ��找。最后，节点u��h��所有比最接近的邻居节�Ҏ��q�的K-桶。在�q�个��h��q�程中，节点u�q�行了两��必需的工作：既填充了自己的K-�Ӟ��又把自己插入��C��其它节点的K-桶中�?/span>

3 �Q�验证概�q?/span>

��Z��验证我们�pȝ��中的�Ҏ��的函敎ͼ�我们必须证实�l�大多数的操作花�?/span> [ log n] + c 的时间开销�Q��ƈ且c是一个比较小的常敎ͼ��q�且 < 键，�?gt;查找��会以很高的概率�q�回一个存储在�pȝ��中的键�?/span>

我们首先做一些定义。对于一个覆盖距��ȝ��范围�?/span> [ 2 i , 2 i +1) �?/span> K- �Ӟ��定义�q�个桶的索引号�ؓi。定义节点的深度h�?60�Q�i�Q�其中i是最��的非空的桶的烦引号。定义在节点x中节点y的桶高度为y��插入到x的桶的烦引号减去x的最不重要的�I�桶的烦引号。由于节点ID是随机选择的，因此高度的不�l�一分布是不太可能的。因此，在非帔R��的概率下�Q��Q意一个给定节点的高度在log n之内�Q�其中n是系�l�中的节�Ҏ��。而且�Q�对于一个ID�Q�最接近节点在第k接近的节点中的桶高度很有可能是在常数log k之内�?/span>

下一步我们将假设一个不变的条�g�Q�那��是每个节点的每个K-桶包含至��一个节点的联系信息�Q�如果这个节点存在于一个合适的范围中。有了这个假设，我们可以发现节点的查找过�E�是正确的�ƈ且时间开销是指数��的。假设与目标ID最接近的节点的深度是h。如果这个节点的h个最有意义的K-桉��是非�I�的�Q�查询过�E�在每一步都可以查找��C��个到目标节点的距��L��接近一半的节点�Q�或者说距离更近了一个bit�Q�，因此�?/span> h - log k 步后目标节点��会出现�?/span> 如果�q�个节点的一个K-桶是�I�的�Q�可能是�q�样的一�U�情况，目标节点恰好在空桶对应的距离范围之内。这�U�情况下�Q�最后的几步�q�不能��距离减半。然而，搜烦�q�是能正��的�l�箋下去��像键中与空桶相关的那个位已�l�被�|�反了。因此，查找��法��L��能在 h - log k 步后 �q�回最接近节点。而且�Q�一旦最接近节点已经扑ֈ��Q��ƈ行度会从а扩展到k。寻扑ֈ�剩下的k-1个最接近节点的步数将不会��过最接近节点在第k接近节点中的桉��度，即不太可能超�q�log k加上一个常数�?/span>

��Z��证实前面的不变条件的正确性，首先考虑桶刷新的效果�Q�如果不变条件成立。在被刷新后�Q�一个桶或者包含k个有效节点，或者包含在它范围内的所有节点，如果��于k个节点存在的话（�q�是从节点的查找�q�程的正��性而得出来的。）新加入的节点也会被插入到��M��没有满的桶中厅R��因此，唯一�q�反�q�个不变条�g的方法就是在一个特别的桶的范围内存在k+1个活更多的节点，�q�且桶中的k个节点在没有查找或刷新的�q�涉下全部失效。然而，k��D��_��的选择以保证��所有节点在一��时内（最大的��h��旉��Q�全都失效的概率��_��?/span>

实际上，��p�|的概率比k个节点在1��时内全都离开的概率小得多�Q�因为每个进入或外出的请求消息都会更新节点的桶。这是异或运��的对称性��生的�Q�因为在一�ơ进入或外出的请求中�Q�与一个给定节炚w��信的对端节点的ID在该节点的桶范围之内的分布是非常均匀的�?/span>

而且�Q�即使这个不变条件在单个节点的单个桶中的��失效了�Q�这也只影响到运行时��_��在某些查询中��d��一个蟩敎ͼ��Q��ƈ不会影响到节�Ҏ��扄��正确性。只有在查找路径中的k个节炚w��必须在没有查找或��h��的干涉下在相同的桶中丢失k个节点，才可能造成一�ơ查扑֤�败。如果不同的节点的桶没有重叠�Q�这�U�情况发生的概率�?^-k*k。否则，节点出现在多个其它的节点的桶中，�q�就很可能会有更长的�q�行旉��和更低概率的��p�|情况�?/span>

现在我们来考虑�?lt;键，�?gt;对的恢复问题。当一�?lt;键，�?gt;对发布时�Q�它��在k个与键接�q�的节点中存储。同时每隔一��时��重新发布一�ơ。因为即使是新节点（最不可靠的节点�Q�都�?/2的概率持�l�存�z�M��个小�Ӟ��一个小时后<键，�?gt;对仍然存在于k个最接近节点中的一个上的概率是1-2^-k �?/span> �q�个性质�q�不会由于有接近键的新节点的插入而改变，因�ؓ一旦有�q�样的节�Ҏ��入，它们��Z��填充它们的桶��会与他们的最接近的那些节点交互，从而收到附�q�的它们应该存储�?lt;键，�?gt;寏V��当�Ӟ��如果�q�k个最接近键的节点都失效了�Q��ƈ且这�?lt;键，�?gt;�Ҏ��有在其它��M��地方�~�存�Q�Kademlia��会丢失�q�个<键，�?gt;寏V�?/span>

4 �Q�讨�?/span>

我们使用的基于异或拓扑的路由��法与Pastry [1], Tapestry [2]的�\��q��法中的第一步和 Plaxton的分布式搜烦��法都非常的�怼�。然而，所有的�q�三个算法，当他们选择一�ơ接�q�目标节点b个bit的时候都会��生问题（��Z��加速的目的�Q�。如果没有异或拓扑，我们�q�需要一个额外的��法�l�构来从与目标节�Ҏ��有相同的前缀但是接下来的b个bit的数字不同的节点扑ֈ�目标节点。所有的�q�三个算法在解决�q�个问题上采取的�Ҏ��都是各不相同的，每个都有其不��之处；它们在大��ؓ O (2 b log 2 b n ) 的主表之�?/span> �?/span> 另外需�?/span> 一�?/span> 大小�?/span> O (2 b ) �?/span> �ơ要路由表，�q�增加了自�D和维护的开支，使协议变的更加复杂了�Q�而且对于Pastry和Tapestry来说��L��了正��性与一致性的正式分析。Plaxton虽然可以得到证实�Q�但在像点对点（P2P�Q�网�l�中的极易失效的环境中不太适应�?/span>

相反�Q�Kademlia则非常容易的以不�?的基数被优化。我们可以配�|�我们的桶表来��每一跳b个bit的速度来接�q�目标节炏V��这��p��求满��一个条�Ӟ��那就是�Q意的 0 < j < 2^b �? 0 �?/span> i < 160 /b �Q?/span> 在与我们的距��Mؓ[j2^160-(i+1)b, (j+1)2^160-(i+1)b] 的范围内��p��有一个桶�Q�这个有实际的项的总量预计不会��过个桶。目前的实现中我们��ob�Q?�?/span>

5 �Q��ȝ��

使用了新颖的��Z��异或�q�算的拓扑，Kademlia是第一个结合了可证实的一致性和高性能�Q�最��时延�\由，和一个对�U�ͼ�单向的拓扑的点对�?P2P)�pȝ��。此外，Kademlia引入了一个�ƈ发参敎ͼ�а�Q�这让�h们可以通过调整带宽的一个常数参数来�q�行异步最低时延的跳选择和不产生时�g的失效恢复。最后，Kademlia是第一个利用了节点失效与它的已�q�行旉��成反比这个事实的点对点（P2P�Q�系�l��?/span>

参考文�?/span>

[1] A. Rowstron and P. Druschel. Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. Accepted for Middleware, 2001, 2001. http://research.microsoft.com/˜antr/pastry/.

[2] Ben Y. Zhao, John Kubiatowicz, and Anthony Joseph. Tapestry: an infrastructure for fault-tolerant wide-area location and routing. Technical Report UCB/CSD-01-1141, U.C. Berkeley, April 2001.

[3] Andr´ea W. Richa C. Greg Plaxton, Rajmohan Rajaraman. Accessing nearby copies of replicated objects in a distributed environment. In Proceedings of the ACM SPAA, pages 311�?20, June 1997.

[4] Stefan Saroiu, P. Krishna Gummadi and Steven D. Gribble. A Measurement Study of Peer-to-Peer File Sharing Systems. Technical Report UW-CSE-01-06-02, University of Washington, Department of Computer Science and Engineering, July 2001.

[5] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup service for internet applications. In Proceedings of the ACM SIGCOMM �?1 Conference, San Diego, California, August 2001.

CPP&&设计模式��屋 2006-09-11 16:18 发表评论

Kademlia详解 (转脓NeoRagex2002)

CPP&&设计模式��屋 — Mon, 11 Sep 2006 06:09:00 GMT

Kademlia详解 (转脓NeoRagex2002)

前两天在�|�上看到世界知名的电骡服务器Razorback 2被查��?��拘禁的消息，深感当前做eMule / BitTorrent�{�P2P文�g交换软�g的不易。以分布式哈希表方式(DHT�Q�Distributed Hash Table)来代曉K��中烦引服务器可以说是目前可以预见到的为数不多的P2P软�g发展��势之一�Q�比较典型的�Ҏ��主要包括�Q�CAN、CHORD、Tapestry、Pastry、Kademlia和Viceroy�{�，而Kademlia协议则是其中应用最为广泛、原理和实现最为实用、简�z�的一�U�，当前��L��的P2P软�g无一例外地采用了它作��q��辅助��索协议，如eMule、Bitcomet、Bitspirit和Azureus�{�。鉴于Kademlia日益增长的强大媄响力�Q�今天特地在blog里写下这��小文，��是对其相关知识�pȝ��的�ȝ��?

1. Kademlia��q?/b>

Kademlia(��U�Kad)属于一�U�典型的�l�构化P2P覆盖�|�络(Structured P2P Overlay Network)�Q�以分布式的应用层全�|�方式来�q�行信息的存储和��索是其尝试解决的主要问题。在Kademlia�|�络中，所有信息均�?key, value="" />的哈希表条目形式加以存储�Q�这些条目被分散地存储在各个节点上，从而以全网方式构成一张巨大的分布式哈希表。我们可以�Ş象地把这张哈希大表看成是一本字典：只要知道了信息烦引的key�Q�我们便可以通过Kademlia协议来查询其所对应的value信息�Q�而不��这个value信息�I�竟是存储在哪一个节点之上。在eMule、BitTorrent�{�P2P文�g交换�pȝ��中，Kademlia主要充当了文件信息检索协议这一关键角色�Q�但Kad�|�络的应用�ƈ不仅限于文�g交换。下文的描述��主要围�l�eMule中Kad�|�络的设计与实现展开�?/p>

2. eMule的Kad�|�络中究竟存储了哪些信息?

只要是能够表�q�成�?key, value="" />字典条目形式的信息Kad�|�络均能存储�Q�一个Kad�|�络能够同时存储多张分布式哈希表。以eMule��Z��Q�在��M��时刻�Q�其Kad�|�络均存储�ƈ�l�护着两张分布式哈希表�Q�一张我们可以将其命名�ؓ关键词字典，而另一张则可以�U�C��为文件烦引字典�?/p>

a. 关键词字�?/b>�Q�主要用于根据给出的关键词查询其所对应的文件名�U�及相关文�g信息�Q�其中key的值等于所�l�出的关键词字符串的160比特SHA1散列�Q�而其对应的value则�ؓ一个列表，在这个列表当中，�l�出了所有的文�g名称当中拥有对应关键词的文�g信息�Q�这些信息我们可以简单地用一�?元组条目表示�Q?文�g名，文�g长度�Q�文件的SHA1校验�?�Q��D个例子，假定存在着一个文件“warcraft_frozen_throne.iso”，当我们分别以“warcraft”、“frozen”、“throne”这三个关键词来查询Kad�Ӟ��Kad��有可能分别�q�回三个不同的文件列表，�q�三个列表的共同之处则在于它们均包含着一个文件名为“warcraft_frozen_throne.iso”的信息条目�Q�通过该条目，我们可以获得对应iso文�g的名�U�、长度及�?60比特的SHA1校验倹{�?/p>

b. 文�g索引字典�Q�用于根据给出的文�g信息来查询文件的拥有�?卌��文�g的下载服务提供�?�Q�其中key的值等于所需下蝲文�g的SHA1校验�?�q�主要是因�ؓ�Q�从�l�计学角度而言�Q?60比特的SHA1文�g校验值可以唯一地确定一份特定数据内容的文�g)�Q�而对应的value也是一个列表，它给��Z��当前所有拥有该文�g的节点的�|�络信息�Q�其中的列表条目我们也可以用一�?元组表示�Q?拥有者IP�Q�下载侦听端口，拥有者节点ID)�Q�根据这些信息，eMule便知道该到哪里去下蝲具备同一SHA1校验值的同一份文件了�?/p>

3. 利用Kad�|�络搜烦�q�下载文件的基本��程是怎样�?

��Z��我们对eMule的Kad�|�络中两本字典的理解�Q�利用Kad�|�络搜烦�q�下载某一特定文�g的基本过�E�便很明白了�Q�仍以“warcraft_frozen_throne.iso”�ؓ例，首先我们可以通过warcraft、frozen、throne�{��Q一关键词查询关键词字典�Q�得到该iso的SHA1校验��|��然后再通过该校验值查询Kad文�g索引字典�Q�从而获得所有提供“warcraft_frozen_throne.iso”下载的�|�络节点�Q��而以分段下蝲方式去这些节点下载整个iso文�g�?/p>

在上�q�过�E�中�Q�Kad�|�络实际上所��L��作用��q��当于两本字典�Q�但值得再次指出的是�Q�Kad�q�不是以集中的烦引服务器(如华语P2P源动力、Razorback 2、DonkeyServer �{�，骡友们应该很熟悉�?方式来实现这两本字典的存储和搜烦的，因�ؓ�q�两本字典的所�?key, value="" />条目均分布式地存储在参与Kad�|�络的各节点中，相关文�g信息、下载位�|�信息的存储和交换均无需集中索引服务器的参与�Q�这不仅提高了查询效率，而且�q�提高了整个P2P文�g交换�pȝ��的可靠性，同时具备相当的反拒绝服务��d��能力�Q�更有意思的是，它能帮助我们有效地抵制FBI的追捕，因�ؓ俗话说得好：法不��M��…看到这里，�怿�大家都能理解“分布式信息��索”所带来的好处了吧。但是，�q�些条目�I�竟是怎样存储的呢?我们又该如何通过Kad�|�络来找到它�?不着急，慢慢来�?/p>

4. 什么叫做节点的ID和节点之间的距离?

Kad�|�络中的每一个节点均拥有一个专属ID�Q�该ID的具体�Ş式与SHA1散列值类��|��Z��个长�?60bit的整敎ͼ�它是��p��点自己随机生成的�Q�两个节�Ҏ��有同一ID的可能性非�怹��，因此可以认�ؓ�q�几乎是不可能的。在Kad�|�络中，两个节点之间距离�q�不是依靠物理距��R��\由器��x��来衡量的�Q�事实上�Q�Kad�|�络��Q意两个节点之间的距离d定义为其二者ID值的逐比特二�q�制和数�Q�即�Q�假定两个节点的ID分别为a与b�Q�则有：d=a XOR b。在Kad中，每一个节炚w��可以�Ҏ��q�一距离概念来判断其他节点距��自��q��“远�q�”，当d值大�Ӟ��节点间距��较�q�，而当d值小�Ӟ��则两个节点相距很�q�。这里的“远�q�”和“距��Z��都只是一�U�逻辑上的度量描述而已�Q�在Kad中，距离�q�一度量是无方向性的�Q�也��是说a到b的距��L��{�于b到a的距��，因�ؓa XOR b==b XOR a

5. 条目是如何存储在Kad�|�络中的?

从上文中我们可以发现节点ID�?key, value="" />条目中key值的�怼�性：无论是关键词字典的key�Q�还是文件烦引字典的key�Q�都�?60bit�Q�而节点ID恰恰也是160bit。这昄��是有目的的。事实上�Q�节点的ID��g��决定了哪些条目可以存储在该节点之中�Q�因为我们完全可以把某一�?key, value="" />条目��单地存放在节点ID值恰好等于条目中key值的那个节点处，我们可以��满��?ID==key)�q�一条�g的节点命名�ؓ目标节点N。这��L��话，一个查�?key, value="" />条目的问题便被简单地转化成�ؓ了一个查找ID�{�于Key值的节点的问题�?/p>

�׃��在实际的Kad�|�络当中�Q��ƈ不能保证在�Q一时刻目标节点N均一定存在或者在�U�，因此Kad�|�络规定�Q��Q一条目�Q�依据其key的具体取��|��该条目将被复制�ƈ存放在节点ID距离key值最�q?卛_��前距��ȝ��标节点N最�q?的k个节点当中；之所以要��?key, value="" />重复保存k份，�q�完全是考虑到整个Kad�pȝ��E�_��性而引入的冗余�Q�这个k的取��g��有讲�IӞ��它是一个带有启发性质的估计��|��挑选其取值的准则为：“在当前规模的Kad�|�络中�Q意选择臛_��k个节点，令它们在��L��时刻同时不在�U�的几率几乎�?”；目前�Q�k的典型取��gؓ20�Q�即�Q��ؓ保证在�Q何时��L��们均能找到至��一份某条目的拷贝，我们必须事先在Kad�|�络中将该条目复制至��?0份�?/p>

�׃��q�可知，对于某一条目�Q�在Kad�|�络中ID��靠�q�key的节点区域，该条目保存的份数��p��多，存储得也��集中；事实上，��Z��实现较短的查询响应�g�q�，在条目查询的�q�程中，��M��条目可被cache��C�Q意节点之上；同时��Z��防止�q�度cache、保证信息��够新鲜，必须考虑条目在节点上存储的时效性：��接�q�目标结点N�Q�该条目保存的时间将��长�Q�反之，其超时时间就��短�Q�保存在目标节点之上的条目最多能够被保留24��时�Q�如果在此期间该条目被其发布源重新发布的话，其保存时间还可以�q�一步�g�ѝ�?/p>

6. Kad�|�络节点需要维护哪些状态信�?

在Kad�|�络中，每一个节点均�l�护�?60个list�Q�其中的每个list均被�U�C��Z��个k-�?k-bucket)�Q�如下图所�C�。在�W�i个list中，记录了当前节点已知的与自�w�距��Mؓ2^i~2^(i+1)的一些其他对端节点的�|�络信息(Node ID�Q�IP地址�Q�UDP端口)�Q�每一个list(k-�?中最多存放k个对端节点信息，注意�Q�此处的k与上文所提到的复制系数k含义是一致的�Q�每一个list中的对端节点信息均按讉K��旉��排序�Q�最早访问的在list头部�Q�而最�q�新讉K��的则攑֜�list的尾部�?/p>

k-桶中节点信息的更新基本遵循Least-recently Seen Eviction原则�Q�当list定w��未满(k-桶中节点个数未满k�?�Q�且最新访问的对端节点信息不在当前list中时�Q�其信息��直接添入list队尾�Q�如果其信息已经在当前list中，则其��被�U�d��至队��；在k-桶容量已满的情况下，��d��新节点的情况有点�Ҏ��Q�它��首先检查最早访问的队首节点是否仍有响应�Q�如果有�Q�则队首节点被移至队��，新访问节点信息被抛弃�Q�如果没有，�q�才抛弃队首节点�Q�将最新访问的节点信息插入队尾。可以看出，��可能重用已有节点信息、�ƈ且按旉��排序是k-桶节�Ҏ��新方式的主要特点。从启发性的角度而言�Q�这�U�方式具有一定的依据�Q�在�U�时间长一点的节点更值得我们信�Q�Q�因为它已经在线了若�q�小�Ӟ��因此�Q�它在下一个小时以内保持在�U�的可能性将比我们最新访问的节点更大�Q�或者更直观点，我这里再�l�出一个更加�h性化的解释：MP3文�g交换本��n是一�U�触犯版权法律的行�ؓ�Q�某一个节点反正已�l�犯了若�q�个��时的法了，因此�Q�它��比其他新加入的节点更不在乎再多犯一个小时的�|�…�?_-b

�׃��可见�Q�设计采用这�U�多k-bucket数据�l�构的初衷主要有二：a. �l�护最�q?最新见到的节点信息更新�Q�b. 实现快速的节点信息�{�选操作，也就是说�Q�只要知道某个需要查扄��特定目标节点N的ID�Q�我们便可以从当前节点的k-buckets�l�构中迅速地查出距离N最�q�的若干已知节点�?/p>

7. 在Kad�|�络中如何寻找某特定的节�?

已知某节点ID�Q�查找获得当前Kad�|�络中与之距��L��短的k个节�Ҏ��对应的网�l�信�?Node ID�Q�IP地址�Q�UDP端口)的过�E�，即�ؓKad�|�络中的一�ơ节�Ҏ��询过�E?Node Lookup)。注意，Kad之所以没有把节点查询�q�程严格地定义成��Z��仅只查询单个目标节点的过�E�，�q�主要是因�ؓKad�|�络�q�没有对节点的上�U�时间作��Z�Q何前提假设，因此在多数情况下我们�q�不能肯定需要查扄��目标节点一定在�U�或存在�?/p>

整个节点查询�q�程非常直接�Q�其方式�c�M��于DNS的�P代查询：
a. 由查询发赯��从自己的k-桶中�{�选出若干距离目标ID最�q�的节点�Q��ƈ向这些节点同时发送异步查询请求；
b .被查询节�Ҏ��到请求之后，��从自己的k-桶中扑և�自己所知道的距��L��询目标ID最�q�的若干个节点，�q�返回给发�v者；
c. 发�v者在收到�q�些�q�回信息之后�Q�再�ơ从自己目前所有已知的距离目标较近的节点中挑选出若干没有��h��q�的�Q��ƈ重复步骤1�Q?br />d. 上述步骤不断重复�Q�直��x��法获得比查询者当前已知的k个节�Ҏ��接近目标的活动节点�ؓ止�?br />e. 在查询过�E�中�Q�没有及时响应的节点��立卌��排除�Q�查询者必��M��证最�l�获得的k个最�q�节炚w��是活动的�?/p>

��单�ȝ��一下上�q�过�E�，实际上它跟我们日常生�z�M��L��某一个�h打听某�g事是非常�怼�的，比方说你是个Agent Smith�Q�想扑ְ��?key)问问他的手机��L��(value)�Q�但你事先�ƈ不认识他�Q�你首先肯定会去找你所认识的和��李在同一个公司工作的人，比方说小赵，然后��n又会告诉你去找与和小李在同一部门的小刘，然后��刘又会�q�一步告诉你��L��和小李在同一个项目组的小张，最后，你找��C��张�Q�哟�Q�正好小李出差去�?节点下线�?�Q�但��张恰好知道��李的号码，�q�样你�ȝ��扑ֈ�了所需的信息。在节点查找的过�E�中�Q�“节点距��ȝ��q�近”实际上与上面例子中“�h际关�pȝ��密切�E�度”所代表的含义是一��L��?br />

最后说说上�q�查询过�E�的局限性：Kad�|�络�q�不适合应用于模�p�搜索，如通配�W�支持、部分查扄��场合�Q�但对于文�g�׃�n场合来说�Q�基于关键词的精��查扑֊�能已�l�基本��够了(值得注意的是�Q�实际上我们只要对上�q�查找过�E�稍加改�q�，�q�可以��o其支持基于关键词匚w��的布��条件查询，但仍不够优化)。这个问题反映到eMule的应用层面来�Q�它直接说明了文件共享时其命名的重要性所在，卻I��文�g名中的关键词定义得越明显�Q�则该文件越�Ҏ��被找刎ͼ�从而越有利于其在P2P�|�络中的传播�Q�而另一斚w��Q�在eMule中，每一个共享文件均可以拥有自己的相��x��释，而Comment的重要性还没有被大家认识到�Q�实际上�Q�这个文件注释中的关键词也可以直接被利用来替代文件名关键词，从而指导和方便用户搜烦�Q�尤其是当文件名本��n�q�没有体现出关键词的时候�?/p>

8. 在Kad�|�络中如何存储和搜烦某特定的条目?

从本质上而言�Q�存储、搜索某特定条目的问题实际上��是节点查找的问题。当需要在Kad�|�络中存储一个条目时�Q�可以首先通过节点查找��法扑ֈ�距离key最�q�的k个节点，然后再通知它们保存条目卛_��。而搜索条目的�q�程则与节点查询�q�程也是基本�c�M��Q�由搜烦发�v方以�q�代方式不断查询距离key较近的节点，一旦查询�\径中的�Q一节点�q�回了所需查找的value�Q�整个搜索的�q�程��q��束。�ؓ提高效率�Q�当搜烦成功之后�Q�发��h��可以选择��搜索到的条目存储到查询路径的多个节点中�Q�作为方便后�l�查询的cache�Q�条目cache的超时时间与节点-key之间的距��d��指数反比关系�?/p>

9. 一个新节点如何首次加入Kad�|�络?

当一个新节点首次试图加入Kad�|�络�Ӟ��它必��d��三�g事，其一�Q�不��通过何种途径�Q�获知一个已�l�加入Kad�|�络的节点信�?我们可以�U�C��点I)�Q��ƈ��其加入自己的k-buckets�Q�其二，向该节点发�v一�ơ针对自己ID的节�Ҏ��询请求，从而通过节点I获取一�p�d��与自��p��邻�q�的其他节点的信息；最后，��h��所有的k-bucket�Q�保证自己所获得的节点信息全部都是新鲜的�?/p>

CPP&&设计模式��屋 2006-09-11 14:09 发表评论

久久久婷婷五月亚洲97号色,国产午夜精品久久久久九九电影,国产91色综合久久免费分享

P2P之UDP�I�K��NAT的原理与实现�Q�附源代码）

Peer-to-Peer (P2P) communication across middleboxes(�?

P2P直播相关(�?

Kademlia: ��Z��异或�q�算的P2P信息�pȝ��(���译�E?

Kademlia详解 (转脓NeoRagex2002)

Kademlia详解 (转脓NeoRagex2002)

Kademlia: ��Z��异或�q�算的P2P信息�pȝ��(��译�E?