How can I limit data transfer to direct connections?

[MatthiasVomBruch]

I'm building a file sharing app that uses both mdns and kademlia for peer discovery. As it's supposed to run on consumer devices, I also use relays and dcutr to establish direct connections.

The actual transfer is done using request-response. If my understanding is correct, I can just use send_request on the request-response behaviour, and it will automatically trigger peer discovery via kademlia, if that peer isn't connected. Once the peer is found, it is dialed and the data is sent.

My issue is that this initial connection is most likely going to be a relayed one, and the relay's limit will not permit me to send a file of any significant size. So I wonder how I would ensure that the data is only sent via the direct connection that dcutr will attempt to establish, and only if dcutr succeeds at that. I do not want to send any data via the relay. Is that currently possible?

[dariusc93]

The actual transfer is done using request-response. If my understanding is correct, I can just use send_request on the request-response behaviour, and it will automatically trigger peer discovery via kademlia, if that peer isn't connected. Once the peer is found, it is dialed and the data is sent.

There is no direct peer discovery when calling Behaviour::send_request. Instead, it checks the local cache for peers that been added in that and other behaviours and dial from there and send the request once everything is established.

My issue is that this initial connection is most likely going to be a relayed one, and the relay's limit will not permit me to send a file of any significant size. So I wonder how I would ensure that the data is only sent via the direct connection that dcutr will attempt to establish, and only if dcutr succeeds at that. I do not want to send any data via the relay. Is that currently possible?

You can increase the size of the data transmission on the relay server side if needed. You could also wait until dcutr emits an event stating that the connection was established then proceed to send the request from there.

[MatthiasvB]

Oh that explains a lot. So I misinterpreted the docs of send_request?

    /// Initiates sending a request.
    ///
    /// If the targeted peer is currently not connected, a dialing
    /// attempt is initiated and the request is sent as soon as a
    /// connection is established.
    ///
    /// > **Note**: In order for such a dialing attempt to succeed,
    /// > the `RequestResonse` protocol must either be embedded
    /// > in another `NetworkBehaviour` that provides peer and
    /// > address discovery, or known addresses of peers must be
    /// > managed via [`Behaviour::add_address`] and
    /// > [`Behaviour::remove_address`].

The Note is what lead me to believe that peer discovery would occur. Perhaps that should be clarified in this comment?

(I asked the question, just from the wrong account)

[MatthiasvB]

But the underlying issue remains. If a address of the peer is known, the data is sent (after dialing, of course). But how do I exclude relayed addresses? Only by "manually" initiating the requests in strategically timed moments? That seems hard to get right

[drHuangMHT]

But how do I exclude relayed addresses?

The relayed connection has a data cap, and will close upon reached, so just wait for it to close. Or wait for dcutr events, close the relayed connection, then send the request.

[drHuangMHT]

The Note is what lead me to believe that peer discovery would occur. Perhaps that should be clarified in this comment?

I believe it means, unless the address is known by request-response, either via manually adding and removing through its Behaviour interface, or a successful connection initiated by a NetworkBehaviour with peer discovery capabilities(implies emitting of NewExternalAddrOfPeer), no connection will be initated by request-response.
Consider how it handles FromSwarm:

    Behaviour::on_swarm_event(&mut self, event: FromSwarm) {
        self.addresses.on_swarm_event(&event); // go to PeerAddresses::on_swarm_event below
        // unrelated code omitted
    }
    
   PeerAddresses::on_swarm_event(&mut self, event: &FromSwarm) -> bool {
        match event {
            FromSwarm::NewExternalAddrOfPeer(NewExternalAddrOfPeer { peer_id, addr }) => self.add(*peer_id, (*addr).clone()),
            FromSwarm::DialFailure( DialFailure {
                peer_id: Some(peer_id), error: DialError::Transport(errors), ..
            }) => {  // remove failed addresses }
            _ => false,
        }
    }

And how NewExternalAddrOfPeer is forwarded on swarm level:

impl Swarm<TBehaviour>{
    pub fn add_peer_address(&mut self, peer_id: PeerId, addr: Multiaddr) {
        self.behaviour
            .on_swarm_event(FromSwarm::NewExternalAddrOfPeer(NewExternalAddrOfPeer {
                peer_id,
                addr: &addr,
            }))
    }
    fn handle_behaviour_event(
        &mut self,
        event: ToSwarm<TBehaviour::ToSwarm, THandlerInEvent<TBehaviour>>,
    ) {
        match event {
            ToSwarm::NewExternalAddrOfPeer { peer_id, address } => {
                self.behaviour
                    .on_swarm_event(FromSwarm::NewExternalAddrOfPeer(NewExternalAddrOfPeer {
                        peer_id,
                        addr: &address,
                    })); // notifies all behaviours about the address
                self.pending_swarm_events
                    .push_back(SwarmEvent::NewExternalAddrOfPeer { peer_id, address }); // emit the event to outside of swarm
            }
        }
    }
}