Socket closed

[cyrus937]

I've developed a module that lets me create a peer-to-peer network based on rust-libp2p. I'm currently trying to set up a binding between this code and my python code, but I'm getting this error from mdns :

2023-12-04T03:29:30.498895Z ERROR libp2p_mdns:: behaviour: if watch returned an error: rtnetlink socket closed 
2023-12-04T03:29:30.498899Z ERROR netlink_proto::framed: failed to read from netlink socket: Custom { kind: Other, error : "A Tokio 1.x context was found, but it is being shutdown." }

Do you have any idea how to solve it?

[thomaseizinger]

Can you post an example to reproduce it? My guess is you are dropping the runtime as you exit the FFI function.

[thomaseizinger]

It is hard to say with individual code snippets, can you post a repository that reproduces the problem and is as minimal as possible?

[thomaseizinger]

I've not done interop with python before. Perhaps try some non-libp2p async stuff with Python and see if you can find something there! :)

[cyrus937]

Here is the link to the public repository :

https://github.com/cyrus937/libp2p-node

[thomaseizinger]

Thanks for sharing the code. I'd suggest to reconsider the design a bit that you've chosen.

For one, you are directly interacting with stdio from within the Rust code. It would be better to employ message passing via a channel. See https://github.com/libp2p/rust-libp2p/blob/master/examples/file-sharing/src/network.rs for some inspiration.

Secondly, it is really important that you continuously, without interruption call Swarm::next() and handle each event with minimal latency. The Swarm is essentially a giant Future and will not make progress if you stop polling it. If you follow the above pattern of an eventloop with message passing, that is solved for you.

In regards to your FFI design, I'd suggest to start the tokio runtime in there and have an endless loop in which you poll the swarm for events using Swarm::next. In other words don't return from your FFI function. That will de-allocate the runtime again and stop any pending tasks and connections immediately. That is likely why you are seeing sockets being closed. Connections run on independent tasks in parallel in the background but if you drop the Runtime, they have nowhere to execute.

[cyrus937]

Thank you for your feedback, and sorry for the delay of my feedback.

I made the changes as you suggested, using the tokio runtime block_on, but I still get the same error with the sockets closing.

Sorry if I don't quite understand what you're saying, but I'm new to using Rust, more specifically the rust-libp2p library.

repo: https://github.com/cyrus937/libp2p-node

fn run(&mut self) {
        let handle = tokio::runtime::Runtime::new().expect("Failed to create Tokio runtime");
        handle.block_on(
            async {

                let command_arc_clone = Arc::clone(&self.node.command_receiver);
                let mut command_guard = command_arc_clone.lock().await;
                let command_receiver = &mut *command_guard;

                loop {
                    tokio::select! {
                        event = self.node.swarm.next() => handle_event(event.expect("Swarm stream to be infinite."), &mut self.node.swarm).await,
                        command = command_receiver.next() => match command {
                            Some(c) => {
                                handle_command(c, &mut self.node.swarm).await},
                            // Command channel closed, thus shutting down the network event loop.
                            None=>  {},
                        },
                    };
                }
            }
        );
    }

[thomaseizinger]

Sorry if I don't quite understand what you're saying, but I'm new to using Rust, more specifically the rust-libp2p library.

No worries! There are quite a few resources out there to learn from! You are touching on many subjects at the same time. I'd recommend to explore them in isolation so you can get a better understanding of them (in no particular order):

• Try to use rust-libp2p standalone
• Use Rust FFI with Python
• Learn Rust async

One thing to note above is that you shouldn't block the event loop on handling the command, i.e. handle_command will stop the swarm from making progress while it is handling the command. The fact that you are passing the Swarm in means that you are likely deadlocking there (semantically).

[cyrus937]

Thanks !!!