dvdlkdvd的网摘列表

搜索词： 时间： 任何时候 最近一周 最近一个月 最近一季度 最近半年 最近一年 分类： 所有分类 系统维护[82] web2.0[72] 搜索引擎[61] Linux[60] 资料[35] Oracle[34] database[33] ajax[32] Google[29] Java[29] Semantic_Web[28] 开发模式[24] 技巧[24] 系统框架[23] 安全[19] 编码[17] RSS[15] Lucene[13] web设计[13] tomcat[13] web_services[12] blog[12] javascript[12] 元数据[12] mysql[12] eclipse[11] XML[10] 正则表达式[10] Microformats[10] 存储备份[10] 算法[8] SOA[8] rdf[7] 本体[7] 测试[7] CSS[7] 构件[7] 生活[6] api[6] tag[6] Apache[6] 垂直搜索引擎[6] 娱乐[5] cms[5] 社会性网络[5] Flickr[5] 负载均衡[5] 全文检索[5] 语义处理[5] awstats[5] p2p[5] Web[4] 数字图书馆[4] sql_server[4] shell[4] opml[4] 互操作[4] 人生感悟[4] 设计[4] veritas[4] 中间件[4] informix[4] 工具[4] 日志[4] 保先[3] 六度分割[3] 社会性软件[3] 备份[3] J2EE[3] awk[3] 专业词汇[3] ftp[3] rpm[3] 逻辑卷[3] JSR[3] RIA[3] mashup[3] 电影[3] XHTML[3] HTML[3] DC[3] 多媒体[3] IT[2] 故障排除[2] cvs[2] ISCSI[2] 资源组织[2] rmvb[2] C&C++[2] 网格[2] Windows[2] 管理[2] 异步交互[2] Bash[2] 集群[2] 硬件[2] DB2[2] 健康[2] Ruby[2] json[2] 生活态度[2] 经济[2] Maven[2] 存储[2] WiFi[2] Technorati[2] 3d[2] 创新[2] 美食[2] tcpdump[2] SSH[2] 地图[2] snmp[2] 数图[2] vcs[2] 高可用[2] ebay[2] 财经[1] 情报科学[1] RPC[1] 知识组织[1] 商业数据库[1] 学术数据库[1] 150法则[1] IM[1] word[1] UI[1] OWL[1] San[1] php[1] 框架[1] servlet[1] 影音[1] DVDRIP[1] XSLT[1] .net[1] url重写[1] Rails[1] sed[1] 个人知识管理PKM[1] 聚合[1] 桌面搜索[1] tivo[1] 图像处理[1] wlan[1] Hibernate[1] 个性化[1] 软件[1] 豆瓣[1] WordPress[1] Python[1] 面向对象[1] 语言[1] wikipedia[1] 搜索[1] 图像搜索[1] Rank[1] ROR[1] 用户体验[1] 信息抽取[1] 台湾[1] 黑河[1] VNC[1] 鬼故事[1] 网络[1] 小说[1] 开源[1] 编程[1] sns[1] ICE[1] Digg[1] 图片[1] music[1] 翻译[1] ha[1] Feed[1] 程序[1] Ant[1] Ontology[1] 优化[1] 卫星电视[1] velocity[1] SWT[1] 性能检测[1] openurl[1] SOAP[1] REST[1] sso[1] OpenID[1] NTFS[1] 学习[1] 新闻 体育 军事 文化 私有 其他 Services 编程语言 pdf      排序： 按相关度 按时间倒序

刷新列表 共1页、5项网摘

TV的Google观察Blog: Foldershare以及P2p在线存储服务 点击：30 　分类：p2p; 存储　时间：2006-10-5 15:51:59　dvdlkdvd收录　(还有4人收录)　 Foldershare正好有这么一个功能，在两台电脑之间同步目录。非常方便，只要你在两台机器上面设置好，然后你就什么都不用管了。你在A机器对文件做了任何修改，Foldershare立刻记录在案，如果B机器在线就直接把修改发送给B机器，否则就B机器在线的时候自动完成同步。当然，既然他是纯粹基于P2p技术的，那么他就有一个无法解决的问题，那就是A和B必须同时在线，才会进行同步。 基于P2p的在线存储业务，所有的数据保存在客户端，服务器只保存更新日志。客户机修改了数据后，更新服务器的同步日志。服务器在其他同步客户机上线的时候根据同步日志，来协调客户机之间的数据传输。这样服务提供者就无需支付昂贵的空间和流量成本了。 当然这也带来了新的问题。如果我需要在A和B两台机器之间同步数据，我就需要它们至少在某一个时刻是同时在线的，这个时候同步流程才能启动。而对大多数需要同步的用户来说，这可能是一个不可能逾越的障碍（除非他们不在乎电费以及让机器24小时开着可能带来的火灾隐患）。 就像解决平面几何问题经常会做的那样，我们引入一个辅助线。如果现在有第三台机器可以永久在线，或者在你的两台机器不能在线的时候它可以恰好在线的话。所有问题就解决了。这第三台机器在传统的在线存储中实际上就是服务器，而在这里我们发现，他可以是任何一台客户机。那么，为什么会有人肯提供这第三台机器呢？ P2p虚拟存储空间市场 现在考虑如下的场景，我现在需要第三台机器，在我短暂的两台机器都不在线的切换期帮助我保存我的共享数据的更新，而不是让我的某一台机器24小时在线。那么，我可能愿意用金钱购买这个临时存储，或者用我的机器在线期间帮助别人提供同等服务作为交换。这个时候，就产生了一个虚拟存储空间的交换市场。这样，你就可以把你的空闲硬盘空间拿出去换钱了。当然，这种市场需要大量的用户参与才取得比较好的效果。 而基于P2p和同步协议的在线存储方案，还能带来另一个变化，那么就是如果服务提供者想自己提供空间服务，他的存储单元配置方式也变得非常简单。 http://tinygoogle.blogspot.com/2006/09/foldersharep2p.html

