DHT= Distributed Hash Table
store the objects(files) at nodes (hosts, machines) in a cluster. The cluster might be distrubuted out throughout the world.
Load balancing: 你希望每个node或者每个host有大至数量相同的objects,你不希望某些hosts负载过多,而某些hosts却只有很少的objects.
Fault-tolerance: 与hash table不同的是,hash table: you can't lose a bucket but still have another.In a distributed hash table: you could lose a node but still have another round. 所以fault-tolerance becomes a concern here: You want to make sure that even though some of the nodes might fail or might just leave the system(due to churn), you don't want to lose any objects.
Locality: You want the messages that are transmitted among the cluster to be transmitted preferably among nodes that are closed in the underlying network topology.
Napster,Guntella,FastTrack都是某种DHT，but they are not really because they don't really try to optimize, the insert, look up ,delete times.
Chord is one of the first peer-to-peer systems which tries to directly address this problem and tries to bring the insert,delete and lookup time down low enough.所以我们称它为真正的DHT.
Napster与Gnutella的比较
Napster的client端存储的是自己这个client要上传的文件，是constant的，所以忽略不计。Server端存储了一些client的directory信息，directory信息会随着client的数量而增长O(N),Server load很高，是O(N)
Napster的查询延时是O(1),因为当知道信息在哪儿时，通过直接去找来找到自己所需的信息。(忽略server里面的查找)
the number of messages for a lookup: O(1)因为它it's just one round-trip time.
Gnutella，没有servers(you only have this overlay graph),所以memory可能是O(N),因为如果client在neighbors的数量上没有限制的话，你就会有O（N）的peers.
Lookup latency: O(N),因为当graph的拓扑结构为一条直线时，当你有一个file存储在直线的末端时，你需要O(N)的时间
the number of messages for a lookup:因为当graph的拓扑结构为一条直线时，当你有一个file存储在直线的末端时，你需要2*N-1条消息，所以为O(N)
当结点很多时，O（N）是一个很大的消耗，这就是为什么引入Chord的原因:
log(N)非常好，因为在特定需求下，它与constant一样好，如log21000=10,log2(232)=32
Chord是如何获得这么好的效率的呢
Chord使用的技术是:in the peer-to-peer overlay每个结点以一种智能的方式来选择它的neighbors.在Gnutella系统中，nodes是使用metrics(如分享的文件数目，分享的字节数)来选择它们的neighbors，它们使用ping和pong消息。
Chord使用consistent Hashing. The consistent Hashing有不同的解释，这儿先给出一种解释，之后会给出一种更流行的解释。
Consisten Hashing是指使用a peer的IP address and port number(这用来唯一的标识一个peer)，然后使用一个well-known hash function(比如说SHA-1 function,simple hash algorithm,是一个well-known cryptographic function),这个function的输出是一个160bits的字符串，不管它的输入是多少，它的输出总是160bits的字符串.使用hash function的一个好处是，使用同样的输入，不管在哪儿运行它，你将得到相同的160bits的输出字符串。将这160bits的字符串截断为mbits的字符串（m是系统参数，用来决定一个peer Id，介于0 - 2m-1). (IP_address, port number)-> hash function->160bit->mbit.当m足够大时，冲突是不可能发生的，你没必要去做防止冲突的措施(事实上需要2m比nodes(hosts)的数量要大).
你可以画一个圆，这个圆是由2m(0-2m-1)个logical points组成
第一种类型的peer pointer
N16，N32，N45...这些是peer Id，是由(IP_address, port number)-> hash function->160bit->mbit(m=7,ID 0-127)得来的.这个圆按照顺时针的方向来，N16的下一个node是N32等等。nodes如何保存它们的neighbors的信息呢，是保存successor的信息，如N16保存N32的ip_address和port number,所以它可以直接给N32发送信息；N112保存N16的ip_address和port number,所以它可以直接给N16发送信息.同样你也可以保存predecessors的信息(即逆时针的方向)。在实际中，Chord通常是使用successor.
第二种类型的peer pointer
m=7,则finger table有7个元素(下标从0-6), 存储的是沿着顺时针方向遇到的第一个>= n+ 2i (mod 2m)peer id的值。
File怎么存储
与Napster与Gnutella（clients存储它们的文件默认不上传这些文件）不同的是，文件存储在一些special nodes上面，基于同样的rules that we are using for placing the servers on the ring.即we take filename(假设在整个系统是唯一的)，给它应用同样的hash function,the SHA-1,然后你得到一个160bits的字符串，然后你截断它(just like we did for peer ids),然后你再把这个file映射到ring上面某个point上去
如file cnn,com/index.html 用hash map得到的key是42,然后这个file就存储在顺时针的第一个结点上面(如上图是结点45).
注意到这儿我们是假设filename是唯一的，我们使用的是链接做为filename,我们是故意这样做的，特别是在peer-to-peer system，在系统中我们任意的交换mp3,MPEG files,但这个并不是一个限制条件，你可以使用peer-to-peer system去开发其它的application比如说cooperative web caching(client browsers穿过大量的clients,互相分享它们的web result),所以他们拥有更快的浏览器因为你能够取得一些已经由临近你的其它人得到的页面，在这种情况下，URLs变得很普遍了，因为是object(webpages)的名字.在这儿是想说明，peer-to-peer system能够被用于存储任何类型的objects,只要这个object有唯一的名字。
consistent hashing: with k keys in the system and N peers in the system,每个peer会存储O(K/N)keys,这意味着你的系统里面的结点有很好的load balance,这个load balance正是我们的目的。
the rest of system how to work--search
比如说N80想要查找K42的文件（该文件存放在N45）,将query发送给 根据Finger Table at N80里面最靠近42的，但是<=42(在42的逆时针方向)的node，在这里是N16。然后N16接收到query后，查找本是否有该文件，没有的话继续以相同的规则发送query，根据Finger Table at N16,最靠近42的是N32，则将query发送给N32,N32接收到query后，查看本地是否有该文件，没有的话继续发送query,根据Finger Table at N32,没有在42的逆时针方向的结点，则根据第二条规则(if none exist, send query to successor),将query发送给N45,N45查找本地是否有该文件，查找成功，则返回给N80消息查找成功。
上图中有3个hops,这些hops是RPCs(remote procedure calls),this is a well-known abstraction in distributed systems
Search时间性能分析(O(logN))
分析
O(log(N))是对任何routing操作都是这样的，如插入，删除，修改 key。
O(log(N))是在finger table和successor是正确的情况下成立的，当网络发生变化(如某个node离开网络)，但是finger table还没有更新的情况下，就不成立了。
