点对点去中心化网络 - 向所有对等点发送消息
我需要创建文件共享点对点网络（没有中央服务器）。
我阅读了很多有关该主题的信息。要求是确保网络中的每个对等点都保留其他对等点的完整列表以及网络上所有文件的完整列表。
我知道这不是最好的方法，但这是一个要求...另一个（在我看来很奇怪）要求是对等点之间的通信应该使用 HTTP 协议和 JSON 序列化来实现。
这意味着每个对等点都将充当网络服务器，并且还可以通过某种方式连接到每个其他对等点。
因此，我想知道一种好方法，可以将消息从一个对等方传递给所有其他对等方，而无需单个对等方直接连接到其他对等方（连接过多）。
我一直在寻找一种方法来以某种方式将消息路由到几个级别，以便流量会有所分布。据我所知，并且可以连接到网络上的任何对等点，我可以在发送消息之前有效地构造一条路由，然后告诉某些对等点重新路由它。但我如何找出最佳路线呢？如果有一个有问题的对等点无法重新路由消息会发生什么？
编辑：如果我没有说清楚，我很抱歉。该消息应该被网络上的所有对等点接收，而不仅仅是一个目标。
编辑2：你可以把我想要做的事情想象成一个网络服务器网络。他们应该能够保存分布式数据（不是问题的一部分），但他们每个人都需要知道网络上有哪些资源可用（哈希表）。客户端可以在其中一台服务器上上传内容（无论是哪一台）。当这种情况发生时，所有其他人都需要知道此更改才能更新他们的哈希表。如果新服务器加入网络，这同样适用。我的问题是如何在没有单个服务器连接到所有其他服务器的情况下传播此消息，这显然会在单个服务器上产生大量流量。
I need to create a file-sharing peer-to-peer network (without a central server).
I read a lot of information on the topic. The requirement is to make sure every peer in the network keeps a full list of the other peers and a full list of all the files on the network.
I know it's not the best way to do it, but it's a requirement so ... Another (in my opinion weird) requirement is that the communication between the peers should be implemented with the HTTP protocol and JSON-serialized.
This means every peer will act as a web-server and will also have a way to connect to every other peer.
So I want to know a good way to deliver a message from one peer to all others without having a single peer to connect directly to the others (too many connections).
I've been looking for a way to somehow route the message a few levels so the traffic will be somewhat distributed. As I know and can connect to any peer on the network I can effectively construct a route before the message is sent and then tell some peers to reroute it. But how do I figure out the best route? And what happens if there's a bugged peer which can't reroute the message?
EDIT: I'm sorry if I didn't make it clear. The message should be received by ALL peers on the network, not just one target.
EDIT 2: You can think of what I want to do as a network of web servers. They should be able to hold data distributed (not part of the question) but every one of them needs to know what resources are available on the network (a hash-table). A client can upload stuff on one of the servers (doesn't matter which one). When that happens ALL others need to know of this change to update their hash-tables. The same applies if a new server joins the network. My question is how to propagate this message without having a single server to connect to all the others, which clearly will generate a lot of traffic on a single server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我看到你的问题分为两个部分：
没有中央服务器
如今流行的 p2p 实体是僵尸网络，它们有 C&C 服务器，并且也使用 HTTP。他们倾向于通过使用某种算法来生成域名来利用 DNS。您需要一些东西来种子/引导该过程，否则 p2p 平台将无法启动。进化可以通过传播来完成，也就是说，对等点可以从中心位置获取初始列表，然后当它们从查询其他对等点中了解更多信息时建立 DHT（即获得更多响应）。
对于没有中央服务器的 p2p 网络，您可以执行本地网络扫描或使用 Zeroconf 协议的实现，例如 SSPD。这里的限制是您不能扩展到本地网络之外。例如，假设您想在 LAN 之外进行多播，您将尝试到达哪些 IP/范围？
向所有对等点发送消息
无法保证此操作会成功，因为您不知道在给定时间点哪些对等点处于活动状态，并且没有一个对等点拥有 DHT 的完整副本。泛洪通常是实现此目的的方式。您可以采用查询泛洪策略，但不要指望得到答复。您可以在实际想要返回答案的搜索中使用相同的策略。如果您只想达到过去 5 个级别，您只需包含一个带有哈希/id 的计数器，对等点在传播消息之前递减，并在计数器达到 0 时停止。
这个项目的一个大障碍是 NAT。因此，不仅对等方需要了解彼此的外部 IP 和端口。如果您在 LAN 内，这不是什么大问题。
I see your question divided in two components:
No central server
Popular p2p entities these days are botnets, which have C&C servers, and do use HTTP too. They tend to exploit DNS by using some kind of an algorithm to generate domain names. You need something to seed/bootstrap the process, otherwise the p2p platform won't start. Evolution can be done by propagation, that is, peers can get an initial list from a central location, then build up the DHT as they learn more from querying other peers (i.e. get more responses back).
For a p2p network without a central server, you can do a local network scan or use an implementation of zeroconf protocols such as SSPD. The restriction here is that you cannot grow beyond your local network. For instance, say you'd like to multicast beyond your LAN, what IPs/ranges are you going to try reach?
Messaging all peers
There is no guarantee for this to succeed, because you do not know at a given point in time which peers are active, and no single peer has a full copy of the DHT. Flooding is generally the way this is accomplished. You can adopt the query flooding strategy, but don't expect an answer back. You can use the same strategy for searches, where you actually want the answer back. In case you want to reach say only past 5 levels, you simply include a counter with the hash/id, that the peers decrement before propagating the message on, and stop when the counter reaches 0.
A big hurdle with this project is NAT. So, not only peers will need to know each others external IP and port. If you are within a LAN this is not much of a problem.