fix(server): Update quic server with compio.

[jadireddi]

Fixes: #1935

Migrates the QUIC listener and sender from tokio-based quinn to compio-quic to align with the project's io_uring migration strategy. This change ensures QUIC transport works with the compio runtime.

[numinnex]

Other than the one more comment that I left it LGTM.

Can you also run a benchmark using quic protocol to check whether it works ?
All you have to do is to run server in one terminal cargo r -r --bin iggy-server and in another run the benchmark - cargo r -r --bin iggy-bench pp quic

[jadireddi]

Other than the one more comment that I left it LGTM.

Can you also run a benchmark using quic protocol to check whether it works ? All you have to do is to run server in one terminal cargo r -r --bin iggy-server and in another run the benchmark - cargo r -r --bin iggy-bench pp quic

I was able to run this: cargo r -r --bin iggy-server.

But when trying to cargo r -r --bin iggy-bench pp quic, it was complaining for file: file local_data/runtime/current_config.toml , which i don't have in my local.

Please find attachment for the logs:
logs.txt

[numinnex]

Did you run that benchmark next to the server running ? on what port and address the quic listener is established ? can you try providing that port and address to the benchmark, the way you do it is as follows - cargo r -r --bin iggy-bench pp quic --server-address QUIC_ADDRESS, by default it's 127.0.0.1:8080

[jadireddi]

@numinnex I have tested quic protocol and benchmarked as well. Looking good now. Can you please help with review.

[numinnex]

@jadireddi
When trying to run the server from your branch I am getting following error:

Failed to install crypto provider: CryptoProvider { cipher_suites: [TLS13_AES_256_GCM_SHA384, TLS13_AES_128_GCM_SHA256, TLS13_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256], kx_groups: [X25519, secp256r1, secp384r1], signature_verification_algorithms: WebPkiSupportedAlgorithms { all: [ .. ], mapping: [ECDSA_NISTP384_SHA384, ECDSA_NISTP256_SHA256, ED25519, RSA_PSS_SHA512, RSA_PSS_SHA384, RSA_PSS_SHA256, RSA_PKCS1_SHA512, RSA_PKCS1_SHA384, RSA_PKCS1_SHA256] }, secure_random: Ring, key_provider: Ring }

Did you get similar issue ? maybe there is conflict between rustls providers for QUIC and HTTP.

[jadireddi]

@numinnex Didn't encounter above issue.

[numinnex]

That's weird, maybe it's something wrong with the configuration, I'll try pinging somebody from the core team and see whether they have the same error.

[hubcio]

Same issue for me:

[jadireddi]

Sorry to bother. Would it be feasdible to run again by pulling the latest commit. Somehow on my local, this was not reproducing.

[jadireddi]

partial logs:

[numinnex]

I've run the server and I noticed one thing, you don't set the SO_REUSEPORT flag on the UDP socket that you pass to the QUIC endpoint, because of that this program fails to create QUIC endpoint on multiple shards. I don't see an option to set SO_REUSEPORT flag on the Socket that ur providing, but by looking at web I see that the SO_REUSEPORT flag exists for UDP.

Could you investigate that ?

On top of that I think the current example with LISTENERS_COUNT does not really work well with the current architecture (we are spawning 10 worksers per shard, which means we do 10xN workers), since the Endpoint from quic wraps into Arc all of it's internal state, including the UDP socket, I think the endpoint could be shared between different shards and each shard would spawn one worker, but investigate first the SO_REUSEPORT flag for UDP

[jadireddi]

@numinnex Fixed multiple shards sharing the same UDP port and One worker per shard.

I am able to bring quic_server for multiple shards successfully. Client successfully connected via QUIC. Connection accepted on shard 5. Login processed successfully on shard 5

After client establishing connection to server's shard-5 successfully, for other shards i see below panic error's.

thread 'shard-2' panicked at core/server/src/shard/system/users.rs:465:14:
At this point session for 2461787274, should exist.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread 'shard-3' panicked at core/server/src/shard/system/users.rs:465:14:
At this point session for 2461787274, should exist.

thread 'shard-8' panicked at core/server/src/shard/system/users.rs:465:14:
At this point session for 2461787274, should exist.

thread 'shard-6' panicked at core/server/src/shard/system/users.rs:465:14:
At this point session for 2461787274, should exist.

thread 'shard-1' panicked at core/server/src/shard/system/users.rs:465:14:
At this point session for 2461787274, should exist.

thread 'shard-0' panicked at core/server/src/shard/system/users.rs:465:14:
At this point session for 2461787274, should exist.

thread 'shard-7' panicked at core/server/src/shard/system/users.rs:465:14:
At this point session for 2461787274, should exist.

thread 'shard-9' panicked at core/server/src/shard/system/users.rs:465:14:
At this point session for 2461787274, should exist.

thread 'shard-4' panicked at core/server/src/shard/system/users.rs:465:14:
At this point session for 2461787274, should exist.

thread 'main' panicked at core/server/src/main.rs:302:23:
Failed to join shard thread: Any { .. }

[numinnex]

Hmm intresting, when I tried to run it I've got error that the port is already in use.

For the error that you are getting, you need to broadcast the session in the handle_stream method. Check out the tcp_listenerline 171-178.

[jadireddi]

@numinnex now we don't see any panics on shards.
Can you check once if no other process is using 8080 port, and can you help to run this on your local.

Two more comments to resolve