随笔 - 7  文章 - 5  trackbacks - 0
<2006年11月>
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

目前在研究生阶段,主要是做基于J2EE的web services

常用链接

留言簿(2)

随笔分类

文章分类

最新随笔

最新评论

      今天修改了jsf的验证器部分...看到了对于email的验证.....看起来还是有点头大呀.....于是乎翻javadoc....找到了java.util.regex.Pattern类....挺有意思的...一起分享一下...... 

java.util.regex
类 Pattern

java.lang.Objectjava.util.regex.Pattern
所有已实现的接口:
Serializable

public final class Pattern
extends Object
implements Serializable

正则表达式的编译表示形式。

指定为字符串的正则表达式必须首先被编译为此类的实例。然后,可将得到的模式用于创建 Matcher 对象,依照正则表达式,该对象可以与任意字符序列匹配。执行匹配所涉及的所有状态都驻留在匹配器中,所以多个匹配器可以共享同一模式。

因此,典型的调用顺序是

 Pattern p = Pattern.compile("a*b");
 Matcher m = p.matcher("aaaaab");
 boolean b = m.matches();

在仅使用一次正则表达式时,可以方便地通过此类定义 matches 方法。此方法编译表达式并在单个调用中将输入序列与其匹配。语句

 boolean b = Pattern.matches("a*b", "aaaaab");
等效于上面的三个语句,尽管对于重复的匹配而言它效率不高,因为它不允许重用已编译的模式。

此类的实例是不可变的,可供多个并发线程安全使用。Matcher 类的实例用于此目的则不安全。

正则表达式的构造摘要

构造匹配
 
字符
x字符 x
\\反斜线字符
\0n带有八进制值 0 的字符 n (0 <= n <= 7)
\0nn带有八进制值 0 的字符 nn (0 <= n <= 7)
\0mnn带有八进制值 0 的字符 mnn(0 <= m <= 3、0 <= n <= 7)
\xhh带有十六进制值 0x 的字符 hh
\uhhhh带有十六进制值 0x 的字符 hhhh
\t制表符 ('\u0009')
\n新行(换行)符 ('\u000A')
\r回车符 ('\u000D')
\f换页符 ('\u000C')
\a报警 (bell) 符 ('\u0007')
\e转义符 ('\u001B')
\cx对应于 x 的控制符
 
字符类
[abc]abc(简单类)
[^abc]任何字符,除了 abc(否定)
[a-zA-Z]azAZ,两头的字母包括在内(范围)
[a-d[m-p]]admp[a-dm-p](并集)
[a-z&&[def]]def(交集)
[a-z&&[^bc]]az,除了 bc[ad-z](减去)
[a-z&&[^m-p]]az,而非 mp[a-lq-z](减去)
 
预定义字符类
.任何字符(与行结束符可能匹配也可能不匹配)
\d数字:[0-9]
\D非数字: [^0-9]
\s空白字符:[ \t\n\x0B\f\r]
\S非空白字符:[^\s]
\w单词字符:[a-zA-Z_0-9]
\W非单词字符:[^\w]
 
POSIX 字符类(仅 US-ASCII)
\p{Lower}小写字母字符:[a-z]
\p{Upper}大写字母字符:[A-Z]
\p{ASCII}所有 ASCII:[\x00-\x7F]
\p{Alpha}字母字符:[\p{Lower}\p{Upper}]
\p{Digit}十进制数字:[0-9]
\p{Alnum}字母数字字符:[\p{Alpha}\p{Digit}]
\p{Punct}标点符号:!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
\p{Graph}可见字符:[\p{Alnum}\p{Punct}]
\p{Print}可打印字符:[\p{Graph}\x20]
\p{Blank}空格或制表符:[ \t]
\p{Cntrl}控制字符:[\x00-\x1F\x7F]
\p{XDigit}十六进制数字:[0-9a-fA-F]
\p{Space}空白字符:[ \t\n\x0B\f\r]
 
