Question: any thoughts on reliable UDP or QUIC? And QoS?

[jaredthirsk]

(I would post this as a discussion but it doesn't seem to be enabled for this repo.)

My understanding is most action games historically prefer some sort of reliable UDP, instead of TCP, because if packets are lost in a TCP connection, it has a head of line blocking problem which slows things down.

Is there any desire from Cysharp to consider this sort of functionality?

• reliable UDP or QUIC support
• Quality of Service: choosing a delivery mode (perhaps as an optional parameter on MagicOnion's .Connect()): at least once, at most once, exactly once

Note that there is a Microsoft QUIC implementation exposed to C# here: https://github.com/microsoft/msquic https://en.wikipedia.org/wiki/QUIC

[Edit: maybe I should be looking at this instead? https://github.com/RevenantX/LiteNetLib]

Suggested course of action:

1. Say "no", there are no plans for QUIC or reliable UDP (or yes)
2. Close this issue

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[jaredthirsk]

I looked at this more, and I wonder if one ideal approach would be to put MagicOnion's RPC over LiteNetLib (or similar) as the transport.

It looks like the transport might be able to be swapped out, but after a bit of looking I couldn't quite figure out how to do it yet.

Has anyone else thought about something like this?

[0xF6]

I would also like to be able to overwrite the transport. for example, using steam networking within the transport network for magiconion but a cursory inspection of the code did not lead me to a quick and easy replacement of the transport @mayuki can you give a quick answer about replacing and/or configuring another transport in the future?

[mayuki]

MagicOnion uses gRPC as its message protocol, so the available transport protocols are limited to those that HttpHandler and ASP.NET Core (Kestrel) can support.

For example, SocketsHttpHandler and Kestrel support Unix Domain Sockets and NamedPipe, so you can use them, but if you want to use something like RUDP, you will need to implement transport support for HttpHandler and Kestrel that supports HTTP/2 semantics on top of RUDP.

We understand the demand for using RUDP/KCP, etc., so we would like to consider separating the transports, but we don't have any detailed plans yet.

[mayuki]

If we separate it from ASP.NET Core, I expect that it won't be that difficult to run gRPC over RUDP without HTTP/2, but at the moment, many parts of MagicOnion.Server rely on ASP.NET Core and Grpc.AspNetCore.