[精华] P2P原理的解释与实现 - C/C - ChinaUnix.net 点击：35 　分类：安全; p2p　时间：2006-9-3 23:31:15　dvdlkdvd收录　 私有地址/端口和公有地址/端口:我们知道,现在大部分网络采用的都是NAPT(Network Address/Port Translator)了,这个东东的作用是一个对外的对话在经过NAT之后IP地址和端口号都会被改写,在这里把一次会话中客户自己认为在使用的IP地址和端口号成为私有地址/端口,而把经过NAPT之后被改写的IP地址和端口号称为公有地址/端口.或者可以这么理解,私有地址/端口是你家里人对你的昵称而公有地址/端口则是你真正对外公开的名字.如何获得用户的私用地址/端口号,这个很简单了,而要得到公有地址/端口号就要在连接上另一台机器之后由那台机器看到的IP地址和端口号来表示. 客户端首先得到自己的私有地址/终端,然后向server端发送登陆请求,server端在得到这个请求之后就可以知道这个client端的公有地址/终端,server会为每一个登陆的client保存它们的私有地址/端口和公有地址/端口. OK,下面开始关键的打洞流程.假设client A要向client B对话,但是A不知道B的地址,即使知道根据NAT的原理这个对话在第一次会被拒绝,因为client B的NAT认为这是一个从没有过的外部发来的请求.这个时候,A如果发现自己没有保存B的地址,或者说发送给B的会话请求失败了,它会要求server端让B向A打一个洞,这个B->A的会话意义在于它使NAT B认为A的地址/端口是可以通过的地址/端口,这样A再向B发送对话的时候就不会再被NAT B拒绝了.打一个比方来说明打洞的过程,A想来B家做客,但是遭到了B的管家NAT B的拒绝,理由是:我从来没有听我家B提过你的名字,这时A找到了A,B都认识的朋友server,要求server给B报一个信,让B去跟管家说A是我的朋友,于是,B跟管家NAT B说,A是我认识的朋友,这样A的访问请求就不会再被管家NAT B所拒绝了.简而言之,UDP打洞就是一个通过server保存下来的地址使得彼此之间能够直接通信的过程,server只管帮助建立连接,在建立间接之后就不再介入了. http://bbs.chinaunix.net/viewthread.php?tid=822168

P2P 之 UDP穿透NAT的原理与实现（附源代码）-- 点击：44 　分类：安全; p2p　时间：2006-9-3 23:29:51　dvdlkdvd收录　 NAT(Network Address Translators)，网络地址转换：网络地址转换是在IP地址日益缺乏的情况下产生的，它的主要目的就是为了能够地址重用。NAT分为两大类，基本的NAT和NAPT(Network Address/Port Translator)。 我们看到，通过NAT,子网内的计算机向外连结是很容易的（NAT相当于透明的，子网内的和外网的计算机不用知道NAT的情况）。 但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是P2P所需要的）。 那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢？首先，我们必须在内网的NAT上打上一个“洞”（也就是前面我们说的在NAT上建立一个 Session），这个洞不能由外部来打，只能由内网内的主机来打。而且这个洞是有方向的，比如从内部某台主机（比如：192.168.0.10）向外部的某个IP(比如：219.237.60.1)发送一个UDP包，那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”，（这就是称为UDP Hole Punching的技术）以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。（但是其他的IP不能利用这个洞）。 呵呵，现在该轮到我们的正题P2P了。有了上面的理论，实现两个内网的主机通讯就差最后一步了：那就是鸡生蛋还是蛋生鸡的问题了，两边都无法主动发出连接请求，谁也不知道谁的公网地址，那我们如何来打这个洞呢？我们需要一个中间人来联系这两个内网主机。 http://www.cnpaf.net/Class/hack/0512182034513804825.htm

