I’m learning about libp2p and trying to re-implement a VPN similar to hyprspace in rust. However I’m realizing that the go lib and the rust lib have dissimilar APIs.
The gist of the application is:
- Provide a mapping from
Iv4Addr to PeerId
-
select! between receiving a fixed-size packet ([u8;1500]) from the TUN device and a SwarmEvent
- When a connection is established with a known peer id, open a stream (maybe
async_std::channel::Sender/Receiver<[u8;1500]>?) to the peer and associate the given Ipv4Addr with the stream using a HashMap.
- When a packet is received from the TUN device, parse its destination address and send the packet to the associated stream in the
HashMap.
Step 3 is what’s confusing me. I assumed Swarm::dial() would result in a SwarmEvent::ConnectionEstablished containing a Sender and Receiver for that peer, but it does not.
My questions are:
- How do I create a channel from a connected peer?
- Do I need to define any custom
NetworkBehaviour for the Swarm or is the Kademlia behaviour for peer discovery + routing enough?
In case anyone bumps into this while researching a similar question, I’ve found my answer in the file-sharing example. Implementing the RequestResponseCodec provides the async_std::io I didn’t know I was looking for. Thanks to dvc94ch for pointing me in the right direction.
I need to dig a little deeper into how the RequestResponse protocol works for my specific needs (no need for a response because the transport should handle resending dropped packets if I’m understanding correctly).
1 Like
I need to dig a little deeper into how the RequestResponse protocol works for my specific needs (no need for a response because the transport should handle resending dropped packets if I’m understanding correctly).
@benlittle no need to send a reply. libp2p-request-response supports just sending a request.
1 Like
To clarify, do you mean using RequestResponseEvent<Packet, ()>? The implementation of RequestResponse seems to use a queue of requests and ensures that the most recent sent request gets a response before trying to send the next.
That is not the case. libp2p-request-response does not guarantee ordering across requests. In other words a later request might get an earlier response.