CN115567517A - 一种基于IPFS的p2p分件分发方法 - Google Patents

一种基于IPFS的p2p分件分发方法 Download PDF

Info

Publication number
CN115567517A
CN115567517A CN202211253761.9A CN202211253761A CN115567517A CN 115567517 A CN115567517 A CN 115567517A CN 202211253761 A CN202211253761 A CN 202211253761A CN 115567517 A CN115567517 A CN 115567517A
Authority
CN
China
Prior art keywords
file
node
ipfs
nat
port
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211253761.9A
Other languages
English (en)
Inventor
吴海霖
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Quanzhou Gravel Eagle Stone Technology Co ltd
Original Assignee
Quanzhou Gravel Eagle Stone Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Quanzhou Gravel Eagle Stone Technology Co ltd filed Critical Quanzhou Gravel Eagle Stone Technology Co ltd
Priority to CN202211253761.9A priority Critical patent/CN115567517A/zh
Publication of CN115567517A publication Critical patent/CN115567517A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/256NAT traversal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1061Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1065Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT] 

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种基于IPFS的p2p分件分发方法,包括以下步骤:S1添加文件到IPFS本地库;S2发送文件到服务器暂存;S3通知接收客户端;S4检索文件所在节点;S5已连接的节点中有节点;S6无可用节点;S7文件下载成功;S8文件下载失败;使用该方案可以作为p2p文件下载服务,IPFS无法进行NAT穿越,本方案提供了NAT穿越功能,包括stun服务来发现外网地址,打洞服务来协助客户端进行打洞流程,IPFS bootstrap服务来检索文件所在节点,该方案可以用来提高文件下载服务,在客户端之间进行多节点p2p传输,可以节省服务端带宽资源及磁盘io资源,同时解决了国内ipv4资源匮乏,大多网络设备没有公网IP,无法进行p2p通信,IPFS很难p2p下载文件的问题。

Description