Tinyfool的开发日记(blog): eMule协议简要分析[二] 点击：42 　分类：p2p　时间：2006-6-24 15:33:49　dvdlkdvd收录　(还有1人收录)　 客户端到客户端之间的连接 电骡客户端一般是为了下载某个文件才会连接到其他的客户端（也就是源）的。一个文件会被分为很多块。客户端会从多个客户端（源）那里下载同一个文件，从不同的源下载文件的不同部分（这样不同的部分就可以同时被下载，如果源多，下载的效率就会极高）。 当两个客户端连接后，他们会交换容量信息，然后协商开始下载(或者说是上传,这取决于视角)的时间。每个客户端有一个下载队列，用来保存正在等待下载的客 户端的列表。当电骡客户端的下载对列为空的时候，下载请求会被马上接受（除非这个请求者已经被屏蔽）。如果下载对列不为空，那么新的下载请求就会放在队列 之中。不会努力服务更多的客户端，对每个下载客户端至少保持不少于2.k字节/每秒。一个正在下载的客户端的下载地位可能被一个对列等级（queue ranking）比他高的等待客户端抢占，在下载进程中的前15分钟正在下载的客户端的队列等级会增长用来避免产生颠簸（这里说的颠簸就是说，一个客户端频繁的从下载地位切换到等待状态，然后再切换回去。这种频繁的切换叫做颠簸，这对资源是种浪费，所以要避免。）。 当正在下载的客户端到达了下载队列的顶部，提供上传的客户端初始化一个连接用于把它需要的文件片断传送给它。一个电骡客户端可能会在多个源客户端的等待队 列中，在每个客户端上注册要求同一个文件片断。当这个等待客户端实际上完成了这个文件片断的下载，他不会通知那些源客户端删除它的请求，而仅仅是在它在那 些源客户端的队列中排到顶端的时候拒绝上传请求而已。 电骡使用一个声望系统来鼓励上传，为了防止假冒，电骡用RSA公钥加密技术来保护声望系统。 客户端连接中会使用很多电驴协议（eDonkey protocol）没有定义的消息，这些消息叫做扩展协议。扩展协议用来实现信用系统，用来进行信息交换（例如，服务器列表的更新和源的更新），通过对文 件块进行压缩提升发送和接收的效率。电骡客户端连接中有限地使用UDP去周期其他客户端的状态。 http://www.tinydust.net/prog/diary/2005/11/emule_19.html

Tinyfool的开发日记(blog): eMule协议专题 点击：26 　分类：p2p　时间：2006-6-24 15:32:21　dvdlkdvd收录　 电骡eMule是基于电驴eDonkey协议的。电骡网络是由数百个电骡服务器和数百万的电骡客户端组成的。客户端必须连接到服务器来获得网络服务，这个连接要一直保持直到客户端关闭。服务器提供集中的索引服务（类同Napster），不同的服务器之间没有通讯。 每个电骡客户端都预先设置好了一个服务器列表和一个本地共享文件列表。客户端通过一个单一的TCP连接到电骡服务器进行网络登陆，得到想要的文件的信息和可用客户端的信息。（这样造成了电骡和电驴都不能完全去中心化，虽然文件存储在客户端上。） 电骡客户端用几百个TCP连接与其他的客户端连接进行文件的上传和下载。每个电骡客户端为它的共享文件维护一个上传队列。正在下载的客户端加入这个队列的 底部，然后逐渐的前进，直到他们达到队列的顶端开始下载文件。一个客户端可能从多个其他的电骡客户端下载同一个文件，从不同的客户端取得不同的部分。客户 端也可以上传一个没有完全下载的文件的部分数据。（文件可以分块传输大大提高了效率，但是也造成了一些问题，比如源提前退出以后，所有的客户端都是不完全数据的情况。）最终，电骡扩展了电驴的能力允许客户端交换关于服务器、其他客户端和文件的信息。（这个能力又开始把中心的意义淡化。）注意，客户端和服务器的通信都是基于TCP的。 服务器使用一个内部数据库来保存客户端和文件的信息。电骡服务器不保存任何文件，它是文件位置信息的中心索引。服务器的另一个功能，正在受到质疑，他将作为通过防火墙连接的客户端之间的桥梁，这样的客户端不能接受引入的连接。桥接功能大大的增加了服务器的负载。（这个功能让服务器承担了过分的负担，大大降低了服务器的能力，在设计中应该摒弃，目前应用中大部分的服务器已经关闭了这个功能，也就是说两个Low id的客户端是不能传输数据的。）电骡使用UDP增强客户端跟服务器和其他客户端的通信能力。但是客户端收发UDP信息的能力不是客户端日常操作强制要求的，即使防火墙阻止客户端收发UDP信息，客户端仍能完美的工作。 http://www.tinydust.net/prog/diary/2005/11/emule.html#1

页码： ［1］ 共1页、5项网摘

使用帮助 |  如何保存网摘 |  给365Key提建议 |  媒体报道 |  站长推广须知 Copyright (C) 2004 365Key.com--天天网摘 All Rights Reserved