QUIC Transport

[ethindp]

I would develop this myself, but there isn't any documentation on how to develop a transport plugin. The idea is a QUIC and HTTP/3 plugin. QUIC is defined in the following RFCs, though it might be a wise idea to use a library like lsquic, msquic, etc. QUIC could also implement the same functionality as the TCP transport: it supports both reliable and unreliable communications and it's encrypted by default (or it should be).

References:

• RFC8999: Version-Independent Properties of QUIC
• RFC9000: QUIC: A UDP-Based Multiplexed and Secure Transport
• RFC9001: Using TLS to Secure QUIC
• RFC9002: QUIC Loss Detection and Congestion Control
• RFC9114: HTTP/3
• RFC9204: QPACK: Field Compression for HTTP/3
• RFC9221: An Unreliable Datagram Extension to QUIC

There are others, see here.

[bernardnormier]

Hi Ethin,

We are already working on a QUIC transport, so the best is to wait a little bit.

QUIC is quite different (better) than the transports that Ice currently supports. The transports that Ice currently supports are "duplex" transports, not multiplexed like QUIC. Beyond multiplexing, QUIC includes features for flow-control and keep-alive that are not present in a duplex transport like tcp.

Ice currently implements many of these QUIC features itself. For example, it performs multiplexing when it sends/receives requests, responses and control frames over a duplex connection.

All this to say that adding QUIC as another Ice transport is possible, but doing it properly--to actually take advantage of QUIC--requires significant work. Stay tuned!

Cheers,
Bernard

[ethindp]

@bernardnormier Good to hear that! I know that Ice implements some of QUIC's features already but considering how protocols like TCP would most likely interfere (it does have it's own idea of what "flow control" is, for example, and I doubt that meshes well with multiplexed connections), it'll be a lot better to use a protocol that actively encourages multiplexing but that also won't get in your way if you want to do your own thing. Ican't wait to see it in a released version! Do you guys have a timeline or anything, or a specific version when this will come out, or are you just experimenting?

One thing I would also like to see more of is plugin documentation. The plugin docs as it currently stands is pretty bare-bones, and there's no docs for, say, making a transport, or adding an alternate property store (I could see a service relying on an external keystore like AWS Dynamo DB or Etcd). And though you could manually incorporate key retrieval and property initialization, the code would probably be a lot nicer if you could just register a plugin. Just my thoughts. Maybe the docs are supposed to be the way they are because plugin dev is advanced stuff from what it looks like?

[bernardnormier]

@ethindp

The just-released IceRPC comes with a new protocol (icerpc) designed to take advantage of QUIC. Check it out!

The plugin docs as it currently stands is pretty bare-bones, and there's no docs for, say, making a transport

The IceRPC transport APIs are fully documented. This allows you to implement your own transport fairly easily. We even provide "conformance tests" to verify your transport implementation satisfy the IceRPC transport requirements.

[ethindp]

@bernardnormier Oooooo, I'll definitely look into this! The ZeroC ICE docs were absolutely incredible so I definitely have high hopes for this new framework! So happy to see this! (I may look into contributing some extra language bindings for some of my favorite languages too at some point!)

[bernardnormier]

Thanks Ethin.

We very much welcome contributions, and the new contribution bot for IceRPC should be up soon.

Compared to Ice, IceRPC is:

• much more modular
• smaller
• more documented, with new doc website and also doc comments and comments in the code itself

This is not just for us. We want you and other users to write new interceptor, middleware, transports, language mappings, you name it!

[ethindp]

@bernardnormier This is great news! If I did want to make language mappings, how would I go about that (considering that it's currently only available for .NET)? Would I need to rewrite the entire framework in the new language, or is there a less onerous route? (I could host the .NET runtime, but given that some of my favorite languages have runtimes of their own...)

[bernardnormier]

I plan to write a blog post on this very topic 😃.

The short answer is yes: if you want to implement IceRPC in say Julia, you would rewrite pretty much everything in Julia.

It's a significant job but still achievable. IceRPC for C# is both full featured and reasonably small:

src bernard$ cloc .
     349 text files.
     331 unique files.                                          
      22 files ignored.

github.com/AlDanial/cloc v 1.96  T=0.19 s (1782.9 files/s, 158026.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C#                             286           3658           5620          18132
Markdown                        15            290              0            846
MSBuild script                  18              3             22            436
JSON                             8              0              0            278
XML                              4              1              6             46
-------------------------------------------------------------------------------
SUM:                           331           3952           5648          19738
-------------------------------------------------------------------------------

src bernard$ cloc IceRpc/
     133 text files.
     133 unique files.                                          
       0 files ignored.

github.com/AlDanial/cloc v 1.96  T=0.09 s (1463.3 files/s, 178367.7 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C#                             130           2169           3206          10695
Markdown                         1             18              0             72
MSBuild script                   1              0              1             44
XML                              1              0              1              6
-------------------------------------------------------------------------------
SUM:                           133           2187           3208          10817
-------------------------------------------------------------------------------

And this includes Slice1 and Slice2, the ice and icerpc protocols, the QUIC support, the Slic adapter... everything except slicec-cs. You should certainly start with a smaller subset.

[ethindp]

Thanks; I'll look into it -- I may end up writing a language binding! (The only downside to this is that since each binding is independently developed, it risks Asynchrony between those implementations and the official one.) I'll close this issue since, for all intents and purposes, it's been resolved. I look forward to experimenting with this new RPC framework to see what I can do with it!