DUtR P2P YamuxError when sending much data over P2P

[Ginkooo]

Hey, I have a problem and I hoped you guys could help me with debugging it.

I don't know if DUtR is stable enough to use, so IDK if this error shouldn't be a problem in the future libp2p release, or I've messed something up

I'm making a p2p videochat application. I realized, that yamux raises an EOF error after some time I'm trying to send a camera frames over the Internet.

So I tried just sending a random text (len of 7) repeatedly, but the problem occurs still.

In my program logs I've found this:
[2022-08-08T11:15:26Z DEBUG yamux::connection] 02efb792: new outbound (Stream 02efb792/180) of (Connection 02efb792 Server (streams 13)) [2022-08-08T11:15:26Z DEBUG multistream_select::dialer_select] Dialer: Proposed protocol: /floodsub/1.0.0 [2022-08-08T11:15:26Z DEBUG yamux::connection::stream] e907cd4b/6: eof [2022-08-08T11:15:26Z DEBUG yamux::connection] 02efb792: socket eof [2022-08-08T11:15:26Z DEBUG libp2p_swarm] Connection closed with error IO(Custom { kind: Other, error: YamuxError(Closed) }): Connected { endpoint: Listener { local_addr: "/ip4/146.59.94.180/ tcp/4001/p2p/12D3KooWDpJ7As7BWAwRMfu1VU2WCqNjvq387JEYKDBj4kx6nXTN/p2p-circuit", send_back_addr: "/p2p/12D3KooWDpJ7As7BWAwRMfu1VU2WCqNjvq387JEYKDBj4kx6nXTN" }, peer_id: PeerId("12D3KooWCK5KMoBy7dNmbCaXGPbUT7KQcRh1ygpCXWrmVCyxJ1i9") }; Total (peer): 0.

After this message is being printed, a program stop receiving new messages. It just continues to publish new messages from a local computer to a floodsub topic.

The first computer is in a local WiFi network, and the other one is connected to the Internet via my phone (maybe the mobile connection could be a bottleneck, idk. But I don't know if it should break the connection anyway).

What do you think? What the potential causes could be?

And the other thing I don't understand is:

02efb792: new outbound (Stream 02efb792/180) of (Connection 02efb792 Server (streams 13)) - what's that? Is it opening multiple p2p connections for some reason?

The code for the app is on my github. (The network code is in src/p2p. It's WIP as hell for now)

Thanks for the help :)

Edit: For clarification, I'm spamming a TCP connection with many small strings

[mxinden]

For more context, have you had a chance to read https://blog.ipfs.io/2022-01-20-libp2p-hole-punching/ ?

By default, relayed connections are limited in the number of bytes and the amount of time. This is implemented to not overwhelm the relay nodes. As far as I can tell, your first error message is due to the relay connection closing.

Usually you would not hit the limit, as DCUtR would upgrade the connection to a direct connection in the meantime. I would need more logs in order to tell whether that is happening. But given the fact that you see the nodes to fail to communicate entirely, I am guessing that the direct connection upgrade did not succeed.

02efb792: new outbound (Stream 02efb792/180) of (Connection 02efb792 Server (streams 13)) - what's that? Is it opening multiple p2p connections for some reason?

We use Yamux to run multiple virtual connections over a single real (e.g. TCP) connection. In this case, Yamux is opening a new outbound virtual connection (i.e. "Stream").

[dariusc93]

Logs would be helpful though from the events that swarm processed. I know when I was using relay (unknowingly without dcutr) that I was hitting limits or it would take to long and i think ive gotten a similar error but cannot recall since it was only a one time thing. With DCUtR, however once connected I had no issues with transmission of data. Granted ive been using gossipsub instead of floodsub but i doubt that even matters in this case.

[Ginkooo]

Hey, thanks for your help, using your replies I managed to solve the problem. There were two things:

1. Make sure the system time on all machines is set correctly.

2. Don't try to dial yourself, along with other nodes (I'm not sure about this, but I think for some reason it prevents establishing other p2p connections. But it's possible that an other part of my code broke this)

Now it works perfectly, without braking the connection :)