一种基于IPFS的p2p分件分发方法
技术领域
本发明涉及电子信息技术领域,具体为一种基于IPFS的p2p分件分发方法。
背景技术
IPFS(Inter Planetary File System,又称星际文件系统)白皮书文件中表示,IPFS是一种点对点的分布式文件系统,是分布式的web,是单一的Bittorrent 群集,git仓库分布式存储的,可以让互联网运行速度更快,更加安全和更加开放的旨在连接所有有相同的文件系统的计算机设备,其基于dht(分布式哈希算法)提供了类似磁链接下载的功能,并且拥有安全防篡改,文件版本控制等功能,IPFS从根本上来讲一项类似于http的网络协议,能够支持我们查看互联网页面,可挂载文件系统,自身具有文件夹和文件,包含连接层,路由层和数据块交换的模块化协议,IPFS基于其独特的去中心网络分享模式,能够是的带宽加速,是天然的CDN,与现有网络协议并不冲突,可以与现有域名系统绑定,但国内ipv4资源匮乏,大多网络设备没有公网IP,都是处于内网环境,无法进行p2p通信因此用IPFS很难p2p下载文件。
发明内容
为了解决上述问题,本发明的目的在于提供一种基于IPFS的p2p分件分发方法。
为实现上述目的,本发明提供如下技术方案:一种基于IPFS的p2p分件分发方法,包括以下步骤:
(1)添加文件到IPFS本地库:上传到原服务端,然后上传到ipfs,调用ipfs add,把文件加入到ipfs本地节点的库中,并同步给bootstrap节点或者其他已连接的peer节点,内容为文件hash及该文件所在的节点ID,保存该文件HASH和节点信息;
(2)发送文件到服务器暂存:上传文件,文件名,IPFS,HASH至服务器,服务端接收该文件;
(3)通知接收客户端:服务端接收文件,通知接收客户端并发送文件的哈希值;
(4)检索文件所在节点:客户端接收文件,然后基于dht(分布式哈希算法)查找文件所在节点,并在IPFS Bootstrap节点查找拥有该文件的所有节点;
(5)已连接的节点中有节点:如果已连接的节点中有节点拥有该文件则直接下载;
(6)无可用节点:连接到拥有文件的节点,连接过程需要进行NAT打洞,需要采用reuseport创建socket来进行打洞,打洞成功后再连接到对方的守护进程进行下载文件;
(7)文件下载成功:文件下载成功,通知服务端文件已接收;
(8)文件下载失败:IPFS下载失败时走原本的下载方式,从服务端直接下载;
进一步地,所述步骤(1)中添加文件到IPFS本地库的方法包括以下步骤;
(1)下载IPFS执行程序,并解压缩到一个文件夹里;
(2)打开cmd命令行,执行两个命令,初始化:ipfs init,运行节点:ipfs daemon;
(3)上传文件 ipfs add filename.txt,会得到一个hash值;
(4)如果往目录添加或修改了目录里的文件,此时目录的Hash值会变化,需要使用新的ID才能访问更新后的目录或文件,这对于网站部署来说是十分不便的,为了解决这个问题IPFS提供了IPNS服务,可以将一个唯一ID绑定到IPFS的Hash上,通过这个唯一ID访问IPFS文件/文件夹,使用ipfs name publish 目录hash值 命令进行绑定操作. 返回哈希值,其中的Qm...就是上传目录时返回的Hash值,返回的k2...就是IPNS ID,对于同一个节点来说默认情况下是相同的,我们可使用这个ID生成新的访问链接;
(5)同步给bootstrap节点或者其他已连接的peer节点,内容为文件hash及该文件所在的节点ID,bootstrap节点保存该文件HASH和节点信息;
进一步地,所述步骤(4)中检索文件所在节点的方法包括以下步骤:
(1)当一个节点加入到IPFS网络中后,该节点中存储的IPFS内容就会通过IPFS的分布式哈希表(DHT)频繁地广播到IPFS全网,告诉其它节点它自己存储了什么内容;
(2)检索节点找到了存储节点后,会得到存储节点的“多地址”;
(3)检索节点就会通过“多地址”直接连接存储节点,然后从存储节点获取所需的检索内容;
进一步地,所述步骤(6)无可用节点方法包括以下步骤:
假设有如下客户端(B),NAT(A),服务端(C),客户端的IP为IPB,NAT的IP为 IPA ,服务端的 IP为IPC1 、IPC2;
(1)B向C的IPC1的port1端口发送一个UDP包,C收到这个包后,会把它收到包的源IP和port写到UDP包中,然后把此包通过IP1C和port1发还给B,这个IP和port也就是NAT的外网IP和port,当B收到此UDP后,把此UDP中的IP和自己的IP做比较,如果是一样的,就说明自己是在公网,下步NAT将去探测防火墙类型,如果不一样,说明有NAT的存在,系统进行步骤(2)的操作。
(2)B向C的IPC1发送一个UDP包,请求C通过另外一个IPC2和PORT向B返回一个UDP数据包,如果B收到了这个数据包,也就是STUN标准中的full cone NAT,如果没收到,那么系统进行步骤(3)的操作;
(3)B向C的IPC2的port2发送一个数据包,C收到数据包后,把它收到包的源IP和port写到UDP包中,然后通过自己的IPC2和port2把此包发还给B,如果这个port和step1中的port一样,那么可以肯定这个NAT是个CONE NAT,否则是对称NAT ,如果此步的时候PORT是不同的,如果不同,那么只剩下了restrict cone 和port restrict cone。系统用步骤(4)探测是是那一种;
(4)B向C的IP2的一个端口PD发送一个数据请求包,要求C用IP2和不同于PD的port返回一个数据包给B,如果B收到了,那也就意味着只要IP相同,即使port不同,NAT也允许UDP包通过,显然这是restrict cone NAT,如果没收到,没别的好说,port restrict NAT;
(5)最后在STUN服务器得到自己的NAT类型和公网IP、Port;
(6)NAT打洞依赖于Stun服务和NAT打洞服务,Stun服务用来发现客户端外网地址和NAT类型,NAT打洞服务协调客户端进行打洞;
(7)IPFS boostrap节点用于和客户端同步文件索引信息,客户端上传时会同步文件hash值到bootstrap节点,下载文件时,从bootstrap节点查找拥有文件的节点;
与现有技术相比,本发明的有益效果如下:
本发明主要基于IPFS作为传输工具,在网络层我们提供了NAT打洞服务,来进行NAT穿透到内网进行p2p文件下载,使用该方案可以作为p2p文件下载服务,IPFS无法进行NAT穿越,本方案提供了NAT穿越功能,包括stun服务来发现外网地址,打洞服务来协助客户端进行打洞流程,IPFS bootstrap服务来检索文件所在节点,该方案可以用来提高文件下载服务,在客户端之间进行多节点p2p传输,可以节省服务端带宽资源及磁盘io资源,同时解决了国内ipv4资源匮乏,大多网络设备没有公网IP,都是处于内网环境,无法进行p2p通信,IPFS很难p2p下载文件的问题。
参照后文的说明和附图,详细公开了本发明的特定实施方式,指明了本发明的原理可以被采用的方式。应该理解,本发明的实施方式在范围上并不因而受到限制。
针对一种实施方式描述和/或示出的特征可以以相同或类似的方式在一个或更多个其它实施方式中使用,与其它实施方式中的特征相组合,或替代其它实施方式中的特征。
应该强调,术语“包括/包含”在本文使用时指特征、整件、步骤或组件的存在,但并不排除一个或更多个其它特征、整件、步骤或组件的存在或附加。
附图说明
图1为本发明一种基于IPFS的p2p分件分发方法的流程图。
具体实施方式
为了使本技术领域的人员更好地理解本发明中的技术方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
需要说明的是,当元件被称为“设置于”另一个元件,它可以直接在另一个元件上或者也可以存在居中的另一个元件。当一个元件被认为是“连接”另一个元件,它可以是直接连接到另一个元件或者可能同时存在居中另一个元件。本文所使用的术语“垂直的”、“水平的”、“左”、“右”以及类似的表述只是为了说明的目的,并不表示是唯一的实施方式。
除非另有定义,本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施方式的目的,不是旨在于限制本发明。本文所使用的术语“和/或”包括一个或多个相关的所列项目的任意的和所有的组合。
实施例1
请参阅图1,一种基于IPFS的p2p分件分发方法,包括以下步骤:
(1)添加文件到IPFS本地库:上传到原服务端,然后上传到ipfs,调用ipfs add,把文件加入到ipfs本地节点的库中,并同步给bootstrap节点或者其他已连接的peer节点,内容为文件hash及该文件所在的节点ID,保存该文件HASH和节点信息;
(2)发送文件到服务器暂存:上传文件,文件名,IPFS,HASH至服务器,服务端接收该文件;
(3)通知接收客户端:服务端接收文件,通知接收客户端并发送文件的哈希值;
(4)检索文件所在节点:客户端接收文件,然后基于dht(分布式哈希算法)查找文件所在节点,并在IPFS Bootstrap节点查找拥有该文件的所有节点;
(5)已连接的节点中有节点:如果已连接的节点中有节点拥有该文件则直接下载;
(6)无可用节点:连接到拥有文件的节点,连接过程需要进行NAT打洞,需要采用reuseport创建socket来进行打洞,打洞成功后再连接到对方的守护进程进行下载文件;
(7)文件下载成功:文件下载成功,通知服务端文件已接收;
(8)文件下载失败:IPFS下载失败时走原本的下载方式,从服务端直接下载;
进一步,所述步骤(1)中添加文件到IPFS本地库的方法包括以下步骤;
(1)下载IPFS执行程序,并解压缩到一个文件夹里;
(2)打开cmd命令行,执行两个命令,初始化:ipfs init,运行节点:ipfs daemon;
(3)上传文件 ipfs add filename.txt,会得到一个hash值;
(4)如果往目录添加或修改了目录里的文件,此时目录的Hash值会变化,需要使用新的ID才能访问更新后的目录或文件,这对于网站部署来说是十分不便的,为了解决这个问题IPFS提供了IPNS服务,可以将一个唯一ID绑定到IPFS的Hash上,通过这个唯一ID访问IPFS文件/文件夹,使用ipfs name publish 目录hash值 命令进行绑定操作. 返回哈希值,其中的Qm...就是上传目录时返回的Hash值,返回的k2...就是IPNS ID,对于同一个节点来说默认情况下是相同的,我们可使用这个ID生成新的访问链接;
(5)同步给bootstrap节点或者其他已连接的peer节点,内容为文件hash及该文件所在的节点ID,bootstrap节点保存该文件HASH和节点信息;
进一步,所述步骤(4)中检索文件所在节点的方法包括以下步骤:
(1)当一个节点加入到IPFS网络中后,该节点中存储的IPFS内容就会通过IPFS的分布式哈希表(DHT)频繁地广播到IPFS全网,告诉其它节点它自己存储了什么内容;
(2)检索节点找到了存储节点后,会得到存储节点的“多地址”;
(3)检索节点就会通过“多地址”直接连接存储节点,然后从存储节点获取所需的检索内容;
进一步,所述步骤(6)无可用节点方法包括以下步骤:
假设有如下客户端(B),NAT(A),服务端(C),客户端的IP为IPB,NAT的IP为 IPA ,服务端的 IP为IPC1 、IPC2;
(1)B向C的IPC1的port1端口发送一个UDP包,C收到这个包后,会把它收到包的源IP和port写到UDP包中,然后把此包通过IP1C和port1发还给B,这个IP和port也就是NAT的外网IP和port,当B收到此UDP后,把此UDP中的IP和自己的IP做比较,如果是一样的,就说明自己是在公网,下步NAT将去探测防火墙类型,如果不一样,说明有NAT的存在,系统进行步骤(2)的操作。
(2)B向C的IPC1发送一个UDP包,请求C通过另外一个IPC2和PORT向B返回一个UDP数据包,如果B收到了这个数据包,也就是STUN标准中的full cone NAT,如果没收到,那么系统进行步骤(3)的操作;
(3)B向C的IPC2的port2发送一个数据包,C收到数据包后,把它收到包的源IP和port写到UDP包中,然后通过自己的IPC2和port2把此包发还给B,如果这个port和step1中的port一样,那么可以肯定这个NAT是个CONE NAT,否则是对称NAT ,如果此步的时候PORT是不同的,如果不同,那么只剩下了restrict cone 和port restrict cone。系统用步骤(4)探测是是那一种;
(4)B向C的IP2的一个端口PD发送一个数据请求包,要求C用IP2和不同于PD的port返回一个数据包给B,如果B收到了,那也就意味着只要IP相同,即使port不同,NAT也允许UDP包通过,显然这是restrict cone NAT,如果没收到,没别的好说,port restrict NAT;
(5)最后在STUN服务器得到自己的NAT类型和公网IP、Port;
(6)NAT打洞依赖于Stun服务和NAT打洞服务,Stun服务用来发现客户端外网地址和NAT类型,NAT打洞服务协调客户端进行打洞;
(7)IPFS boostrap节点用于和客户端同步文件索引信息,客户端上传时会同步文件hash值到bootstrap节点,下载文件时,从bootstrap节点查找拥有文件的节点;
除非另有说明,所有范围都包括端点以及端点之间的所有数字。与范围一起使用的“大约”或“近似”适合于该范围的两个端点。因而,“大约20到30”旨在覆盖“大约20到大约30”,至少包括指明的端点。
披露的所有文章和参考资料,包括专利申请和出版物,出于各种目的通过援引结合于此。描述组合的术语“基本由…构成”应该包括所确定的元件、成分、部件或步骤以及实质上没有影响该组合的基本新颖特征的其他元件、成分、部件或步骤。使用术语“包含”或“包括”来描述这里的元件、成分、部件或步骤的组合也想到了基本由这些元件、成分、部件或步骤构成的实施方式。这里通过使用术语“可以”,旨在说明“可以”包括的所描述的任何属性都是可选的。
多个元件、成分、部件或步骤能够由单个集成元件、成分、部件或步骤来提供。另选地,单个集成元件、成分、部件或步骤可以被分成分离的多个元件、成分、部件或步骤。用来描述元件、成分、部件或步骤的公开“一”或“一个”并不说为了排除其他的元件、成分、部件或步骤。
应该理解,以上描述是为了进行图示说明而不是为了进行限制。通过阅读上述描述,在所提供的示例之外的许多实施方式和许多应用对本领域技术人员来说都将是显而易见的。因此,本教导的范围不应该参照上述描述来确定,而是应该参照所附权利要求以及这些权利要求所拥有的等价物的全部范围来确定。出于全面之目的,所有文章和参考包括专利申请和公告的公开都通过参考结合在本文中。在前述权利要求中省略这里公开的主题的任何方面并不是为了放弃该主体内容,也不应该认为发明人没有将该主题考虑为所公开的发明主题的一部分。

