I am developing an app where a network of peers collaborate:
jobs are sent out to the network for completion, and a response is sent back to the sender with the result
content is loaded into memory and processed by a client (a peer in the network) with FS access, and required by other peers when a job refers to it. This processed content (not the raw file) is to be offered to any peer in the network executing a job by p2p sharing of the content a a key or content ID.
I have read the docs and tinkered with the rust examples.
Specific questions I have are:
Are there any examples of the request-response protocol. I would like to send out a request to the network participating in my app, to be served by the first one who can, and then get the response back to the original sender (use PeerId to send back directly).
For the content sharing, I’m not sure if I should look more at the distributed key value store example or the file sharing example.
In the distributed key value store example is it possible to make the network (DK-V) specific to a single purpose (by a name or identifier) such that more that one could run independently in parallel. My understanding is that in the example the participating nodes is just limited by network visibility.
It could work like that or go with a different architecture. I would use GossipSub to send all available jobs then listen for Job accepted messages. A peer could accept jobs based on some algorithm to spread the load evenly among peers.
Bitswap is what you would use but it’s not implemented yet. I may be working on that later this year.
I don’t know if it’s possible. You could separate purpose in some other way. in IPFS, CIDs and IPNS records are in the same DHT.
Thanks a lot for the reply. I will start trying to get GossipSub to work for me.
I notice in the GossipSub example that in the second peer you need to identify the first peer via an address on the command line. I assume it will it be possible to combine with mDNS and to discover the other peer(s) also?
For the content sharing, I guess I will do something with the DKV Store, and wait for your news on “Bitswap”!
Maybe my previous post wasn’t clear.
If I start two examples of the gossipsub-chat example with just “cargo run” (not specifying any known address on the comment line), then sending a message from the first one leads to the error:
Publish error: InsufficientPeers
as it doesn’t know about any peers.
To avoid this, you need to start the second instance of the example specifying the address of the first.
I was expecting that if both implemented mDNS discovery, they would discover each other at startup and you could gossip messages between peers without any prior knowledge of the other’s address when you were starting them
Does that make sense?
If so, would a contribution to that example to add mDNS be welcome, or you want to keep them as simple as possible and focussed on the protocol in question (gossipsub in this case)?
OK I have added mDNS discovery to the gossipsub-chat example and it works.
I saw occaisonal non-discovery, but I reproduced that using the untouched distributed-key-store example, so I assume it’s my Mac or network or something I ignored that!
Would you like a PR with that, as mentioned above?