After I use a bootstrap-node and add it to the farm using --bootstrap-nodes, the farm stops working and displays errors like ‘DSN L2. No retries left. Cannot acquire piece from DSN L1’. How can I ensure that the bootstrap-node maintains its basic functionality? For example, how do I add peer information for dns/bootstrap-0.gemini-3g.subspace.network in the bootstrap-node?
Bootstrap node is how you reach the network. Looks like what you have essentially done is locked yourself into an isolated network.
What you should do is to specify bootstrap nodes for your bootstrap node (can be found in chain spec, there are none hardcoded) if you really want to run it. Shouldn’t be necessary though as any other node and/or farmer can act as bootstrap nodes as well. That app is designed for use cases where you want a bootstrap node and nothing else. For example official public-facing bootstrap nodes are using it.
ok , thanks 
Can I specify other nodes to which my guiding node broadcasts downwards? For example, only announcing to my nodes located in Germany, it seems like forming a new subnet and allowing only designated nodes to provide network announcements for the entire network. I couldn’t find any relevant standards or articles, please guide me.
I’m not really sure what you’re asking about. Either way Subspace is meant to be a global network, not a local subnet. So unless you isolate the instances you’re running, they will most likely not stay connected to each other and will be connected to the other peers on the network instead.
I just want them to stay connected with my other nodes rather than accessing other connected nodes. I will set up a special bootstrap-node specifically for these nodes to access externally. This is very important for breaking through protocol blockades and providing large bandwidth.luck like the bootstrap-node is RT，farm and node is PC 。
- That is really not how the protocol is designed to work
- I think what you want then is not bootstrap nodes, but rather reserved, but even then there is no guarantee that you’ll be retrieving data from your nodes and not other random participants on the network (there is no guarantee any of your nodes will have the data you actually need either)
I may need to implement the following steps.
- Implement Two libp2p Peer Pools: The first step involves the creation of two separate peer pools using libp2p.
- Use the First Pool as a Bootstrap Node: The first pool will act as a bootstrap node. It will broadcast all the registered internal network peers.
- Create an Additional Public Network Peer Pool: An additional peer pool will be created for normal public network communication.
- Broadcast Unanswered Requests from the Internal Network Pool to the Public Network Pool: If a request in the internal network pool is not answered by other nodes, it will be broadcasted to the second public network pool. The results will then be returned to the first internal network pool. It’s also essential to ensure that these requests are not redundantly returned by other nodes in the internal network pool.
1 Like
This might require a substantial amount of coding, and the difficulty is almost very high for me who is just getting started with Rust. Can you offer some relevant advice?
The effect of the implementation is almost exactly the same as this: like this
What you write sounds great on abstract level, but that is not how P2P networking is designed to work, so I don’t think it is quite implementable. I’m also not sure what problem you’re trying to solve in the process, but if it is the same as Can set up farm to connect to specified farm on internal network?, then there is an explanation there how to achieve it in a way that will actually work.
Yes, Implementing the aforementioned functions should be able to satisfy the implementation of this architecture.
I have made new progress in this architecture, and now it has almost reached the functionality I need. So, this post is concluded.