Claims (4)

1.一种基于IPFS的p2p分件分发方法,其特征在于,包括以下步骤:
(1)添加文件到IPFS本地库:上传到原服务端,然后上传到ipfs,调用ipfs add,把文件加入到ipfs本地节点的库中,并同步给bootstrap节点或者其他已连接的peer节点,内容为文件hash及该文件所在的节点ID,保存该文件HASH和节点信息;
(2)发送文件到服务器暂存:上传文件,文件名,IPFS,HASH至服务器,服务端接收该文件;
(3)通知接收客户端:服务端接收文件,通知接收客户端并发送文件的哈希值;
(4)检索文件所在节点:客户端接收文件,然后基于dht(分布式哈希算法)查找文件所在节点,并在IPFS Bootstrap节点查找拥有该文件的所有节点;
(5)已连接的节点中有节点:如果已连接的节点中有节点拥有该文件则直接下载;
(6)无可用节点:连接到拥有文件的节点,连接过程需要进行NAT打洞,需要采用reuseport创建socket来进行打洞,打洞成功后再连接到对方的守护进程进行下载文件;
(7)文件下载成功:文件下载成功,通知服务端文件已接收;
(8)文件下载失败:IPFS下载失败时走原本的下载方式,从服务端直接下载。
2.根据权利要求1所述的一种基于IPFS的p2p分件分发方法,其特征在于,所述步骤(1)中添加文件到IPFS本地库的方法包括以下步骤:
(1)下载IPFS执行程序,并解压缩到一个文件夹里;
(2)打开cmd命令行,执行两个命令,初始化:ipfs init,运行节点:ipfs daemon;
(3)上传文件 ipfs add filename.txt,会得到一个hash值;
(4)如果往目录添加或修改了目录里的文件,此时目录的Hash值会变化,需要使用新的ID才能访问更新后的目录或文件,这对于网站部署来说是十分不便的;
(5)同步给bootstrap节点或者其他已连接的peer节点,内容为文件hash及该文件所在的节点ID,bootstrap节点保存该文件HASH和节点信息。
3.根据权利要求1所述的一种基于IPFS的p2p分件分发方法,其特征在于,所述步骤(4)中检索文件所在节点的方法包括以下步骤:
(1)当一个节点加入到IPFS网络中后,该节点中存储的IPFS内容就会通过IPFS的分布式哈希表(DHT)频繁地广播到IPFS全网,告诉其它节点它自己存储了什么内容;
(2)检索节点找到了存储节点后,会得到存储节点的“多地址”;
(3)检索节点就会通过“多地址”直接连接存储节点,然后从存储节点获取所需的检索内容。
4.根据权利要求1所述的一种基于IPFS的p2p分件分发方法,其特征在于,所述步骤(6)无可用节点方法包括以下步骤:
假设有如下客户端(B),NAT(A),服务端(C),客户端的IP为IPB,NAT的IP为 IPA ,服务端的 IP为IPC1 、IPC2;
(1)B向C的IPC1的port1端口发送一个UDP包,C收到这个包后,会把它收到包的源IP和port写到UDP包中,然后把此包通过IP1C和port1发还给B,这个IP和port也就是NAT的外网IP和port,当B收到此UDP后,把此UDP中的IP和自己的IP做比较,如果是一样的,就说明自己是在公网,下步NAT将去探测防火墙类型,如果不一样,说明有NAT的存在,系统进行步骤(2)的操作。
(2)B向C的IPC1发送一个UDP包,请求C通过另外一个IPC2和PORT向B返回一个UDP数据包,如果B收到了这个数据包,也就是STUN标准中的full cone NAT,如果没收到,那么系统进行步骤(3)的操作;
(3)B向C的IPC2的port2发送一个数据包,C收到数据包后,把它收到包的源IP和port写到UDP包中,然后通过自己的IPC2和port2把此包发还给B,如果这个port和step1中的port一样,那么可以肯定这个NAT是个CONE NAT,否则是对称NAT ,如果此步的时候PORT是不同的,如果不同,那么只剩下了restrict cone 和port restrict cone。系统用步骤(4)探测是是那一种;
(4)B向C的IP2的一个端口PD发送一个数据请求包,要求C用IP2和不同于PD的port返回一个数据包给B,如果B收到了,那也就意味着只要IP相同,即使port不同,NAT也允许UDP包通过,显然这是restrict cone NAT,如果没收到,没别的好说,port restrict NAT;
(5)最后在STUN服务器得到自己的NAT类型和公网IP、Port;
(6)NAT打洞依赖于Stun服务和NAT打洞服务,Stun服务用来发现客户端外网地址和NAT类型,NAT打洞服务协调客户端进行打洞;
(7)IPFS boostrap节点用于和客户端同步文件索引信息,客户端上传时会同步文件hash值到bootstrap节点,下载文件时,从bootstrap节点查找拥有文件的节点。
CN202211253761.9A 2022-10-13 2022-10-13 一种基于IPFS的p2p分件分发方法 Pending CN115567517A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211253761.9A CN115567517A (zh) 2022-10-13 2022-10-13 一种基于IPFS的p2p分件分发方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211253761.9A CN115567517A (zh) 2022-10-13 2022-10-13 一种基于IPFS的p2p分件分发方法