java.lang.Character 类(简单的 java 字符类型
\p{javaLowerCase}等效于 java.lang.Character.isLowerCase()
\p{javaUpperCase}等效于 java.lang.Character.isUpperCase()
\p{javaWhitespace}等效于 java.lang.Character.isWhitespace()
\p{javaMirrored}等效于 java.lang.Character.isMirrored()
 
Unicode 块和类别的类
\p{InGreek}Greek 块(简单)中的字符
\p{Lu}大写字母(简单类别
\p{Sc}货币符号
\P{InGreek}所有字符,Greek 块中的除外(否定)
[\p{L}&&[^\p{Lu}]] 所有字母,大写字母除外(减去)
 
边界匹配器
^行的开头
$行的结尾
\b单词边界
\B非单词边界
\A输入的开头
\G上一个匹配的结尾
\Z输入的结尾,仅用于最后的结束符(如果有的话)
\z输入的结尾
 
Greedy 数量词
X?X,一次或一次也没有
X*X,零次或多次
X+X,一次或多次
X{n}X,恰好 n
X{n,}X,至少 n
X{n,m}X,至少 n 次,但是不超过 m
 
Reluctant 数量词
X??X,一次或一次也没有
X*?X,零次或多次
X+?X,一次或多次
X{n}?X,恰好 n
X{n,}?X,至少 n
X{n,m}?X,至少 n 次,但是不超过 m
 
Possessive 数量词
X?+X,一次或一次也没有
X*+X,零次或多次
X++X,一次或多次
X{n}+X,恰好 n
X{n,}+X,至少 n
X{n,m}+X,至少 n 次,但是不超过 m
 
Logical 运算符
XYX 后跟 Y
X|YXY
(X)X,作为捕获组
 
Back 引用
\n任何匹配的 nth捕获组
 
引用
\Nothing,但是引用以下字符
\QNothing,但是引用所有字符,直到 \E
\ENothing,但是结束从 \Q 开始的引用
 
特殊构造(非捕获)
(?:X)X,作为非捕获组
(?idmsux-idmsux) Nothing,但是将匹配标志由 on 转为 off
(?idmsux-idmsux:X)  X,作为带有给定标志 on - off 的非捕获组
(?=X)X,通过零宽度的正 lookahead
(?!X)X,通过零宽度的负 lookahead
(?<=X)X,通过零宽度的正 lookbehind
(?<!X)X,通过零宽度的负 lookbehind
(?>X)X,作为独立的非捕获组

反斜线、转义和引用

反斜线字符 ('\') 用于引用转义构造,如上表所定义的,同时还用于引用其他将被解释为非转义构造的字符。因此,表达式 \\ 与单个反斜线匹配,而 \{ 与左括号匹配。

在不表示转义构造的任何字母字符前使用反斜线都是错误的;它们是为将来扩展正则表达式语言保留的。可以在非字母字符前使用反斜线,不管该字符是否非转义构造的一部分。

根据 Java Language Specification 的要求,Java 源代码的字符串中的反斜线被解释为 Unicode 转义或其他字符转义。因此必须在字符串字面值中使用两个反斜线,表示正则表达式受到保护,不被 Java 字节码编译器解释。例如,当解释为正则表达式时,字符串字面值 "\b" 与单个退格字符匹配,而 "\\b" 与单词边界匹配。字符串字面值 "\(hello\)" 是非法的,将导致编译时错误;要与字符串 (hello) 匹配,必须使用字符串字面值 "\\(hello\\)"

字符类

字符类可以出现在其他字符类中,并且可以包含并集运算符(隐式)和交集运算符 (&&)。并集运算符表示至少包含其某个操作数类中所有字符的类。交集运算符表示包含同时位于其两个操作数类中所有字符的类。

字符类运算符的优先级如下所示,按从最高到最低的顺序排列:

1    字面值转义    \x
2    分组[...]
3    范围a-z
4    并集[a-e][i-u]
5    交集[a-z&&[aeiou]]

注意,元字符的不同集合实际上位于字符类的内部,而非字符类的外部。例如,正则表达式 . 在字符类内部就失去了其特殊意义,而表达式 - 变成了形成元字符的范围。

行结束符

行结束符 是一个或两个字符的序列,标记输入字符序列的行结尾。以下代码被识别为行结束符:

如果激活 UNIX_LINES 模式,则新行符是惟一识别的行结束符。

如果未指定 DOTALL 标志,则正则表达式 . 可以与任何字符(行结束符除外)匹配。

默认情况下,正则表达式 ^$ 忽略行结束符,仅分别与整个输入序列的开头和结尾匹配。如果激活 MULTILINE 模式,则 ^ 在输入的开头和行结束符之后(输入的结尾)才发生匹配。处于 MULTILINE 模式中时,$ 仅在行结束符之前或输入序列的结尾处匹配。

组和捕获

捕获组可以通过从左到右计算其开括号来编号。例如,在表达式 ((A)(B(C))) 中,存在四个这样的组:

1    ((A)(B(C)))
2    \A
3    (B(C))
4    (C)

组零始终代表整个表达式。

之所以这样命名捕获组是因为在匹配中,保存了与这些组匹配的输入序列的每个子序列。捕获的子序列稍后可以通过 Back 引用在表达式中使用,也可以在匹配操作完成后从匹配器检索。

与组关联的捕获输入始终是与组最近匹配的子序列。如果由于量化的缘故再次计算了组,则在第二次计算失败时将保留其以前捕获的值(如果有的话)例如,将字符串 "aba" 与表达式 (a(b)?)+ 相匹配,会将第二组设置为 "b"。在每个匹配的开头,所有捕获的输入都会被丢弃。

(?) 开头的组是纯的非捕获 组,它不捕获文本,也不针对组合计进行计数。

Unicode 支持

此类符合 Unicode Technical Standard #18:Unicode Regular Expression Guidelines 第 1 级和 RL2.1 Canonical Equivalents。

Java 源代码中的 Unicode 转义序列(如 \u2014)是按照 Java Language Specification 的 第 3.3 节中的描述处理的。这样的转义序列还可以由正则表达式分析器直接实现,以便在从文件或键盘击键读取的表达式中使用 Unicode 转义。因此,可以将不相等的字符串 "\u2014""\\u2014" 编译为相同的模式,从而与带有十六进制值 0x2014 的字符匹配。

与 Perl 中一样,Unicode 块和类别是使用 \p\P 构造编写的。如果输入具有属性 prop,则与 \p{prop} 匹配,而输入具有该属性时与 \P{prop} 不匹配。块使用前缀 In 指定,与在 InMongolian 中一样。可以使用可选前缀 Is 指定类别:\p{L}\p{IsL} 都表示 Unicode 字母的类别。块和类别在字符类的内部和外部都可以使用。

受支持的类别是由 Character 类指定版本中的 The Unicode Standard 的类别。类别名称是在 Standard 中定义的,即标准又丰富。Pattern 所支持的块名称是 UnicodeBlock.forName 所接受和定义的有效块名称。

行为类似 java.lang.Character boolean 是 methodname 方法(废弃的类别除外)的类别,可以通过相同的 \p{prop} 语法来提供,其中指定的属性具有名称 javamethodname

与 Perl 5 相比较

Pattern 引擎用有序替换项执行传统上基于 NFA 的匹配,与 Perl 5 中进行的相同。

此类不支持 Perl 构造:

此类支持但 Perl 不支持的构造:

与 Perl 的显著不同点是:

  • 在 Perl 中,\1\9 始终被解释为 Back 引用;如果至少存在多个子表达式,则大于 9 的反斜线转义数按 Back 引用对待,否则在可能的情况下,它将被解释为八进制转义。在此类中,八进制转义必须始终以零开头。在此类中,\1\9 始终被解释为 Back 引用,较大的数被接受为 Back 引用,如果在正则表达式中至少存在多个子表达式的话;否则,分析器将删除数字,直到该数小于或等于组的现有数或者其为一个数字。

  • Perl 使用 g 标志请求恢复最后匹配丢失的匹配。此功能是由 Matcher 类显式提供的:重复执行 find 方法调用可以恢复丢失的最后匹配,除非匹配器被重置。

  • 在 Perl 中,位于表达式顶级的嵌入式标记对整个表达式都有影响。在此类中,嵌入式标志始终在它们出现的时候才起作用,不管它们位于顶级还是组中;在后一种情况下,与在 Perl 中类似,标志在组的结尾处还原。

  • Perl 允许错误匹配构造,如在表达式 *a 中,以及不匹配的括号,如在在表达式 abc] 中,并将其作为字面值对待。此类还接受不匹配的括号,但对 +、? 和 * 不匹配元字符有严格限制;如果遇到它们,则抛出 PatternSyntaxException

有关正则表达式构造行为更准确的描述,请参见《Mastering Regular Expressions, 2nd Edition》,该书由 Jeffrey E. F. Friedl、O'Reilly 和 Associates 合著,于 2002 年出版。

从以下版本开始:
1.4
另请参见:
String.split(String, int), String.split(String), 序列化表格

字段摘要
static intCANON_EQ
          启用规范等价。
static intCASE_INSENSITIVE
          启用不区分大小写的匹配。
static intCOMMENTS
          模式中允许空白和注释。
static intDOTALL
          启用 dotall 模式。
static intLITERAL
          启用模式的字面值分析。
static intMULTILINE
          启用多行模式。
static intUNICODE_CASE
          启用 Unicode 感知的大小写折叠。
static intUNIX_LINES
          启用 Unix 行模式。
 
方法摘要
static Patterncompile(String regex)
          将给定的正则表达式编译到模式中。
static Patterncompile(String regex, int flags)
          将给定的正则表达式编译到具有给定标志的模式中。
 intflags()
          返回此模式的匹配标志。
 Matchermatcher(CharSequence input)
          创建匹配给定输入与此模式的匹配器。
static booleanmatches(String regex, CharSequence input)
          编译给定正则表达式并尝试将给定输入与其匹配。
 Stringpattern()
          返回在其中编译过此模式的正则表达式。
static Stringquote(String s)
          返回指定 String 的字面值模式 String
 String[]split(CharSequence input)
          围绕此模式的匹配拆分给定输入序列。
 String[]split(CharSequence input, int limit)
          围绕此模式的匹配拆分给定输入序列。
 StringtoString()
          返回此模式的字符串表示形式。
 
从类 java.lang.Object 继承的方法
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait


这样下来检验email的代码也是相当简单呀....
     boolean b = Pattern.matches("^\\w+@\\w+(\\.\\w+)+", email);

posted @ 2006-11-18 22:38 Stefanie 阅读(5918) | 评论 (1)编辑 收藏

P2P网络的拓扑结构

拓扑结构是指分布式系统中各个计算单元之间的物理或逻辑的互联关系,结点之间的拓扑结构一直是确定系统类型的重要依据。目前互联网络中广泛使用集中式、层次式等拓扑结构。Internet本身是世界上最大的非集中式的互联网络,但是九十年代所建立的一些网络应用系统却是完全的集中式的系统,许多Web应用都是运行在集中式的服务器系统上。集中式拓扑结构系统目前面临着过量存储负载、DOS(Denial of Service,拒绝服务)攻击,网络带宽限制等一些难以解决的问题。Peer-to-Peer (简称P2P) 系统主要采用非集中式的拓扑结构,一般来说不存在上述这些难题。根据结构关系可以将P2P系统细分为四种拓扑形式:

  • 中心化拓扑(Centralized Topology);
  • 全分布式非结构化拓扑(Decentralized Unstructured Topology);
  • 全分布式结构化拓扑(Decentralized Structured Topology,也称作DHT网络);
  • 半分布式拓扑(Partially Decentralized Topology)。

其中,中心化拓扑最大的优点是维护简单,资源发现效率高。由于资源的发现依赖中心化的目录系统,发现算法灵活高效并能够实现复杂查询。最大的问题与传统客户机/服务器结构类似,容易造成单点故障,访问的“热点”现象和版权纠纷等相关问题,这是第一代P2P网络采用的结构模式,经典案例就是著名的MP3共享软件Napster[1].

Napster是最早出现的P2P系统之一,并在短期内迅速成长起来。它实质上并非是纯粹的P2P系统,而是通过一个中央索引服务器保存所有Napster用户上传的音乐文件索引和存放位置的信息。它的工作原理如图1所示。当某个用户需要某个音乐文件时,首先连接到Napster中央索引服务器,在服务器上进行检索,服务器返回存有该文件的用户信息,再由请求者直接连到文件的所有者传输文件。Napster首先实现了文件查询与文件传输的分离,有效地节省了中央服务器的带宽消耗,减少了系统的文件传输延时。

图1 Napster的拓扑结构

然而,这种对等网络模型存在以下这些问题:

  • 中央索引服务器的瘫痪容易导致整个网络的崩溃,因此可靠性和安全性较低。
  • 随着网络规模的扩大,对中央索引服务器进行维护和更新的费用将急剧增加,所需成本较高。
  • 中央索引服务器的存在常引起版权问题上的纠纷,服务提供商容易被追究法律责任。

综合上述优缺点,对小型网络而言,中心化拓扑模型在管理和控制方面占一定优势。但鉴于其存在的上述缺陷,该模型并不适合大型网络应用。

全分布式非结构化拓扑的P2P网络是在重叠网络(Overlay Network)(见标注1)采用了随机图的组织方式,结点度数服从Power-law规律(幂次法则)[2],从而能够较快发现目的结点,面对网络的动态变化体现了较好的容错能力,因此具有较好的可用性。同时可以支持复杂查询,如带有规则表达式的多关键词查询,模糊查询等,采用这种拓扑结构最典型的案例便是Gnutella(音译:纽特拉)。准确地说,Gnutella不是特指某一款软件,而是指遵守Gnutella协议[3]的网络以及客户端软件的统称。目前基于Gnutella网络的客户端软件非常多,著名的有ShareazaLimeWire和BearShare等。

图2Gnutella的拓扑结构和文件检索方法

Gnutella和Napster最大的区别在于Gnutella是更加纯粹的P2P系统,因为它没有中央索引服务器,每台机器在Gnutella网络中是真正的对等关系,既是客户机同时又是服务器,所以被称为对等机(Servent,Server+Client的组合)。在文件检索方面,它与Napster也不相同。在Gnutella网络的发展初期,它主要采用基于完全随机图的Flooding搜索算法。图2 显示了Flooding的工作流程:当一台计算机要下载一个文件,它首先以文件名或者关键字生成一个查询,并把这个查询发送给与它相连的所有计算机,这些计算机如果存在这个文件,则与查询的机器建立连接,如果不存在这个文件,则继续在自己相邻的计算机之间转发这个查询,直到找到文件为止。为了控制搜索消息不至于永远这样传递下去,一般通过TTL (Time To Live)的减值来控制查询的深度。

但是,随着联网节点的不断增多,网络规模不断扩大,通过这种Flooding方式定位对等点的方法将造成网络流量急剧增加,从而导致网络中部分低带宽节点因网络资源过载而失效。所以在初期的Gnutella网络中,存在比较严重的分区,断链现象。也就是说,一个查询访问只能在网络的很小一部分进行,因此网络的可扩展性不好。所以,后来许多研究人员在Flooding的基础上作了许多改进,例如采用Random work [4]、Dynamic Query[5]等方法。

由于非结构化网络将重叠网络认为是一个完全随机图,结点之间的链路没有遵循某些预先定义的拓扑来构建。这些系统一般不提供性能保证,但容错性好,支持复杂的查询,并受结点频繁加入和退出系统的影响小。但是查询的结果可能不完全,查询速度较慢,采用Flooding查询的系统对网络带宽的消耗非常大,并由此带来可扩展性差等问题。

全分布式结构化拓扑的P2P网络主要是采用分布式散列表(Distributed Hash Table, 简写成DHT)技术来组织网络中的结点。DHT是一个由广域范围大量结点共同维护的巨大散列表。散列表被分割成不连续的块,每个结点被分配给一个属于自己的散列块,并成为这个散列块的管理者。通过加密散列函数,一个对象的名字或关键词被映射为128位或160位的散列值。分布式散列表起源于SDDS(Scalable Distribute Data Structures)[6]研究,Gribble等实现了一个高度可扩展,容错的SDDS集群。DHT类结构能够自适应结点的动态加入/退出,有着良好的可扩展性、鲁棒性、结点ID分配的均匀性和自组织能力。由于重叠网络采用了确定性拓扑结构,DHT可以提供精确的发现。只要目的结点存在于网络中DHT总能发现它,发现的准确性得到了保证,最经典的案例是Tapestry,Pastry,Chord和CAN。

Tapestry [7]提供了一个分布式容错查找和路由基础平台,在此平台基础之上,可以开发各种P2P应用(OceanStore[8]即是此平台上的一个应用)。Tapestry的思想来源于Plaxton。在Plaxton中,结点使用自己所知道的邻近结点表,按照目的ID来逐步传递消息。Tapestry基于Plaxton的思想,加入了容错机制,从而可适应P2P的动态变化的特点。OceanStore是以Tapestry为路由和查找基础设施的P2P平台。它是一个适合于全球数据存储的P2P应用系统。任何用户均可以加入OceanStore系统,或者共享自己的存储空间,或者使用该系统中的资源。通过使用复制和缓存技术,OceanStore可提高查找的效率。最近,Tapestry为适应P2P网络的动态特性,作了很多改进,增加了额外的机制实现了网络的软状态(soft state),并提供了自组织、鲁棒性、可扩展性和动态适应性,当网络高负载且有失效结点时候性能有限降低,消除了对全局信息的依赖、根结点易失效和弹性差的问题。

Pastry 是微软研究院提出的可扩展的分布式对象定位和路由协议,可用于构建大规模的P2P系统。如图3 所示,在Pastry中,每个结点分配一个128位的结点标识符号(nodeID) ,所有的结点标识符形成了一个环形的nodeID空间,范围从0到2128 - 1 ,结点加入系统时通过散列结点IP地址在128位nodeID空间中随机分配。网络结点的加入与退出,资源查询的过程可以参考文献[9]。

图3Pastry的消息路由

Chord [10]项目诞生于美国的麻省理工学院。它的目标是提供一个适合于P2P环境的分布式资源发现服务,它通过使用DHT技术使得发现指定对象只需要维护O(logN)长度的路由表。在DHT技术中,网络结点按照一定的方式分配一个唯一结点标识符(Node ID) ,资源对象通过散列运算产生一个唯一的资源标识符(Object ID) ,且该资源将存储在结点ID与之相等或者相近的结点上。需要查找该资源时,采用同样的方法可定位到存储该资源的结点。因此,Chord的主要贡献是提出了一个分布式查找协议,该协议可将指定的关键字(Key) 映射到对应的结点(Node) 。从算法来看,Chord是相容散列算法的变体。

图4 Chord的拓扑形状

CAN(Content Addressable Networks)[11] 项目采用多维的标识符空间来实现分布式散列算法。CAN将所有结点映射到一个n维的笛卡尔空间中,并为每个结点尽可能均匀的分配一块区域。CAN采用的散列函数通过对(key, value) 对中的key进行散列运算,得到笛卡尔空间中的一个点,并将(key, value) 对存储在拥有该点所在区域的结点内。CAN采用的路由算法相当直接和简单,知道目标点的坐标后,就将请求传给当前结点四邻中坐标最接近目标点的结点。CAN是一个具有良好可扩展性的系统,给定N个结点,系统维数为d,则路由路径长度为O(n1/d) ,每结点维护的路由表信息和网络规模无关为O(d) 。

上述四种基于DHT的P2P系统的性能比较可以参照[12]。DHT这类结构最大的问题是DHT的维护机制较为复杂,尤其是结点频繁加入退出造成的网络波动(Churn)会极大增加DHT的维护代价。DHT所面临的另外一个问题是DHT仅支持精确关键词匹配查询,无法支持内容/语义等复杂查询。

半分布式拓扑结构(有的文献亦称作混杂模式,英文表达为Hybrid Structure)吸取了中心化结构和全分布式非结构化拓扑的优点,选择性能较高(处理、存储、带宽等方面性能)的结点作为超级结点(英文表达为SuperNodes或者Hubs),在各个超级结点上存储了系统中其他部分结点的信息,发现算法仅在超级结点之间转发,超级结点再将查询请求转发给适当的叶子结点。半分布式结构也是一个层次式结构,超级结点之间构成一个高速转发层,超级结点和所负责的普通结点构成若干层次。采用这种结构的最典型的案例就是KaZaa

图5 半分布式拓扑结构(网络中包含Super Node)

KaZaa是当前世界最流行的几款P2P文件共享软件之一。根据CA公司统计,全球KaZaa的下载量超过2.5亿次。使用KaZaa软件进行文件传输消耗了互联网40%的带宽。之所以它如此的成功,是因为它结合了Napster和Gnutella共同的优点。从结构上来说,它使用了Gnutella的全分布式的结构,这样可以是系统更好的扩展,因为它无需中央索引服务器存储文件名,它是自动的把性能好的机器成为SuperNode,它存储着离它最近的叶子节点的文件信息,这些SuperNode,再连通起来形成一个Overlay Network. 由于SuperNode的索引功能,使搜索效率大大提高。

图6 KaZaa的软件界面

半分布式结构的优点是性能、可扩展性较好,较容易管理,但对超级点依赖性大,易于受到攻击,容错性也受到影响。

在实际应用中,每种拓扑结构的P2P网络都有其优缺点,下表从可扩展性、可靠性、可维护性、发现算法的效率、复杂查询等方面比较了这四种拓扑结构的综合性能。

比较标准/拓扑结构

中心化拓扑

全分布式非结构化拓扑

全分布式结构化拓扑

半分布式拓扑

可扩展性

可靠性

可维护性

最好

最好

发现算法效率

最高

复杂查询

支持

支持

不支持

支持



我还是比较看好chord...虽然目前还有不少问题没有解决....
顺便附上一篇经典的chord论文: Chord: A Scalable Peertopeer Lookup Service for Internet Applications
http://www.blogjava.net/Files/heiyuchuanxia/chord_sigcomm.rar
posted @ 2006-11-15 15:28 Stefanie 阅读(3447) | 评论 (0)编辑 收藏