QUICER Announcements

[qzhuyan]

To be transparent to the community, we keep making some announcements regarding:

• Development Progress
• Decisions
• Tag/Branch changes
• Test Results
• Some other facts.

[qzhuyan]

We are making heavy refactoring aiming QUICER to be production grade.
This is driven by making it easy to use for developing APP that handles multi-streams.

The refactoring will come with many breaking changes including

• API changes
• Message formats. (msg from stack to the resource owners)
• A behavior to make quic programming easier.
• documents the messages to the owners.
• Updated API docs.

What will not be included is

• configuration implementations, there is still lots to impl. and test.

We will bump the tags:

• We will make a new tag on current main branch as the end of PoC
• new tags for aiming for production grade will start from 0.0.100

[qzhuyan]

We got some contacts asking for merge the refactoring PR to unblock your work and we did it.

We will continue improve quicker with follow up PRs.

We are also thinking having a MsQuic Fork repo that hosts most of the work for quicer. What do you think?

[qzhuyan]

now main branch has latest MsQuic 2.1.3

[qzhuyan]

Next major changes will try to have 1 to 1 mapping of msquic APIs for flexibility.

Old APIs will be kept for convenient.

A quick glance of the differences will be:

API v1:

Port = 4567,
{ok, Conn} = quicer:connect("localhost", Port, [{alpn, ["sample"]}, {verify, none}], 5000),
{ok, Stm} = quicer:start_stream(Conn, []),
{ok, 4} = quicer:send(Stm, <<"ping">>),
receive {quic, <<"pong">>, Stm, _Props} -> ok end,
ok = quicer:close_connection(Conn).

API v2:

{ok, Conn} = quicer:open_connection([{alpn, ["sample"]}, {verify, none}]),
{ok, Stm} = quicer:open_stream(Conn, []),
{ok, 4} = quicer:async_send(Stm, <<"ping">>),
{ok, Conn} = quicer:start_connection("localhost", Port),
receive {quic, <<"pong">>, Stm, _Props} -> ok end,
ok = quicer:close_connection(Conn).

[klacke]

Excellent idea, it'll make it easier to understand the api using the msquic docs.

…

On Wed, 4 Jan 2023, 12:15 William Yang, ***@***.***> wrote: Next major changes will try to have 1 to 1 mapping of msquic APIs for flexibility. Old APIs will be kept for convenient. A quick glance of the differences will be: API v1: Port = 4567, {ok, Conn} = quicer:connect("localhost", Port, [{alpn, ["sample"]}, {verify, none}], 5000), {ok, Stm} = quicer:start_stream(Conn, []), {ok, 4} = quicer:send(Stm, <<"ping">>), receive {quic, <<"pong">>, Stm, _Props} -> ok end, ok = quicer:close_connection(Conn). API v2: {ok, Conn} = quicer:open_connection([{alpn, ["sample"]}, {verify, none}]), {ok, Stm} = quicer:open_stream(Conn, []), {ok, 4} = quicer:async_send(Stm, <<"ping">>), {ok, Conn} = quicer:start_connection("localhost", Port), receive {quic, <<"pong">>, Stm, _Props} -> ok end, ok = quicer:close_connection(Conn). — Reply to this email directly, view it on GitHub <#122 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANQIBEAIBKJGUXDVCABL3WQVLTZANCNFSM6AAAAAAQZ43WIU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[qzhuyan]

regarding issue: #209

I need some suggestions/inputs from user's point of view. You are welcome to add comments to that issue.

[qzhuyan]

Rewrite in RUST

When I start the quicer project, I didn't expect I need to write so many C code.
I thought it should be just a thin layer of C glue code because MsQuic provides multi thread worker, async tasks ....
But now after a few iterations I realize it is not just thin layer of code and I need to do ref counting, mutex in NIF code because not all the MsQuic API are thread safe and need caller to manage the life cycle of connections and streams.

As we gain enough knowledge about MsQuic and OTP NIF, it is good time to start thinking of rewriting the NIF in rust because:

1. Current most error prone hand crafted stuffs (ref counting, ownership, mutex, lifecycle management) in quicer have their mappings in Rust language domain. Some could be checked at compile time.
2. MsQuic provides Rust bindings, although it is not production grade yet.
3. From benchmark and profiling result, the bottleneck in current implementation is when quicer create ctx for incoming connection or streams in beam (resource) and when it reports event to the erlang processes. Mostly due to memory allocations. So even rust might be slower than C, it should be negligible.
4. In late 2023, AI may help to generate the code.
5. there are other quic stack in rust world, we could try anyway.