Publications (1)

Publication Number Publication Date
CN115567517A true CN115567517A (zh) 2023-01-03

Family

ID=84745769

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211253761.9A Pending CN115567517A (zh) 2022-10-13 2022-10-13 一种基于IPFS的p2p分件分发方法

Country Status (1)

Country Link
CN (1) CN115567517A (zh)

Similar Documents

Publication Publication Date Title
US11343353B2 (en) Method and system of dispatching requests in a content delivery network
US7788378B2 (en) Apparatus and method for community relay node discovery
KR100723320B1 (ko) 인터넷 클라이언트-서버 멀티플렉서
US20060085385A1 (en) Storage of content data in a peer-to-peer network
US7430747B2 (en) Peer-to peer graphing interfaces and methods
US20050229243A1 (en) Method and system for providing Web browsing through a firewall in a peer to peer network
US20150248455A1 (en) Content name resolution for information centric networking
US20100115613A1 (en) Cacheable Mesh Browsers
US8140645B2 (en) Index server support to file sharing applications
US8478898B2 (en) System and method for routing directory service operations in a directory service network
CN104601724A (zh) 上传和下载文件的方法及系统
US7996532B2 (en) Cluster-free techniques for enabling a directory protocol-based domain name system (DNS) service for high availability
CN110830601B (zh) 分布式系统nat穿透方法、装置、设备及存储介质
US20030126198A1 (en) Method and apparatus for discovering client proximity using race type translations
US8244867B2 (en) System and method for the location of caches
US20120047170A1 (en) Techniques for accessing remote files
CN115567517A (zh) 一种基于IPFS的p2p分件分发方法
US8135772B2 (en) Single servlets for B2B message routing
CN109547508B (zh) 一种实现资源访问的方法、装置及系统
CN101668029A (zh) 一种网络设备和网络通讯的方法
US20070106691A1 (en) System and method for efficient directory performance using non-persistent storage
Cisco IPM Error Messages
US9391979B1 (en) Managing secure connections at a proxy server
CN112637333A (zh) 一种客户端智能代理方法
Liu et al. Enhanced Kepler framework for self-archiving

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination