libp2p
Unix Domain Socket support?
The rust implementation has https://docs.rs/libp2p/latest/libp2p/uds
Is there any chance for a Go version of the UDS transport? It's mostly needed for load testing.
Sure, its at the bottom of this pubsub comment https://github.com/libp2p/go-libp2p-pubsub/issues/624#issuecomment-3031520789
It came up in my load test with 50 peers over a UDS transport with 7k active goroutines (6.7k belonging to libp2p, 3.3k to pubsub). It was 13k on quic, so in both cases very inefficient.
Ive translated the rust version to golang and will be releasing in my repo this week.
- Is there any reason for this transport to live inside go-libp2p. It can be a separate repo. What do we gain by keeping it in this repo?
- Why do you need UDS for load testing? Why not TCP, QUIC, etc?
Is there any reason for this transport to live inside go-libp2p. It can be a separate repo.
Is there any reason a new repo is needed for 150 lines and some tests? Where are transports being kept right now in go-libp2p? Where are transport being kept right now in rust-libp2p?
Why do you need UDS for load testing? Why not TCP, QUIC, etc?
The answer is literally in the previous post, look at the number of active goroutines in both cases. Not using a network stack is faster then using a network stack (A->B->C will always be slower then A->C).
A working UDS transport can be found here, along with partially passing tests. The load test mentioned can be found one up in .. and it's a discovery protocol.
It's a translation of the rust implementation from https://github.com/libp2p/rust-libp2p/blob/master/transports/uds/src/lib.rs. I'm not the author.
PS. You may want to take a look at prom's goroutine allocation as well.
Is there any reason a new repo is needed for 150 lines and some tests?
There's a maintenance cost to any code that's added. We generally only add things that are broadly useful. For testing and simulations, the plan is to have https://github.com/libp2p/go-libp2p/pull/3262
The answer is literally in the previous post, look at the number of active goroutines in both cases. Not using a network stack is faster then using a network stack
- go-libp2p in production does want to send things over a network, so it makes sense to load test with the code that will be used when it's deployed over a network. For reducing test running time, does #3262 work for you?
- We aren't optimizing for reducing the number of goroutines unless there's a specific argument that says these X goroutines aren't really required and could be replace with Y < X goroutines.